Requirement Engineering

Requirement Engineering
 Requirement Engineering is the disciplined application of proven principles,
methods, tools, and notations to describe a proposed system’s intended
behaviour and its associated constraints.
 SRS may act as a contract between developer and customer.
Requirements are difficult to uncover
 Requirements change
 Tight project Schedule
 Communication barriers
 Market driven software development
 Lack of resources
Types of Requirement
Functional Requirements
 Functional requirements define what the software should DO. They describe the
specific features, actions, and tasks the software must perform.
 These are statement s of services the system should provide, how the system should
react to particular inputs, and how the system should be have in particular situations.
In some cases, the functional requirements may also explicitly state what the system
should not do.
 Requirements, which are related to functional aspect of software fall into this
category.
 They define functions and functionality within and from the software system.

 .
Examples of Functional Requirements
 Users should be able to log in with a username and password.
 The software should allow users to search for products by name or category
 The system must send a confirmation email whenever an order is placed.
 The system must allow blog visitors to sign up for the newsletter by leaving their
email.
 The system must allow users to verify their accounts using their phone number.
 The system must allow users to log into their account by entering their email and
password.
 The system must allow users to log in with their Google accounts.
 The system must allow users to reset their password by clicking on "I forgot my
password" and receiving a link to their verified email address.
Non-Functional Requirements
 Non-functional requirements define how the software should be. They focus
on qualities like performance, usability, security, and more.
 These are constraints on the services or functions offered by the system.
They include timing constraints, constraints on the development process,
and constraints imposed by standards. Non-functional requirements often
apply to the system as a whole rather than individual system features or
services.

Examples of Functional Requirements

 Performance: The software should respond to user actions within 2 seconds

 Usability: The interface should be easy to navigate for all user
Non-functional requirements include -

 Performance: Fast-loading video games without lag.

 Reliability: Car starts every time you turn the key.
 Usability: Phones with a simple and easy-to-use interface.
 Security: Banking websites with strong protection and security for personal
information.
 Scalability: Websites handling a large number of visitors without crashing.
 Compatibility: Printers working with different types of computers.
User Requirement
 User requirements are statements in natural language along with
corresponding diagrams (tables, forms, intuitive diagrams) detailing the
services provided by the system and operational constraints it must comply
with. Additionally, it’s worth noting that user requirements primarily focus
on the user’s needs. Thus, these user requirements cater to the customer.
System Requirement
 System requirements consist of a structured document that details
the system’s functions, services and operational constraints. It’s mainly
written and serves as a tool for the developers of the system to build and
implement the system design. It contains the functionality that’s needed by
the system in order for it to fulfil the user requirements.
Comparison in Functional And Non-Functional
Requirements
Requirement Engineering Activities
Requirement Engineering Process
It is a four-step process, which includes -
 Feasibility Study
 Requirement Elicitation and Analysis
 Software Requirement Specification
 Software Requirement Validation
 Software Requirement Management
 The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.
 Technical Feasibility-Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements within
the time and budget.
 Operational Feasibility-Operational feasibility assesses the range in which
the required software performs a series of levels to solve business problems
and customer requirements.
 Economic Feasibility-Economic feasibility decides whether the necessary
software can generate financial profits for an organization.
 2. Requirement Elicitation and Analysis :
 This is also known as the gathering of requirements. Here, requirements are
identified with the help of customers and existing systems processes, if
available.
 Analysis of requirements starts with requirement elicitation. The
requirements are analyzed to identify inconsistencies, defects, omission, etc.
We describe requirements in terms of relationships and also resolve
conflicts if any.
Problems of Elicitation and Analysis
 Getting all, and only, the right people involved.
 Stakeholders often don't know what they want
 Stakeholders express requirements in their terms.
 Stakeholders may have conflicting requirements.
 Requirement change during the analysis process.
 Organizational and political factors may influence system requirements.
 Requirements Elicitation: This is the process of gathering
information about the needs and expectations of stakeholders for the
software system. This step involves interviews, surveys, focus
groups, and other techniques to gather information from
stakeholders.
 Requirements Analysis: This step involves analyzing the information
gathered in the requirements elicitation step to identify the high-level
goals and objectives of the software system. It also involves
identifying any constraints or limitations that may affect the
development of the software system.
:
3. Software Requirement Specification

 Software requirement specification is a kind of document which is created

by a software analyst after the requirements collected from the various
sources -the requirement received by the customer written in ordinary
language. It is the job of the analyst to write the requirement in technical
language so that they can be understood and beneficial by the development
team.
 The models used at this stage include ER diagrams, data flow diagrams
(DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
 Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely
for modeling the requirements. DFD shows the flow of data through
a system. The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.
 Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the
requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use
the same definition and terminologies.
 Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.
 Requirements Specification: This step involves documenting
the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable
chunks.
 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.
4. Software Requirement Validation:

 After requirement specifications developed, the requirements

discussed in this document are validated. The user might demand
illegal, impossible solution or experts may misinterpret the needs.
Requirements can be the check against the following conditions -
 If they can practically implement
 If they are correct and as per the functionality and specially of
software
 If there are any ambiguities
 If they are full
 If they can describe
Requirements Validation Techniques

 Requirements reviews/inspections: Systematic manual analysis of the

requirements.
 Prototyping: Using an executable model of the system to check
requirements.
 Test-case generation: Developing tests for requirements to check testability.
 Automated consistency analysis: Checking for the consistency of structured
requirements descriptions.
 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.eno two requirements should conflict with each other.
 The requirements should be complete in every sense.
 The requirements should be practically achievable.
Software Requirement Management:

 Requirement management is the process of managing changing

requirements during the requirements engineering process and
system development.
 New requirements emerge during the process as business needs a
change, and a better understanding of the system is developed.
 The priority of requirements from different viewpoints changes
during development process.
 The business and technical environment of the system changes
during the development.
 Requirements Management: This step involves managing the
requirements throughout the software development life cycle,
including tracking and controlling changes, and ensuring that the
requirements are still valid and relevant.
 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.
Requirement Elicitation
 The aims of the requirements elicitation process are to understand the work
that stakeholders do and how they might use a new system to help support
that work. During requirements elicitation, software engineers work with
stakeholders to find out about the application domain, work activities, the
services and system features that stakeholders want, the required
performance of the system, hardware constraints, and so on.
 A process model of the elicitation and analysis process is shown in Figure
above. Each organization will have its own version or instantiation of this
general model, depending on local actors such as the expertise of the staff,
the type of system being developed, and the standards used.
 The process activities are:
 Requirements discovery and understanding:
This is the process of interacting with stakeholders of the system to discover
their requirements. Domain requirements from stakeholders and
documentation are also discovered during this activity.
 Requirements classification and organization:
This activity takes the unstructured collection of requirements, groups
related requirements and organizes them in to coherent clusters.
 Requirements prioritization and negotiation:
Inevitably, when multiple stakeholders are involved, requirements
will conflict. This activity is concerned with prioritizing
requirements and finding and resolving requirements conflicts
through negotiation. Usually, stakeholders have to meet to resolve
differences and agree on compromise requirements.
 Requirements documentation:
The requirements are documented and input into the next round of
the spiral. An early draft of the software requirements documents
may be produced at this stage, or the requirements may simply be
maintained informally on whiteboards, wikis, or other shared spaces.
Requirements elicitation Activities:

 Requirements elicitation includes the subsequent activities. Few of them are

listed below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system are going to
be applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements elicitation Methods:
1. Interviews:

 Objective of conducting an interview is to understand the customer’s

expectations from the software. It is impossible to interview every
stakeholder hence representatives from groups are selected based on their
expertise and credibility.
 Interviews maybe be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context free questions
may be asked to understand the problem.
 In structured interview, agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:

 It is a group technique
 It is intended to generate lots of new ideas hence providing a
platform to share views
 A highly trained facilitator is required to handle group bias and
group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
3. Facilitated Application Specification
Technique:

 It’s objective is to bridge the expectation gap –difference between

what the developers think they are supposed to build and what
customers think they are going to get.
 A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
 Part of the environment that surrounds the system
 Produced by the system
 Used by the system
 Each participant prepares his/her list, different lists are then
combined, redundant entries are eliminated, team is divided into
smaller sub-teams to develop mini-specifications and finally a draft
of specifications is written down using all the inputs from the
meeting.
The fundamental guidelines of FAST are given below:
 Arrange a meeting at a neutral site for developers as well as customers.
 Establishment of the rules for preparation and participation.
 Prepare as well as informal agenda that encourages free flow of ideas.
 Appoint a facilitator to manage the meeting. A facilitator may be a
developer or a customer and or an outside expert. Organize a definition flip
chart, mechanism-Board, worksheets and wall stickiest and so on.
 Participants must not criticize or debate.
4. Quality Function Deployment:
 In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the customer.
 3 types of requirements are identified –
 Normal requirements –In this the objective and goals of the proposed
software are discussed with the customer. Example –normal requirements
for a result management system may be entry of marks, calculation of
results, etc
 Expected requirements –These requirements are so
obvious that the customer need not explicitly state them.
Example –protection from unauthorized access.
 Exciting requirements –It includes features that are
beyond customer’s expectations and prove to be very
satisfying when present. Example –when unauthorized
access is detected, it should backup and shutdown all
processes.
 Quality Function Deployment (QFD)is process or set of tools used to
define the customer requirements for product and convert those
requirements into engineering specifications and plans such that the
customer requirements for that product are satisfied.
 QFD was developed in late 1960s by Japanese Planning Specialist
named Yoji Akao.
 QFD aims at translating Voice of Customer into measurable and detailed
design targets and then drives them from the assembly level down
through sub-assembly level, component level, and production process
levels.
 QFD helps to achieve structured planning of product by enabling
development team to clearly specify customer needs and expectations of
product and then evaluate each part of product systematically.
5. Use Case Approach:

 This technique combines text and pictures to provide a

better understanding of the requirements. The use
cases describe the ‘what’, of a system and not ‘how’.
Hence, they only give a functional view of the
system.The components of the use case design
includes three major things –Actor, Use cases, use case
diagram.
 Actor –It is the external agent that lies outside the system but
interacts with it in some way. An actor maybe a person,
machine etc.
 Use cases –They describe the sequence of interactions between
actors and the system. They capture who(actors) do
what(interaction) with the system. A complete set of use cases
specifies all possible ways to use the system.
 Use case diagram –A use case diagram graphically represents what happens
when an actor interacts with a system. It captures the functional aspect of
the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
When to Use a Use-Case Diagram?
 The use-case diagram is an extraordinary system's functionality
that is accomplished by a client. The objective of use-case
diagram is to capture the system's key functionalities and
visualize the interactions of different thinkings known as actors
with the use case. It is the basic use of use-case diagram.
 With the help of the use-case diagram, we can characterize the
system's main part and flow of work among them. In the use-
case, the implementation of details is hidden from external use,
and only the flow of the event is represented.
 Using use-case diagrams, we can detect the pre-and post-
conditions after communication with the actor. We can
determine these conditions using several test cases.
Generally, the use-cases diagram is
used for:
 Examining the system's requirements.
 Capturing the system's Functionalities.
 We use use-case diagram in order to modeling the
general idea behind the system.
 System's Forward and reverse engineering using
several test cases.
 Complex visual designing of software.
Tips for Drawing a Use-Case
Diagram
 It must be complete.
 It must be simple.
 The use-case diagram must show each and every interaction with
the use case.
 It is must that the use-case should be generalized if it is large.
 At least one system module must be defined in the use case
diagram.
 When there are number of actors or use-cases in the use-case
diagram, only the significant use-cases must be represented.
 The use-case diagrams must be clear and easy so that anyone can
understand them easily.
Importance of Use-Case Diagram
 Use Cases have been broadly used over the last few years.
There are various benefits of the use-case diagram:
 Use-case diagram provides an outline related to all
components in the system. Use-case diagram helps to
define the role of administrators, users, etc.
 The use-Case diagram helps to provide solutions and
answers to various questions that may pop up if you begin a
project unplanned.
 It helps us to define the needs of the users extensively and
explore how it will work.
Basic Use-Case Diagram Symbols
and Notations
 There are following use-case diagram symbols and
notations:
System:
With the help of the rectangle, we can draw the
boundaries of the system, which includes use-cases.
We need to put the actors outside the system's
boundaries.
Use-Case
 With the help of the Ovals, we can draw the use-cases.
With the verb we have to label the ovals in order to
represent the functions of the system.
Actors
 Actors mean the system's users. If one system is the
actor of the other system, then with the actor
stereotype, we have to tag the actor system.
Relationships
 With the simple line we can represent relationships between an actor
and use cases. For relationships between use-case, we use arrows which
are labelled either “extends“ or "uses".
 "extends“ relationship shows the alternative options under the specific
use case.
 The "uses“ relationship shows that single use case is required to
accomplish a job.
 In UML, various types of dependencies are defined between use cases.
In particular,<<include>>and<<extend>>.
 We use<<include>>dependency to comprise shared behavior from an
included use case into a base use case to use common behavior.
 We use<<extend>>dependency to include optional behavior from an
extended use-case into an extended usecase.
Actors
 The actor's name should be meaningful and relevant to the business
If the use-case interacting with the outside organization, then we
have to give the actor's name with the function instead of the
organization name, such as Airline company is better than the Pan
Air).
 Place inheriting actors below the parent actor We have to place the
inheriting actors below the parent actor because it makes the actors
more readable and easily highlights the use-cases, which are exact
for that actor.
 External Systems are actors If send-email is our use-case and when
the use-case interrelates with the email management software, then
in this case, the software is an actor to that specific user-case.
Use-Cases
 The name of the use-case begins with a verb. The use-case models
action, so the name of the use-case must start with a verb.
 The name of the use-case must be descriptive. The use-case is
created to provide more information to others who are looking at a
diagram, such as instead of "Print," "print Invoice is good.
 Put the use-cases to the right of the included use-cases. In order to
add clarity and enhance readability, we have to place the included
use-cases to the right of the invoking use-cases.
 Place inheriting use-case below the parent use-case. In order to
enhance the diagram's readability, we have to place the inheriting
use-case below the parent use-case.
Relationships
 When we are using <<extend>> arrow, points to the
base use-case.
 When we are using <<include>> then arrow points to
the comprised use-case.
 Actor and use-case relationship do not display arrows.
 <<extend>> may have an optional extension condition.
 <<include>> and <<extend>> both are shown as
dashed arrows.
Use-Case Examples
 Use-Case Example-Association Link
 In this use-case diagram, we show a group of use cases
for a system which means the relationship among the
use-cases and the actor.
Use-Case Example-Include
Relationship
 In order to add additional functionality that is not specified in
the base use-case, we use to include relationship. We use it to
comprise the general behavior from an included use case into a
base case so that we can support the reuse general behavior.
Use-Case Example-Extend
Relationship
 With the help of the extend relationship, we can show the system behavior
or optional functionality. We use <<extend>> relationship in order to
comprise optional behavior from an extending use-case in an extended use-
case. For example, the below diagram of the use-case displays an extend
connector and an extension point "Search".
Use-Case Example-Generalization
Relationship
 In the generalization relationship, the child use-case can inherit the meaning
and behavior of the parent use-case. The child use-case is able to override
and adds the parent's behavior. The below diagram is an example of
generalization relationship in which two generalization connector is
connected among three use-cases.
Use-Case Diagram-Student
Management System
Requirement analysis
 Requirement analysis is significant and essential activity after
elicitation. We analyze, refine, and scrutinize the gathered
requirements to make consistent and unambiguous requirements.
This activity reviews all requirements and may provide a graphical
view of the entire system. After the completion of the analysis, it is
expected that the understandability of the project may improve
significantly. Here, we may also use the interaction with the
customer to clarify points of confusion and to understand which
requirements are more important than others.
(i) Draw the context diagram:
 The context diagram is a simple model that defines the boundaries and
interfaces of the proposed systems with the external world. It identifies the
entities outside the proposed system that interact with the system. The
context diagram of student result management system is given below:
(ii) Development of a Prototype
(optional):
 One effective way to find out what the customer wants is to construct a prototype,
something that looks and preferably acts as part of the system they say they want.
 We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system
and increase the understanding of the requirements. When developers and users are
not sure about some of the elements, a prototype may help both the parties to take a
final decision.
 Some projects are developed for the general market. In such cases, the prototype
should be shown to some representative sample of the population of potential
purchasers. Even though a person who tries out a prototype may not buy the final
system, but their feedback may allow us to make the product more attractive to
others.
 The prototype should be built quickly and at a relatively low cost. Hence it will
always have limitations and would not be acceptable in the final system. This is an
optional activity.
(iii) Model the requirements:

 This process usually consists of various graphical representations of the

functions, data entities, external entities, and the relationships between
them. The graphical view may help to find incorrect, inconsistent, missing,
and superfluous requirements. Such models include the Data Flow diagram,
Entity-Relationship diagram, Data Dictionaries, State-transition diagrams,
etc.
(iv) Finalise the requirements:

 After modeling the requirements, we will have a better understanding of the

system behavior. The inconsistencies and ambiguities have been identified
and corrected. The flow of data amongst various modules has been
analyzed. Elicitation and analyze activities have provided better insight into
the system. Now we finalize the analyzed requirements, and the next step is
to document these requirements in a prescribed format.
Requirement Analysis Techniques
 1. Business Process Model and Notation (BPMN):

 Business Process Modeling Notation (BPMN) is a flow chart

method that models the steps of a planned business process
from end to end. A key to Business Process Management, it
visually depicts a detailed sequence of business activities and
information flows needed to complete a process.
 Its purpose is to model ways to improve efficiency, account for
new circumstances or gain competitive advantage. The method
has been undergoing a standardization push in the past few
years and is now often called by a slightly different name:
Business Process Model and Notation, still using the BPMN
acronym.
2. Flowcharts

 Flowcharts depict sequential flow and control logic of

a related set of activities. They are useful for both
technical and non-technical members.
3. Gantt Charts

 Gantt Charts provide a visual representation of tasks

along with their scheduled timelines. They help
business analysts visualize the start and end dates of
all the tasks in a project.
4.GAP ANALYSIS
 The easy-to-use methodology of Fit-GAP processing enables the
accurate identification of where your current software, or a proposed
new system, will fit or does not fit your organization's needs. In the
context of software requirements identification, Fit/GAP analysis is
the formal process of identifying how well a specific organization's
currentor planned system fits that organization's requirements on a
day-to-day operational basis. In other words, WHERE are problems
occuring, WHY are they occuring, and HOW BAD are they?
 A scenario in which the system does NOT Fit a specific
requirementis known as a GAP. The term GAP is derived from the
early fit asessment terms Good,Average, or Poor.
Software Requirements Specification

 SRS is developed which describes

requirements of software that may
include changes and modifications that
is needed to be done to increase quality
of product and to satisfy customer’s
demand.
Introduction :
 Purpose of this Document –At first, main aim of why this
document is necessary and what’s purpose of document is
explained and described.
 Scope of this document –In this, overall working and main
objective of document and what value it will provide to
customer is described and explained. It also includes a
description of development cost and time required.
 Overview –In this, description of product is explained. It’s
simply summary or overall review of product.
Introduction :
 General description :In this, general functions of product which
includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of
user community.
 Functional Requirements :In this, possible outcome of software
system which includes effects due to operation of program is fully
explained. All functional requirements which may include
calculations, data processing, etc. are placed in a ranked order.
 Interface Requirements :In this, software interfaces which mean
how software program communicates with each other or users either
in form of any language, code, or message are fully described and
explained. Examples can be shared memory, data streams, etc.
Introduction :
 Performance Requirements :In this, how a software system
performs desired functions under specific condition is explained. It
also explains required time, required memory, maximum error rate,
etc.
 Design Constraints :In this, constraints which simply means
limitation or restriction are specified and explained for design team.
Examples may include use of a particular algorithm, hardware and
software limitations, etc.
 Non-Functional Attributes :In this, non-functional attributes are
explained that are required by software system for better
performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity,
Scalability capacity, etc.
Introduction :

 Preliminary Schedule and Budget :In this, initial version and budget of
project plan are explained which include overall time duration required and
overall cost required for development of project.
 Appendices :In this, additional information like references from where
information is gathered, definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained.
SRS Document
 The SRS is a specification for a specific software product, program,
or set of applications that perform particular functions in a specific
environment. It serves several goals depending on who is writing it.
First, the SRS could be written by the client of a system. Second, the
SRS could be written by a developer of the system. The two methods
create entirely various situations and establish different purposes for
the document altogether. The first case, SRS, is used to define the
needs and expectation of the users. The second case, SRS, is written
for various purposes and serves as a contract document between
customer and developer.
Features of a good SRS document:

 Correctness: User review is used to provide the accuracy of

requirements stated in the SRS. SRS is said to be perfect if it covers
all the needs that are truly expected from the system.
 Completeness: The SRS is complete if, and only if, it includes the
following elements:
 (1).All essential requirements, whether relating to functionality,
performance, design, constraints, attributes, or external interfaces.
 (2).Definition of their responses of the software to all realizable
classes of input data in all available categories of situations.
 (3) Full labels and references to all figures, tables, and diagrams in
the SRS and definitions of all terms and units of measure.
 3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in the
SRS:
 1. The specified characteristics of real-world objects may conflicts.
For example,
 (a) The format of an output report may be described in one requirement as tabular but
in another as textual.
 (b) One condition may state that all lights shall be green while another states that all
lights shall be blue.

 2. There may be a reasonable or temporal conflict between the two specified actions.
For example,
 (a) One requirement may determine that the program will add two inputs, and another
may determine that the program will multiply them.
 (b) One condition may state that "A" must always follow "B," while other requires that
"A and B" co-occurs.
 3. Two or more requirements may define the same real-world object but use
different terms for that object.
For example,
a program's request for user input may be called a "prompt" in one requirement's and a "cue"
in another. The use of standard terminology and descriptions promotes consistency.
 4. Unambiguousness: SRS is unambiguous when every fixed requirement
has only one interpretation. This suggests that each element is uniquely
interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it
is clear and simple to understand.
 5. Ranking for importance and stability: The SRS is ranked for
importance and stability if each requirement in it has an identifier to indicate
either the significance or stability of that particular requirement.
 Typically, all requirements are not equally important. Some prerequisites
may be essential, especially for life-critical applications, while others may
be desirable. Each element should be identified to make these differences
clear and explicit. Another way to rank requirements is to distinguish classes
of items as essential, conditional, and optional.
 6. Modifiability: SRS should be made as modifiable as likely and
should be capable of quickly obtain changes to the system to some
extent. Modifications should be perfectly indexed and cross-
referenced.
 7. Verifiability: SRS is correct when the specified requirements can
be verified with a cost-effective system to check whether the final
software meets those requirements. The requirements are verified
with the help of reviews.
 8. Traceability: The SRS is traceable if the origin of each of the
requirements is clear and if it facilitates the referencing of each
condition in future development or enhancement documentation.
 9. Design Independence: There should be an option to select from
multiple design alternatives for the final system. More specifically,
the SRS should not contain any implementation details.
 10. Testability :An SRS should be written in such a method that it is
simple to generate test cases and test plans from the report.
 11. Understandable by the customer: An end user may be an expert
in his/her explicit domain but might not be trained in computer
science. Hence, the purpose of formal notations and symbols should
be avoided too as much extent as possible. The language should be
kept simple and clear.
 12. The right level of abstraction: If the SRS is written for the
requirements stage, the details should be explained explicitly.
Whereas, for a feasibility study, fewer analysis can be used. Hence,
the level of abstraction modifies according to the objective of the
SRS.
Properties of a good SRS document
 Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Verbose and irrelevant descriptions decrease readability
and also increase error possibilities.
 Structured: It should be well-structured. A well-structured document is simple to
understand and modify. In practice, the SRS document undergoes several revisions
to cope up with the user requirements. Often, user requirements evolve over a period
of time. Therefore, to make the modifications to the SRS document easy, it is vital to
make the report well-structured.
 Black-box view: It should only define what the system should do and refrain from
stating how to do these. This means that the SRS document should define the
external behavior of the system and not discuss the implementation issues. The SRS
report should view the system to be developed as a black box and should define the
externally visible behavior of the system. For this reason, the SRS report is also
known as the black-box specification of a system.
 Conceptual integrity: It should show conceptual integrity so that the reader can
merely understand it. Response to undesired events: It should characterize
acceptable responses to unwanted events. These are called system response to
exceptional conditions.
 Verifiable: All requirements of the system, as documented in the SRS document,
should be correct. This means that it should be possible to decide whether or not
requirements have been met in an implementation.
Requirement Validation
 Requirements validation is the process of checking that requirements define
the system that the customer really wants. It overlaps with elicitation and
analysis, as it is concerned with finding problems with the requirements.
Requirements validation is critically important because errors in a
requirements document can lead to extensive rework costs when these
problems are discovered during development or after the system is in
service.
 The cost of fixing a requirements problem by making a system change is
usually much greater than repairing design or coding errors. A change to the
requirements usually means that the system design and implementation
must also be changed. Furthermore, the system must then be retested.
During the requirements validation process, different types of checks should be carried
out on the requirements in the requirements document. These checks include:

• Validity checks: These check that the requirements reflect the real needs of
system users. Because of changing circumstances, the user requirements
may have changed since they were originally elicited.
 Consistency checks: Requirements in the document should not conflict.
That is, there should not be contradictory constraints or different
descriptions of the same system function.
 Completeness checks: The requirements document should include
requirements that define all functions and the constraints intended by the
system user.
 Realism checks: By using knowledge of existing technologies, the requirements
should be checked to ensure that they can be implemented within the proposed
budget for the system. These checks should also take account of the budget and
schedule for the system development.
 Verifiability: To reduce the potential for dispute between customer and contractor,
system requirements should always be written so that they are verifiable. This means
that you should be able to write a set of tests that can demonstrate that the delivered
system meets each specified requirement.
 Requirements validation is the process of checking that requirements are
defined for development, and defining the system that the customer really
wants. To check issues related to requirements, we perform requirements
validation. Requirements validation usually helps us detect errors at an early
stage of product development so that it does not result in excessive rework
when detected later in the software development life cycle. we will look at
what Requirements Validation is, its Process, and various Tools used for
Requirements Validation.
Validation Vs Verification
 Validation is a process used for checking if the system is up to the mark or
not. Validation answers the question, “Are we building the right system?” It
is about testing and validating the system and seeing if the system we built
is right or not and if it meets the customer’s expectations or not. Various
methods that are used to validate the system include black-box testing,
white-box testing, integration testing, and unit testing. Validation always
comes after verification. We usually use requirements validation to check
errors at the initial development phase as the error may increase excessive
rework when detected later in the development process. Requirements
validation is important as it helps us to validate that the requirements match
the ideal rules and standards.
 Verification is a process used for checking if the system achieves its
expected goals or not without any bugs or issues. Verification answers the
question, “Are we building the product right?” It is about testing and
verifying if the system meets its requirements without any problems.
Various methods that are used to verify the system include reviews,
walkthroughs, inspections, and desk checkings. Verification is a manual
process done before validation.
Validation Techniques:
 Checks–While checking the requirements, we proofread the requirements
documents to ensure that no elicitation notes are missed out. During these
checks, we also check the traceability level between all the requirements.
For this, the creation of a traceability matrix is required. This matrix ensures
that all the requirements are being considered seriously and everything that
is specified is justified. We also check the format of requirements during
these checks. We see if the requirements are clear and well-written or not.
 Prototyping–This is a way of building a model or simulation of the system
that is to be built by the developers. This is a very popular technique for
requirements validation among stakeholders and users as it helps them to
easily identify the problems. We can just reach out to the users and
stakeholders and get their feedback.
 Test Design–During test designing, we follow a small procedure where
we first finalize the testing team, then build a few testing scenarios.
Functional tests can be derived from the requirements specification
itself where each requirement has an associated test. On the contrary, the
non-functional requirements are hard to test as each test has to be traced
back to its requirement. The aim of this is to figure out the errors in the
specification or the details that are missed out.
 Requirements Review–During requirement review, a group of
knowledgeable people analyze the requirements in a structured
and detailed manner and identify the potential problems. After
that, they gather up to discuss the issues and figure out a way to
address the issues. A checklist is prepared consisting of various
standards and the reviewers check the boxes to provide a formal
review. After that, a final approval sign-off is done.
verification and validation (V&V)

 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.
Requirements management
 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.
 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.
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.