Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.

S,Asst Prof

UNIT-2 REQUIREMENTS ENGINEERING:

REQUIREMENTS ENGINEERING: Functional and non-functional requirements;
Software requirements document; Requirement’s specification; Requirements
engineering processes; Requirement’s elicitation and analysis; Requirement’s
validation; Requirements management.
Requirement Engineering The process to gather the software requirements
from client, analyze, and document them is known as requirement
engineering.
Functional Requirements 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 - • Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.
Non-Functional Requirements Requirements, which are not related to
functional aspect of software, fall into this category. They are implicit or
expected characteristics of software, which users make assumption of.
Non-functional requirements include - • Security • Logging • Storage •
Configuration • Performance • Cost • Interoperability • Flexibility • Disaster
recovery • Accessibility

functional Requirements Non-functional requirements

Functional requirements help to understand They help to understand the

the functions of the system. system's performance.
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

Functional requirements are mandatory. While non-functional requirements

are not mandatory.

They are easy to define. They are hard to define.

They describe what the product does. They describe the working of
product.

It concentrates on the user's requirement. It concentrates on the expectation

and experience of the user.

It helps us to verify the software's It helps us to verify the software's

functionality. performance.

These requirements are specified by the user. These requirements are specified by
the software developers, architects,
and technical persons.

There is functional testing such as API testing, There is non-functional testing such
system, integration, etc. as usability, performance, stress,
security, etc.

Examples of the functional requirements are - Examples of the non-functional

Authentication of a user on trying to log in to requirements are -
the system. The background color of the screens
should be light blue.

These requirements are important to system These are not always the important
operation. requirements, they may be
desirable.

Completion of Functional requirements While system will not work only with
allows the system to perform, irrespective of non-functional requirements.
meeting the non-functional requirements.
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

Software Requirements Document

The software requirements document (SRD) describes the business or

organization’s understanding of the end user’s (typically the client’s) needs.

The SRD functions as a blueprint for managing the scope of a project, it

ultimately only defines functional and nonfunctional requirements for a
system. The document does not outline design or technology solutions. Those
decisions are made later by the developers.

A well-written SRD should:

• Break the problem into manageable parts.

• Serve as a reference for testing and validation.
• Informthe design specifications (i.e., the SRD needs to include sufficient
information on the requirements of the software in order to render an
effective design).
• Provide feedback to the client (end user).

The SRD demonstrates to the client that your organization understands the
issue they want to be solved and how to address those problems through
software solutions. Because clients are often direct stakeholders, it is
especially important to draft the documentation clearly in layman’s terms
(avoiding technical jargon).

Software Requirement Specification

Software Requirement Specification (SRS) Format as the name suggests, is a

complete specification and description of requirements of the software that
need to be fulfilled for the successful development of the software system.
These requirements can be functional as well as non-functional depending
upon the type of requirement. The interaction between different customers
and contractors is done because it is necessary to fully understand the needs
of customers.
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

The SRS document is very crucial for software development, it is typically

expected to be:

• Correct

User review is done to check that the requirements listed in the SRS are
proper. SRS is correct if it meets all of the system's requirements.

• Unambiguous

The SRS is considered unambiguous or precise if all requirements have only

one interpretation. Some methods for avoiding ambiguity incorporate the use
of modeling approaches such as ER diagrams, thorough reviews and buddy
checks, and so on.

• Complete

Definition of the software's reactions to all realizable input data classes

in all possible scenario categories.

1. Complete labeling and references to all figures, tables, and diagrams in

the SRS, as well as definitions of all terms and units of measurement.

• Consistent

Two or more requirements may define the same real-world object but
refer to it differently. Consistency is promoted by the use of uniform
terminology and descriptions.

• Verifiable

We should be able to verify the specified requirements with a cost-effective

approach to check whether the final software meets those requirements. The
requirements are verified with the help of software reviews.

• Modifiable/Adaptable
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

SRS should be made as adaptable as possible, with the ability to make changes
to the system fast. In addition, changes should be fully indexed and cross-
referenced.

• Traceable

The SRS is traceable if the origin of each requirement is clear and if it facilitates
the referencing of each condition in the future. Traceability is classified into
two types:

1. Backward Traceability: This is contingent on each need explicitly citing

its source in previous publications.
2. Forward Traceability: This depends on each SRS element having a unique
name or reference number. When the software product enters the
operation and maintenance phase, forward traceability of the SRS
becomes especially important. As the code and design documents are
changed, it is vital to determine the entire range of requirements that
may be affected by those changes.

• Design Independent

The final system should include the option of selecting from numerous design
possibilities. More particularly, no implementation details should be included
in the SRS.

• Testable

An SRS document should be constructed so that it is simple to build test cases

and test plans.

• Abstract to the Right Level

The details should be explained explicitly if the SRS is written for the
requirements phase. A feasibility study, on the other hand, can employ fewer
details. As a result, the level of abstraction varies depending on the SRS's
objective.
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

• Customer-friendly

An end user may not be an expert in software engineering. As a result, formal

notations and symbols should be avoided as far as possible and practicable.
Instead, the language should be simple and straightforward.

Requirements engineering processes; Requirement’s elicitation and

analysis Requirement’s validation; Requirements management.

Requirements engineering is the process of identifying, eliciting, analyzing,

specifying, validating, and managing the needs and expectations of
stakeholders for a software system. The requirements engineering process is
an iterative process that involves several steps, including:
• 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.
• 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.
• Requirements Validation: This step involves checking that the
requirements are complete, consistent, and accurate. It also
involves checking that the requirements are testable and that they
meet the needs and expectations of stakeholders.
• Requirements Management: This step involves managing the
requirements throughout the software development life cycle,
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

including tracking and controlling changes, and ensuring that the

requirements are still valid and relevant.
• The Requirements Engineering process 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.
Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining service
provided by the system. it is the disciplined application of proven principle ,
methods ,tools and notations to describe a proposed system’s intended
behavior and its associated constraints.
Tools involved in requirement engineering:
• observation report
• Questionnaire ( survey , poll )
• Use cases
• User stories
• Requirement workshop
• Mind mapping
• Role playing
• Prototyping
Requirements Engineering Process consists of the following main
activities:
• Requirements elicitation
• Requirements specification
• Requirements verification and validation
• Requirements management

Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project
domain and requirements. The various sources of domain knowledge include
customers, business manuals, the existing software of same type, standards
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

and other stakeholders of the project. The techniques used for requirements
elicitation include interviews, brainstorming, task analysis, Delphi technique,
prototyping, etc. Some of these are discussed here. Elicitation does not
produce formal models of the requirements understood. Instead, it widens
the domain knowledge of the analyst and thus helps in providing input to the
next stage.
Requirements elicitation is the process of gathering information about the
needs and expectations of stakeholders for a software system. This is the first
step in the requirements engineering process and it is critical to the success
of the software development project. 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.
•
Requirements verification and validation:
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
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

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.
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

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:
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.
Seshadripuram Degree College,S/W Engg.UNIT-2 NEP Sonia.S,Asst Prof

• 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.