UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION

Software Requirements: Functional and Non-Functional, User requirements, System

requirements, Software Requirements Document – Requirement Engineering Process:
Feasibility Studies, Requirements elicitation and analysis, requirements validation,
requirements management Classical analysis: Structured system Analysis, Petri Nets-
Data Dictionary.
Software Requirements
 In the software development process, requirement phase is the first software engineering
activity. This phase is a user-dominated phase and translates the ideas or views into a
requirements document.
 The requirement phase encompasses a set of tasks, which help to specify the impact of the
software on the organization, customers’ needs, and how users will interact with the
developed software.
 The requirements are the basis of the system design. If requirements are not correct the end
product will also contain errors.
 Note that requirements activity like all other software engineering activities should be
adapted to the needs of the process, the project, the product and the people involved in the
activity.
 Also, the requirements should be specified at different levels of detail. This is because
requirements are meant for people such as users, business managers, system engineers, and
so on.
 For example, business managers are interested in knowing which features can be
implemented within the allocated budget whereas end-users are interested in knowing how
easy it is to use the features of software.

 The intent of requirements engineering is to provide all parties with a written understanding
of the problem. This can be achieved though a number of work products: usage scenarios,
functions and features lists, requirements models, or a specification.

What is Software Requirement?

Requirement is a condition or capability possessed by the software or system
component in order to solve a real world problem. The problems can be to automate a part
of a system, to correct shortcomings of an existing system, to control a device, and so on.
IEEE defines requirement as
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
documents.
(3) A documented representation of a condition or capability as in (1) or (2).’
Requirements describe how a system should act, appear or perform. For this, when users
request for software, they provide an approximation of what the new system should be
capable of doing. Requirements differ from one user to another and from one business
process to another.
Types of Requirements
 The requirement can be defined as a high-level abstract statement or a detailed
mathematical functional specification of a system's services, functions, and
constraints.
 They are depictions of the characteristics and functionalities of the target system.
Requirements denote the expectations of users from the software product.
  The requirement should be open to interpretation and detailed enough to understand.
 It is essential to know about software requirements because it minimizes the
developer's time and effort and the development cost.
 Requirements are broadly classified into user requirement and System Requirement
There are three types of software requirements as follows:
1. Functional requirements
2. Non-Functional requirements
3. Domain requirements

1. Functional Requirements/ Functional Specification:

 IEEE defines functional requirements as ‘a function that a system or component must
be able to perform.’
 Functional requirements are such software requirements that are demanded explicitly as
basic facilities of the system by the end-users. So, these requirements for functionalities
should be necessarily incorporated into the system as a part of the contract.
 They describe system behaviour under specific conditions. In other words, they are
the functions that one can see directly in the final product, and it was the requirements of
the users as well. It describes a software system or its components.
 These are represented as inputs to the software system, its behavior, and its output. It
can be a calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to perform.
 A functional requirement can range from the high-level abstract statement of the sender's
necessity to detailed mathematical functional requirement specifications. Functional
software requirements help us to capture the intended behavior of the system.

Examples of functional requirements

1. Whenever a user logs into the system, their authentication is done.
2. In case of a cyber attack, the whole system is shut down
3. Whenever a user registers on some software system the first time, a verification email
is sent to the user.
Functional requirements should be complete and consistent.
Completeness implies that all the user requirements are defined.
Consistency implies that all requirements are specified clearly without any contradictory
definition.
Generally, it is observed that completeness and consistency cannot be achieved in large
software or in a complex system due to the problems that arise while defining the functional
requirements of these systems. The different needs of stakeholders also prevent the
achievement of completeness and consistency.
2. Non Functional Requirements
 The non-functional requirements are related to system attributes such as
reliability and response time.
 They are also called non-behavioral requirements or quality
requirements/attributes
 Non-functional requirements arise due to user requirements, budget constraints,
organizational policies, and so on.
 These requirements are not related directly to any particular function provided by
the system.
 Non-functional requirements should be accomplished in software to make it
perform efficiently. For example, if an aeroplane is unable to fulfill reliability
requirements, it is not approved for safe operation. Similarly, if a real time control
system is ineffective in accomplishing non-functional requirements, the control
functions cannot operate correctly.
 Non-functional requirements are more abstract. They deal with issues like-
o Performance
o Reusability
o Flexibility
o Reliability
o Maintainability
o Security
o Portability
The description of different types of non-functional requirements is listed below.

Product requirements: These requirements specify how software product performs. Product
requirements comprise the following.

1. Efficiency requirements: Describe the extent to which the software makes optimal
use of resources, the speed with which the system executes, and the memory it
 consumes for its operation. For example, the system should be able to operate at least
three times faster than the existing system.
2. Reliability requirements: Describe the acceptable failure rate of the software. For
example, the software should be able to operate even if a hazard occurs.
3. Portability requirements: Describe the ease with which the software can be
transferred from one platform to another. For example, it should be easy to port the
software to a different operating system without the need to redesign the entire
software.
4. Usability requirements: Describe the ease with which users are able to operate the
software. For example, the software should be able to provide access to functionality
with fewer keystrokes and mouse clicks.

Organizational requirements: These requirements are derived from the policies and
procedures of an organization. Organizational requirements comprise the following.

1. Delivery requirements: Specify when the software and its documentation are to be
delivered to the user.
2. Implementation requirements: Describe requirements such as programming language
and design method.
3. Standards requirements: Describe the process standards to be used during software
development. For example, the software should be developed using standards specified
by the ISO and IEEE standards.

External requirements: These requirements include all the requirements that affect the
software or its development process externally. External requirements comprise the
following.

1. Interoperability requirements: Define the way in which different computer based

systems will interact with each other in one or more organizations.
2. Ethical requirements: Specify the rules and regulations of the software so that they
are acceptable to users.
3. Legislative requirements: Ensure that the software operates within the legal
jurisdiction. For example, pirated software should not be sold.

To perform the process of specification of non-functional requirements, we require

knowledge of the context within which the system will operate and an understanding of the
system's functionality.
3. Domain Requirements:
 Domain requirements are the requirements which are characteristic of a particular
category or domain of projects.
 Domain requirements can be functional or non functional.
 Domain requirements engineering is a continuous process of proactively defining
the requirements for all foreseeable applications to be developed in the software
product line.
 The basic functions that a system of a specific domain must necessarily exhibit
come under this category.
Examples of domain requirements are- medical equipment or educational software.
Software in medical equipment
 In medical equipment, software must be developed per IEC 60601 regarding medical
electrical equipment's basic safety and performance.
 The software can be functional and usable but not acceptable for production because it
fails to meet domain requirements.
 An Academic Software
 Such software must be developed to maintain records of an institute efficiently.
 Domain requirement of such software is the functionality of being able to access the list
of faculty and list of students of each grade.

Funtional Requiremnet Non Functional Requirement

 It is used for defining a system and its  It is used for defining the quality
components. attribute of a software system.
 It focuses on what software will be  It fixes the constraint on which
doing. software should fulfill the functional
requirement.
 The user specifies it.  Techies like architects or software
developers specify it.
 It is compulsory.  It is not compulsory.
 It is easy to define.  It is comparatively tough to define.
 It verifies the functionality of the  It verifies the performance of the
system. system
 It is defined as a system at the  It is defined as a system as a whole.
component level.
 Example-System should be shut down  Example-Within 10 seconds, the
if a cyber attack happens. processing should be done of each
request.

Advantages of classifying software requirements include:

1. Better organization: Classifying software requirements helps organize them into
groups that are easier to manage, prioritize, and track throughout the development
process.
2. Improved communication: Clear classification of requirements makes it easier to
communicate them to stakeholders, developers, and other team members. It also ensures
that everyone is on the same page about what is required.
3. Increased quality: By classifying requirements, potential conflicts or gaps can be
identified early in the development process. This reduces the risk of errors, omissions,
or misunderstandings, leading to higher quality software.
4. Improved traceability: Classifying requirements helps establish traceability, which is
essential for demonstrating compliance with regulatory or quality standards.
Disadvantages of classifying software requirements include:
1. Complexity: Classifying software requirements can be complex, especially if there are
many stakeholders with different needs or requirements. It can also be time-consuming
to identify and classify all the requirements.
2. Rigid structure: A rigid classification structure may limit the ability to accommodate
changes or evolving needs during the development process. It can also lead to a siloed
approach that prevents the integration of new ideas or insights.
3. Misclassification: Misclassifying requirements can lead to errors or misunderstandings
that can be costly to correct later in the development process.

User and System Requirements

 The requirements for a system are the descriptions of the services that a system should
provide and the constraints on its operation.
 These requirements reflect the needs of customers for a system that serves a certain
purpose such as controlling a device, placing an order, or finding information.
 The process of finding out, analyzing, documenting and checking these services
and constraints is called requirements engineering (RE).
Some of the problems that arise during the requirements engineering process are a result of
failing to make a clear separation between these different levels of description. we distinguish
between them by using the term user requirements to mean the high-level abstract
requirements and system requirements to mean the detailed description of what the system
should do. User requirements and system requirements may be defined as follows:

User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must operate.
The user requirements may vary from broad statements of the system features required to
detailed, precise descriptions of the system functionality.
 User requirements describe what services the system is expected to
provide and the constraints under which it must operate.
 These requirements should describe functional and non-functional
requirements so that they are understandable by system users who don’t have
detailed technical knowledge
 They should specify only the external behaviour and avoid the
system design characteristics
 User requirements are defined using natural language, tables, and diagrams
 Problems faced with natural language:
1. Lack of clarity: It is sometimes difficult to use language in a precise and
unambiguous way without making the document wordy and difficult to read.
2. Requirements confusion: Functional requirements, non-functional
requirements, system goals and design information may not be clearly
distinguished.
3. Requirements amalgamation: Several different requirements may be
expressed together as a single requirement.
 This requirement includes both conceptual and detailed information.
 The user requirement should simply focus on the key facilities to be provided.
 A rationale can be associated with each user requirement which explains why the
requirement has been included and is particularly useful when requirements are
changed
Guidelines to be followed to minimize misunderstandings when writing
user requirements:
1. Use a standard format to define all the requirement.
2. Use language consistently.
3. Use text highlighting (bold, italic or color) to pick out key parts of the
requirement.
4. Avoid using computer jargon /technical terms

System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document (sometimes called a
functional specification) should define exactly what is to be implemented. It may be part of
the contract between the system buyer and the software developers.
 System requirements describe the external behaviour of the system and its operational
constraints.
 This explains how the user requirements should be provided by the system
 System requirement should be a complete and consistent specification of the whole
system
 Natural language is often used to write system requirements specifications
Drawbacks of using natural language specifications for specifying system requirements:
1. Ambiguity
 The readers and writers of the requirement must interpret the same words in
the same way. NL is naturally ambiguous so this is very difficult.
2. Over-flexibility
 The same thing may be said in a number of different ways in the specification.
3. Lack of modularisation
 NL structures are inadequate to structure system requirements.
Alternate Notations used for System requirements specification
1.Structured natural language
 This approach depends on defining standard forms or templates to express the
requirements specification.
2.Design description languages
 This approach uses a language like a programming language but with more abstract
feature to specify the requirements by defining an operational model of the system
3. Graphical notations
 A graphical language, supplemented by text annotations is used to define the
functional requirements for the system. Eg: SADT(structured analysis and design
techniques), use case diagram, sequence diagrams etc
4. Mathematical specifications
 These are notations based on mathematical concepts such as finite-state machines or
sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality
5.Structured natural language specifications
 Structured natural language is a way of writing system requirements in a standard
format.
 Advantage of this approach is that it maintains most of the expressiveness and
understandability of natural language but ensures that some degree of uniformity is
imposed on the specification.
 Structured language notations limit the terminology that can be used and use templates
to specify system requirements.
 They may include control constructs derived from programming languages and
graphical highlighting to partition the specification.
 When a standard form is used for specifying functional requirements, the following
information should be included:
1. Description of the function or entity being specified
2. Description of its inputs and where these come from
3. Description of its outputs and where these go to
4. Indication of what other entities are used (the requires part)
5. Description of the action to be taken
6. If a functional approach is used, a pre-condition setting out what must be true
before the function is called and a post-condition specifying what is true after
the function is called
7. Description of the side effects (if any) of the operation.
Advantages:
 Variability in the specification is reduced and requirements are organized more
effectively.
 To avoid ambiguity, add extra information to natural language requirements using
 tables or graphical models of the system. These can show how computations proceed,
how the system state changes, how users interact with the system and how sequences
of actions are performed.
Different kinds of requirement are needed to communicate information about a system to
different types of reader.
Figure illustrates the distinction between user and system requirements.

This example from the mental health care patient information system (Mentcare)
shows how a user requirement may be expanded into several system requirements. You can
see from Figure that the user requirement is quite general. The system requirements provide
more specific information about the services and functions of the system that is to be
implemented.
You need to write requirements at different levels of detail because different types of
readers use them in different ways. Figure below shows the types of readers of the user and
system requirements.

The readers of the user requirements are not usually concerned with how the system
will be implemented and may be managers who are not interested in the detailed facilities of
the system. The readers of the system requirements need to know more precisely what the
system will do because they are concerned with how it will support the business processes or
because they are involved in the system implementation.

The different types of document readers shown in Figure above are examples of
system stakeholders. As well as users, many other people have some kind of interest in the
system. System stakeholders include anyone who is affected by the system in some way and
so anyone who has a legitimate interest in it. Stakeholders range from end-users of a system
through managers to external stakeholders such as regulators, who certify the acceptability of
the system. For example, system stakeholders for the Mentcare system include:

1. Patients whose information is recorded in the system and relatives of these patients.
 2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some
treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
6. A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
7. Health care managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly
implemented.

Requirements engineering is usually presented as the first stage of the software engineering
process. However, some understanding of the system requirements may have to be developed
before a decision is made to go ahead with the procurement or development of a system. This
early-stage RE establishes a high-level view of what the system might do and the benefits
that it might provide. These may then be considered in a feasibility study, which tries to
assess whether or not the system is technically and financially feasible. The results of that
study help management decide whether or not to go ahead with the procurement or
development of the system.

Software Requirements Document

 System Requirements Document is also known as System Requirements
Specifications.
 System requirements document is a set of documentation that describes the behaviour
and features of a software or system.
 It comprises of various elements that attempt to characterize the functionality needed
by the client to satisfy their users. In other words, the system requirements document
(SRD) describes the system-level performance and functional requirements for a
system.

System Requirements Document or System Requirements Specification is defined as a

document which defines what the software will do and how it will be required to
perform, and it also defines the functionality the software needs to satisfy all
stakeholders (users, business) requirements.

What is Included in a System Requirement Document?

While the SRD capacities as an outline for dealing with the extent of a project, it
eventually characterizes the functional and non-functional requirements of the system. The
document doesn't layout design or technology solutions. These decisions will be taken by the
developers later.
The well-written system requirement document should:
o Split the problem into manageable parts.
o Notify design specifications i.e., SRD needs to comprise adequate information on
software requirements to present an effective design.
o Gives feedback to the customer or client.
o For testing and validation, serve as a reference.
Need of software requirement document
1. It structure and formalizes all project requirements
2. It help the development team to build a product that exactly meets customer and target
audience needs
3. It provide all team members with necessary information while working on the project
4. It minimize the possible misunderstandings between the members of development team
and customers
5. It clearly defined the scope of work and that allows developers to plan particular iteration
and release date
6. It allows estimating the required development budget

Structure of SRS
1. Introduction
1.1 Purpose
1.2 Intended audience
1.3 Scope
1.4 Definition
1.5 Reference
2. Overall description
2.1 user interface system
2.2 interface Software and Hardware requirements constraints
2.3 user characteristics
3. System features and requirements
3.1 Functional requirement
3.2 Use case/sequence diagram
3.3 External interface requirement
3.4 Database requirement
3.5 Nonfunctional requirement
4. delivery for approval

Characteristics of good SRS

1. Correctness - It provide accurate functional and nonfunctional requirements as
described with client
2. Completeness- it should complete all essential features like functionality
performance features design constraints and external interfaces
3. Consistency- same Abbreviation tabular format diagram format name format should
be followed
4. Unambiguousness- there should not be any confusion regarding understanding of
the requirements
5. Modifiability- it is capable of quickly obtaining changes to the system without
affecting others
6. Ranking for importance and stability- every requirement is important some maybe
urgent and some must be full filled before other requirement so classify according to
the importance and stability
7. Verifiability- Requirements should be verified with the help of reviews and
stakeholders
8. Traceability - every requirement having unique number that is easy to use in future
development
9. Design Independence -that should be an option to select from multiple design and
alternative for the final system.SRS should not contain any implementation details
10. Testability- SRS must be written such a way that it is simple to generate the cases
and test plans from the report
11. Understable by the customer- the language should be kept simple and clear
Goals of SRS document:
1. Problem Breakdown: it divide the problem into component parts.
2. Input to design specification: it serves as the parent document to subsequent document
such as the software design specification and statement of work.
3. Feedback to customer: customer is assured that the developing organization understand
the issues or problem to be solved.
4. Product validation check: it ensure the good quality of the product.

Disadvantages of SRS document:

1. Time-consuming: Creating an SRS document can be time-consuming, especially if the
software system is complex and involves many stakeholders.
2. Limited flexibility: Once the SRS document is created, it can be difficult to make
changes to it without affecting other parts of the document.
3. Limited user involvement: If the SRS document is created before user involvement, it
may not reflect the actual needs and requirements of the users.
4. Misinterpretation: Despite efforts to make the SRS document clear and unambiguous,
there may still be some room for misinterpretation, which can lead to errors in the final
software product.
Requirement Engineering Process
 The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirements engineering. From a software process
perspective, requirements engineering is a major software engineering action that
begins during the communication activity and continues into the modeling activity.
 Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process.
 Requirement engineering provides the appropriate mechanism to understand what the
customer desires, analyzing the need, and assessing feasibility, negotiating a
reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system.
 Thus, requirement engineering is the disciplined application of proven principles,
methods, tools, and notation to describe a proposed system's intended behavior and its
associated constraints.
Requirement Engineering Process
It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

requirements engineering process

1. Feasibility Study
The main aim of a feasibility study is to create reasons for the development of the
software that the users accept, that is flexible enough and open to changes, and abide by the
standards chosen for software development and maintenance.
There are several types of feasibility. They are:
Technical Feasibility: The current technologies are evaluated using technical feasibility, and
they are necessary to achieve the requirements of the customer within the given time and
budget.
Operational Feasibility: The assessment of the range for software in which the required
software performs a series of levels to solve the problems in business and the customer’s
requirements.
Economic Feasibility: If the required software can generate profits in the area of finance is
decided by economic feasibility.

2. Elicitation of Requirements and Analysis

 This process is also called requirements gathering. If there are any existing processes
available and with the help of customers, requirements gathering is done.
 Elicitation of requirements is the starting step of requirements analysis.
Inconsistencies, omissions, defects, etc., can be identified by analyzing the
requirements.
 Requirements are described in relationship terms to resolve if there are any conflicts.
 The goal of this step is to understand the problem that the software system is intended
to solve, and the needs and expectations of the stakeholders who will use the system.
There are several techniques that can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather information
about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software system,
which can be used to gather feedback from stakeholders and to validate requirements.
It’s important to document, organize and prioritize the requirements obtained from all these
techniques to ensure that they are complete, consistent and accurate.
challenges with respect to the elicitation of requirements and analysis. They are:

 Involvement of all the right people and only the right people.
 The stakeholders not knowing what they need.
 The requirements are expressed in terms of stakeholders.
 The requirements of the stakeholders may be conflicting.
 The changes in requirements during the process of analysis.
 Several factors influence the requirements of the system in organization and politics.

3.Specification of Software Requirements

 A document consisting of requirements that are collected from various sources like
the requirements from customers expressed in an ordinary language and created by
the software analyst is called a specification document for software requirements .
  The analyst understands the customers’ requirements in ordinary language and
converts them into a technical language that the development team can easily
understand.
 Several models are used during the process of specification of software requirements
like Entity-Relationship diagrams (ER diagrams), data flow diagrams (DFD), data
dictionaries, function decomposition diagrams (FDD), etc.

7. Data Flow Diagrams (DFD): The modeling of requirements can be done

using Data Flow Diagrams (DFD). The flow of data within the system can be
seen by using data flow diagrams (DFD). The system here can be a company,
an organization, a hardware system in a computer, a software system in a
computer, a set of procedures or a combination of everything. The data flow
diagrams (DFD) are also called bubble charts or data flow graph.
8. Data Dictionaries: The data defined using a data flow diagram (DFD) is
stored as information in the form of repositories called data dictionaries. The
customer’s data items must be defined by the data dictionaries at the stage of
requirements gathering to make sure that the customers and developers use the
same methodologies and definitions.
9. Entity Relationship Diagrams: One of the other tools used for the
specification of requirements is entity-relationship diagrams. It is also called
as ER diagrams. The detailed representation of logic for the organization is
done using entity relationship diagrams (ER diagrams). They make use of
three types of constructs: relationships, entities of data, and the attributes
associated with them.
 The goal of this step is to create a clear and comprehensive document that
describes the requirements for the software system. This document should be
understandable by both the development team and the stakeholders.
There are several types of requirements that are commonly specified in this step,
including:
 Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
 Non-Functional Requirements: These describe how well the software system should do
it. They specify the quality attributes of the system, such as performance, reliability,
usability, and security.
 Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.
 Acceptance Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.
In order to make the requirements specification clear, the requirements should be written in a
natural language and use simple terms, avoiding technical jargon, and using a consistent
format throughout the document. It is also important to use diagrams, models, and other
visual aids to help communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the stakeholders
and development team to ensure that they are complete, consistent, and accurate.
4. Validation of Software Requirements
Verification: It refers to the set of tasks that ensures that the software correctly implements a
specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been
built is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
 The requirements should be consistent with all the other requirements i.e no two
requirements should conflict with each other.
 The requirements should be complete in every sense.
 The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements verification and validation (V&V) is the process of checking that the
requirements for a software system are complete, consistent, and accurate, and that
they meet the needs and expectations of the stakeholders. The goal of V&V is to ensure
that the software system being developed meets the requirements and that it is
developed on time, within budget, and to the required quality.
 Verification is the process of checking that the requirements are complete, consistent, and
accurate. It involves reviewing the requirements to ensure that they are clear, testable, and
free of errors and inconsistencies. This can include reviewing the requirements document,
models, and diagrams, and holding meetings and walkthroughs with stakeholders.
 Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure that they
are valid and that the software system being developed will meet the needs of the
stakeholders. This can include testing the software system through simulation, testing
with prototypes, and testing with the final version of the software.
 V&V is an iterative process that occurs throughout the software development life cycle.
It is important to involve stakeholders and the development team in the V&V process to
ensure that the requirements are thoroughly reviewed and tested.
It’s important to note that V&V is not a one-time process, but it should be integrated and
continue throughout the software development process and even in the maintenance stage.

5. Management of Software Requirements

Requirement management is the process of analyzing, documenting, tracking,
prioritizing and agreeing on the requirement and controlling the communication to
relevant stakeholders. This stage takes care of the changing nature of requirements. It
should be ensured that the SRS is as modifiable as possible so as to incorporate changes in
requirements specified by the end users at later stages too. Being able to modify the software
as per requirements in a systematic and controlled manner is an extremely important part of
the requirements engineering process.
Requirements management is the process of managing the requirements throughout the
software development life cycle, including tracking and controlling changes, and ensuring
that the requirements are still valid and relevant. The goal of requirements management is
to ensure that the software system being developed meets the needs and expectations of
the stakeholders and that it is developed on time, within budget, and to the required
quality.
There are several key activities that are involved in requirements management, including:
 Tracking and controlling changes: This involves monitoring and controlling changes to
the requirements throughout the development process, including identifying the source of
the change, assessing the impact of the change, and approving or rejecting the change.
 Version control: This involves keeping track of different versions of the requirements
document and other related artifacts.
 Traceability: This involves linking the requirements to other elements of the
development process, such as design, testing, and validation.
 Communication: This involves ensuring that the requirements are communicated
effectively to all stakeholders and that any changes or issues are addressed in a timely
manner.
 Monitoring and reporting: This involves monitoring the progress of the development
process and reporting on the status of the requirements.
Requirements management is a critical step in the software development life cycle as it helps
to ensure that the software system being developed meets the needs and expectations of
stakeholders, and that it is developed on time, within budget, and to the required quality. It
also helps to prevent scope creep and to ensure that the requirements are aligned with the
project goals.

Advantages of requirements engineering process:

 Helps ensure that the software being developed meets the needs and expectations of the
stakeholders
 Can help identify potential issues or problems early in the development process, allowing
for adjustments to be made before significant
 Helps ensure that the software is developed in a cost-effective and efficient manner
 Can improve communication and collaboration between the development team and
stakeholders
 Helps to ensure that the software system meets the needs of all stakeholders.
 Provides a clear and unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.
 Helps to identify potential conflicts and contradictions in the requirements, which can be
resolved before the software development process begins.
 Helps to ensure that the software system is delivered on time, within budget, and to the
required quality standards.
 Provides a solid foundation for the development process, which helps to reduce the risk of
failure.

Disadvantages of requirements engineering process:

 Can be time-consuming and costly, particularly if the requirements gathering process is
not well-managed
 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into
account
 Can be challenging to ensure that the requirements are clear, consistent, and complete
 Changes in requirements can lead to delays and increased costs in the development
process.
 As a best practice, Requirements engineering should be flexible, adaptable, and should be
aligned with the overall project goals.
 It can be time-consuming and expensive, especially if the requirements are complex.
 It can be difficult to elicit requirements from stakeholders who have different needs and
priorities.
 Requirements may change over time, which can result in delays and additional costs.
 There may be conflicts between stakeholders, which can be difficult to resolve.
 It may be challenging to ensure that all stakeholders understand and agree on the
requirements.
Requirements Engineering Tasks:
The software requirements engineering process includes the following steps of activities:
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
1. Inception: This is the first phase of the requirements analysis process. This phase gives
an outline of how to get started on a project. In the inception phase, all the basic questions
are asked on how to go about a task or the steps required to accomplish a task. A basic
understanding of the problem is gained and the nature of the solution is addressed.
Effective communication is very important in this stage, as this phase is the foundation as
to what has to be done further. Overall in the inception phase, the following criteria have to
be addressed by the software engineers:
 Understanding of the problem.
 The people who want a solution.
 Nature of the solution.
 Communication and collaboration between the customer and developer.

2. Elicitation: This is the second phase of the requirements analysis process. This phase
focuses on gathering the requirements from the stakeholders. One should be careful in this
phase, as the requirements are what establishes the key purpose of a project. Understanding
the kind of requirements needed from the customer is very crucial for a developer. In this
process, mistakes can happen in regard to, not implementing the right requirements or
forgetting a part. The right people must be involved in this phase. The following problems
can occur in the elicitation phase:
 Problem of Scope: The requirements given are of unnecessary detail, ill-defined, or not
possible to implement.
 Problem of Understanding: Not having a clear-cut understanding between the
developer and customer when putting out the requirements needed. Sometimes the
customer might not know what they want or the developer might misunderstand one
requirement for another.
 Problem of Volatility: Requirements changing over time can cause difficulty in leading
a project. It can lead to loss and wastage of resources and time.
3. Elaboration: This is the third phase of the requirements analysis process. This phase is
the result of the inception and elicitation phase. In the elaboration process, it takes the
requirements that have been stated and gathered in the first two phases and refines them.
Expansion and looking into it further are done as well. The main task in this phase is to
indulge in modeling activities and develop a prototype that elaborates on the features and
constraints using the necessary tools and functions.

4. Negotiation: This is the fourth phase of the requirements analysis process. This phase
emphasizes discussion and exchanging conversation on what is needed and what is to be
eliminated. In the negotiation phase, negotiation is between the developer and the customer
and they dwell on how to go about the project with limited business resources. Customers
are asked to prioritize the requirements and make guesstimates on the conflicts that may
arise along with it. Risks of all the requirements are taken into consideration and negotiated
in a way where the customer and developer are both satisfied with reference to the further
implementation. The following are discussed in the negotiation phase:
 Availability of Resources.
 Delivery Time.
 Scope of requirements.
 Project Cost.
 Estimations on development.

5. Specification: This is the fifth phase of the requirements analysis process. This phase
specifies the following:
 Written document.
 A set of models.
 A collection of use cases.
 A prototype.
 In the specification phase, the requirements engineer gathers all the requirements and
develops a working model. This final working product will be the basis of any functions,
features or constraints to be observed. The models used in this phase include ER (Entity
Relationship) diagrams, DFD (Data Flow Diagram), FDD (Function Decomposition
Diagrams), and Data Dictionaries.
A software specification document is submitted to the customer in a language that he/she
will understand, to give a glimpse of the working model.

6. Validation: This is the sixth phase of the requirements analysis process. This phase
focuses on checking for errors and debugging. In the validation phase, the developer scans
the specification document and checks for the following:
 All the requirements have been stated and met correctly
 Errors have been debugged and corrected.
 Work product is built according to the standards.
This requirements validation mechanism is known as the formal technical review. The
review team that works together and validates the requirements include software engineers,
customers, users, and other stakeholders. Everyone in this team takes part in checking the
specification by examining for any errors, missing information, or anything that has to be
added or checking for any unrealistic and problematic errors. Some of the validation
techniques are the following-
 Requirements reviews/inspections.
 Prototyping.
 Test-case generation.
 Automated consistency analysis.
7. Requirements Management: This is the last phase of the requirements analysis process.
Requirements management is a set of activities where the entire team takes part in
identifying, controlling, tracking, and establishing the requirements for the successful and
smooth implementation of the project.
In this phase, the team is responsible for managing any changes that may occur during the
project. New requirements emerge, and it is in this phase, responsibility should be taken to
manage and prioritize as to where its position is in the project and how this new change will
affect the overall system, and how to address and deal with the change. Based on this
phase, the working model will be analyzed carefully and ready to be delivered to the
customer.
Classical analysis

Structured system Analysis

Analysts use various tools to understand and describe the information system. One of the ways
is using structured analysis.
What is Structured Analysis?
Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives
of an existing system and develop a new system specification which can be easily
understandable by user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor
or hardware.
 It is an approach that works from high-level overviews to lower-level details.
Structured Analysis Tools
During Structured Analysis, various tools and techniques are used for system development.
They are −
1. Data Flow Diagrams
2. Data Dictionary
3. Decision Trees
4. Decision Tables
5. Structured English
6. Pseudocode

1. Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of system in a
graphical form.
 It shows the flow of data between various functions of system and specifies how the
current system is implemented.
 It is an initial stage of design phase that functionally divides the requirement
specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst or
analyst and system designer.
 It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.
Basic Elements of DFD
DFD is easy to understand and quite effective when the required design is not clear and the
user wants a notational language for communication. However, it requires a large number of
iterations for obtaining the most accurate and complete solution.
The following table shows the symbols used in designing a DFD and their significance −

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points
that differentiate a physical DFD from a logical DFD.
Context Diagram
A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system. It starts with mentioning major processes with little details and then
goes onto giving more details of the processes with the top-down approach.
The context diagram of mess management is shown below.

2. Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.
A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard
feature. For example, refer the following table −

3. Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.
Decision trees depict the relationship of each condition and their permissible actions. A
square node indicates an action and a circle indicates a condition. It forces analysts to
consider the sequence of decisions and identifies the actual decision that must be made.
The major limitation of a decision tree is that it lacks information in its format to describe
what other combinations of conditions you can take for testing. It is a single representation of
the relationships between conditions and actions.
For example, refer the following decision tree −

4. Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise
manner which is easily understandable.
It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.
Components of a Decision Table
 Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be
carried out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to questions
asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.
The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,
 Y shows the existence of a condition.
 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −
 5. Structured English
Structure English is derived from structured programming language which gives more
understandable and precise description of process. It is based on procedural logic that uses
construction and imperative sentences designed to perform operation for action.
 It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential decision
structures and iterations.
For example, see the following sequence of actions –

6. Pseudocode
A pseudocode does not conform to any programming language and expresses logic in plain
English.
 It may specify the physical programming logic without actual coding during and after
the physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.
Guidelines for Selecting Appropriate Tools
Use the following guidelines for selecting the most appropriate tool that would suit your
requirements −
 Use DFD at high or low level analysis for providing good system documentations.
 Use data dictionary to simplify the structure for meeting the data requirement of the
system.
 Use structured English if there are many loops and actions are complex.
 Use decision tables when there are a large number of conditions to check and logic is
complex.
 Use decision trees when sequencing of conditions is important and if there are few
conditions to be tested

Petri Nets
 Petri nets are a graphical for representing a system in which there are multiple
independent activities in progress at the same time.
 The ability to model multiple activities differentiates Petri nets from finite state
machines. In a finite state machine there is always a single “current” state that
determines which action can next occur. In Petri nets there may be several states any
one of which may evolve by changing the state of the Petri net. Alternatively, some,
of even all, of these states may evolve in parallel causing several independent changes
to the Petri net to occur at once.
Basic Structure
 A Petri net consists of four elements: places, transitions, edges, and tokens.
 Graphically, places are represented by circles, transitions by rectangles, edges by
directed arrows, and tokens by small solid (filled) circles.
 There are a wide variety of extensions to Petri nets. These extensions add features
to model probabilistic behavior, allow weighted edges, or have tokens of various
colors among others. Only the most basic Petri net concepts will be covered here.
 A basic Petri net is shown in Figure 2.

 This Petri net has four places, labeled P0 through P4, and three transitions, labeled
T0 through T2. Notice that places P0 and P2 each have a single token represented
by the black dot inside each place.
 Edges, represented as directed arcs, connect places to transitions and transitions to
places.
 In a properly formed Petri net, places cannot be directly connected to other places
and transitions cannot be directly connected to other transitions.
 Also notice that the Petri net may contain cycles. The Petri net in Figure 2
contains two cycles. One cycle contains P0, T0, P1, T1, P3, and T3. The other
cycle contains T1, P4, T2, and P2. Cycles are common in Petri nets which
represent activities that happen repeatedly. For example, a web server repeated
services incoming requests to deliver web page content to different clients.
  The state of a Petri net is represented by the occurrence of the tokens at various
places. The state of the Petri net in Figure 2 has tokens at places P0 and P2. It will
be shown that in another state of this Petri net there are tokens at states P1 and P2.
 Yet another state has tokens at states P3 and P4.
 Not all placements of tokens at places represent a possible state of the system. For
example, the Petri net in Figure 2 will never have as a possible state one in which
the only tokens are at places P1 and P4.
 Which states are possible and which are not are determined by the structure of the
Petri net and the rules that define how a Petri net changes its state.
 A Petri net changes from one state to the next state when a transition “fires”. The
firing of a transition involves the transition’s input places and output places.
 The input places for a transition are all those places that have an edge directed
from the place to the transition.
 The output places of a transition are all those places that have an edge directed
from the transition to the place.
 For example, in Figure 2 the input places for transition T1 are places P1 and P2.
The output place for transition T0 is place P1 while the output places for transition
T1 are places P3 and P4.
The firing rules for a transition are:
1. a transition is able to fire when there is at least one token on each of the
transition’s input places, and
2. when a transition fires it removes one token from each of its input places
and produces a single token on each of its output places.

 A transition that is able to fire is said to be enabled and otherwise disabled. If

there is more than one enabled transition any one of enabled transitions may
be the next one to fire. That is, Petri nets are able to model systems with
non‐deterministic behavior. An example of this will be shown later.
 The Petri net in Figure 2 will be used to explain how a Petri net changes from
one state to the next. In Figure 2 the only transition that is able to fire is
transition T0 because it has a single input place, P0, and that input place has at
least one token. Notice that transition T1 is not able to fire because it has two
input places, P1 and P2, and P1 does not have at least one input token. As a
result of the firing on transition T0, the token in place P0 is removed and a
single token is created in place P1. This state is shown in Figure 3.

 In the state of the Petri net shown in Figure 3 transition T1 is able to fire because there
are input tokens on each of its two input places, P1 and P2. Notice that transition T1
was not able to fire in the previous state of the Petri net (as shown in Figure 2). The
 firing of transition T0 in the earlier state create a new state (the one shown in Figure 3)
in which transition T1 is now able to fire. It is common to find that the firing of a
transition creates a new state in which previously disabled (i.e., unable to fire)
transitions now become enabled (i.e., able to fire). Notice that in Figure 3, transition T1
is the only transition that is enabled. The firing of transition T1 in the state shown in
Figure 3 produces the new state shown in Figure 4. In the state of the Petri net shown
in Figure 4 both transitions T2 and T3 are enabled (i.e., able to fire). As noted about,
these transitions may fire in either order because the Petri net does not determine which
one of the two transitions is the next one to fire. The next state of the Petri net is, thus,
not uniquely determined. The next state can be the one following the firing of transition
T3 or the one following the firing of transition T2. The reader should draw both of
these states and see that they are different.

The state shown in Figure 4 will eventually lead back to one of the previous states. The
possibilities are: • transition T2 fires and then transition T3 fires, leading to the state shown in
Figure 2, • transition T3 fires and then transition T2 fires, leading to the state shown in Figure
2, or • transition T3 fires, transition T0 fires, and then transition T2 fires, leading to the state
shown in Figure 3. This Petri net will continue to transition among these states repeatedly.

Example: Resource Allocation

It is possible that a single place may contain multiple tokens at one time. This situation
occurs frequently in dealing with resource allocation problems where there are multiple units
of a given resource to allocate. In these problems, a place typically represents the number of
available units of the resource. The specific number of units available at a given time is
denoted by the number of tokens contained in the place. When there are no token in the place,
meaning that there are no available units, activities which need a unit of the resource to
execute must wait until a unit is returned or produced. In some systems there are a fixed
number of units which are acquired and returned by the activities. For example, several
processes may acquire and release a printer during their execution. In other cases, the number
of units is variable. For example, in distributed system a sender may generate many data
packets that are waiting to be read by the receiver. Finally, the number of available units,
though variable, may be limited to a maximum amount. For example, in a distributed system
the number of unread data packets may be limited to some number so that the amount of
buffer space at the receiver is limited. The classical producer‐consumer problem is a
resource allocation problem with a variable number of resources that are limited to a
maximum number. There is a producer that generates new units and makes them available to
a consumer. The consumer takes one unit of the resource at a time. The primary
synchronization constraints are: • overflow: the producer cannot produce a new unit unless
the number of units is below the maximum number allowed, and • underflow: the consumer
cannot take a unit unless there is at least one available. The Petri net shown in Figure 8 is a
model of a producer‐consumer system where the maximum number of units is limited to 3. In
this model, there are two places that are used to represent the number of units produced but
not yet consumed and the number of additional units that can be produced. These places are
named Full and Empty, respectively. The names full and empty reflect that the units are often
contained in a fixed sized buffer of size N, where N is the maximum number of units
allowed. The number of buffer entries that are full contain produced units that are available to
the consumer and the number of buffer entries that are empty contain spaces available to the
producer to store new units. An invariant in this model is that number(full) + number(empty)
= N. The buffer is modeled in Figure 8 by the two places in the middle named Empty and
Full. The three tokens in the Empty place represent the initial state of the system with three
empty buffer elements. The absence of tokens in the Full place represents the initial state of
the system where there are no buffer elements with information.

The producer in Figure 8 is modeled as a subsystem with two places. The Generate place
represents the condition of the producer when it is generating the next unit of information to
transmit to the consumer. The Ready state represents the condition where the producer is
ready to insert the newly generated information into the buffer where it is will be available to
the consumer. Notice that the transition Produce for the producer can only fire when the
producer is Ready and there is at least one token in the Empty place (denoting a currently
empty buffer element into which the new information can be placed). The consumer in Figure
8 is modeled as a subsystem with two places. The Ready place represents the condition where
the consumer is ready to receive the next unit of new information that was generated by the
producer. Notice that the transition Take for the producer can only fire when the producer is
Ready and there is at least one token in the Full place (denoting a buffer element containing
new information which can be retrieved). The Process place in the producer represents the
condition of the consumer when it is processing the new information most recently retrieved
from the buffer. It can be observed that the producer‐consumer system in Figure 8 satisfies
the two primary synchronization constraints noted above. The overflow constraint is satisfied
because the producer cannot fire its Produce transition unless there is at least one token in the
Empty place. Thus, it is not possible for the Produce transition to fire four (or more) times in
a row without the Take transition firing one or more times. The underflow constraint is
satisfied because the consumer cannot fire its Take transition unless there is at least one token
in the Full place. Thus, it is not possible for the Take transition to fire four (or more) times in
a row without the Produce transition firing one or more times.

Data Dictionaries

A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership, data
relationships to other objects, and other data. The data dictionary is an essential component of
any relational database. Ironically, because of its importance, it is invisible to most database
users. Typically, only database administrators interact with the data dictionary.
 The data dictionary, in general, includes information about the following:
o Name of the data item
o Aliases
o Description/purpose
o Related data items
o Range of values
o Data structure definition/Forms

The name of the data item is self-explanatory.

Aliases include other names by which this data item is called DEO for Data Entry Operator
and DR for Deputy Registrar.
Description/purpose is a textual description of what the data item is used for or why it
exists.
Related data items capture relationships between data items e.g., total_marks must always
equal to internal_marks plus external_marks.
Range of values records all possible values, e.g. total marks must be positive and between 0
to 100.
Data structure Forms: Data flows capture the name of processes that generate or receive the
data items. If the data item is primitive, then data structure form captures the physical
structures of the data item. If the data is itself a data aggregate, then data structure form
capture the composition of the data items in terms of other data items.

Data dictionary can be used to

 Create an ordered listing of all data items
 Create an ordered listing of subset of all data items
 Find a data item name from a description
 Design the software and test cases

Features of Data Dictionary :

Here, we will discuss some features of the data dictionary as follows.
 It helps in designing test cases and designing the software.
 It is very important for creating an order list from a subset of the items list.
 It is very important for creating an order list from a complete items list.
 The data dictionary is also important to find the specific data item object from the list.

Advantages of Data Dictionary:

 Consistency and Standardization: A data dictionary helps to ensure that all data
elements and attributes are consistently defined and named across the organization,
promoting standardization and consistency in data management practices.
 Data Quality: A data dictionary can help improve data quality by providing a single
source of truth for data definitions, allowing users to easily verify the accuracy and
completeness of data.
 Data Integration: A data dictionary can facilitate data integration efforts by providing
a common language and framework for understanding data elements and their
relationships across different systems.
 Improved Collaboration: A data dictionary can help promote collaboration between
business and technical teams by providing a shared understanding of data definitions
and structures, reducing misunderstandings and communication gaps.
 Improved Efficiency: A data dictionary can help improve efficiency by reducing the
time and effort required to define, document, and manage data elements and attributes.

Disadvantages of Data Dictionary:

 Implementation and Maintenance Costs: Implementing and maintaining a data
dictionary can be costly, requiring significant resources in terms of time, money, and
personnel.
 Complexity: A data dictionary can be complex and difficult to manage, particularly in
large organizations with multiple systems and data sources.
 Resistance to Change: Some stakeholders may be resistant to using a data dictionary,
either due to a lack of understanding or because they prefer to use their own
terminology or definitions.
 Data Security: A data dictionary can contain sensitive information, and therefore,
proper security measures must be in place to ensure that unauthorized users do not
access or modify the data.
 Data Governance: A data dictionary requires strong data governance practices to
ensure that data elements and attributes are managed effectively and consistently acr oss
the organization.