Requirements Engineering?

A systematic and strict approach to the definition, creation, and verification of requirements for a
software system is known as requirements engineering. To guarantee the effective creation of a
software product, the requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of stakeholders.
Requirements Engineering Process

Requirements Engineering Process

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and
validation
5. Requirements management
1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below. Among these
Economic Feasibility Study is the most important part of the feasibility analysis and the Legal
Feasibility Study is less considered feasibility analysis.
1. Technical Feasibility: In Technical Feasibility current resources both hardware software along
required technology are analyzed/assessed to develop the project. This technical feasibility
study reports whether there are correct required resources and technologies that will be
used for project development. Along with this, the feasibility study also analyzes the
technical skills and capabilities of the technical team, whether existing technology can be
used or not, whether maintenance and up-gradation are easy or not for the chosen
technology, etc.
2. Operational Feasibility: In Operational Feasibility degree of providing service to
requirements is analyzed along with how easy the product will be to operate and maintain
after deployment. Along with this other operational scopes are determining the usability of
the product, Determining suggested solution by the software development team is
acceptable or not, etc.
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are
analyzed. This means under this feasibility study a detailed analysis is carried out will be cost
of the project for development which includes all required costs for final development
hardware and software resources required, design and development costs operational costs,
and so on. After that, it is analyzed whether the project will be beneficial in terms of finance
for the organization or not.
4. Legal Feasibility: In legal feasibility, the project is ensured to comply with all relevant laws,
regulations, and standards. It identifies any legal constraints that could impact the project
and reviews existing contracts and agreements to assess their effect on the project’s
execution. Additionally, legal feasibility considers issues related to intellectual property, such
as patents and copyrights, to safeguard the project’s innovation and originality.
 5. Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to determine if
it is realistic and achievable. Significant milestones are identified, and deadlines are
established to track progress effectively. Resource availability is assessed to ensure that the
necessary resources are accessible to meet the project schedule. Furthermore, any time
constraints that might affect project delivery are considered to ensure timely completion.
This focus on schedule feasibility is crucial for the successful planning and execution of a
project.
2. 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 the same type, standards, 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.
Several techniques 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.
3. Requirements Specification
This activity is used to produce formal software requirement models. All the requirements including
the functional as well as the non-functional requirements and the constraints are specified by these
models in totality. During specification, more knowledge about the problem may be required which
can again trigger the elicitation process. The models used at this stage include ER diagrams, data flow
diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
Requirements specification is the process of 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.
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.
Several types of requirements are commonly specified in this step, including
1. 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.
2. 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.

NOTE –
Functional and Non-functional requirements. functional requirements define the specific
behavior or functions of a system. In contrast, non-functional requirements specify how the
system performs its tasks, focusing on attributes like performance, security, scalability, and
usability.

3. Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software system
to be considered complete and ready for release.
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. 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 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:
 1. The requirements should be consistent with all the other requirements i.e. no two
requirements should conflict with each other.
2. The requirements should be complete in every sense.
3. 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.
1. Verification is 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.
2. 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.
3. Verification and Validation 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. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing, and
agreeing on the requirement and controlling the communication with relevant stakeholders. This
stage takes care of the changing nature of requirements. It should be ensured that the SRS is as
modifiable as possible to incorporate changes in requirements specified by the end users at later
stages too. Modifying 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.
Several key activities are involved in requirements management, including:
1. 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.
2. Version control: This involves keeping track of different versions of the requirements
document and other related artifacts.
 3. Traceability: This involves linking the requirements to other elements of the development
process, such as design, testing, and validation.
4. Communication: This involves ensuring that the requirements are communicated effectively
to all stakeholders and that any changes or issues are addressed promptly.
5. 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.
Tools Involved in Requirement Engineering
 Observation report
 Questionnaire ( survey, poll )
 Use cases
 User stories
 Requirement workshop
 Mind mapping
 Roleplaying
 Prototyping
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 an 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
 It 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.