Chapter 2.

2
Chapter 2.2

Requirement Engineering Process

Requirement engineering is the systematic process of eliciting, analyzing, documenting, validating, and
managing the requirements of a software system throughout its lifecycle. The requirement engineering
process typically involves the following stages:

1. Requirements Elicitation:

a. Identify stakeholders: Identify and involve all relevant stakeholders, including end-users,
customers, managers, domain experts, and other interested parties.

b. Gather requirements: Employ various techniques such as interviews, surveys, workshops,

observations, and document analysis to elicit requirements from stakeholders.

c. Document requirements: Document the gathered requirements in a clear, concise, and

unambiguous manner using appropriate documentation formats.

2. Requirements Analysis:

a. Analyze requirements: Analyze and understand the implications, dependencies, and

constraints of the elicited requirements.

b. Model requirements: Model the requirements using techniques such as use cases, user
stories, data flow diagrams, entity-relationship diagrams, or formal specification
languages to represent the system's behavior and structure.

c. Prioritize requirements: Prioritize requirements based on their importance, urgency, and

impact on the software system and its stakeholders.

d. Resolve conflicts: Resolve conflicts and inconsistencies among requirements to ensure

that they are coherent and compatible with each other.

3. Requirements Specification:

a. Document requirements: Formalize the analyzed requirements into a Software

Requirements Specification (SRS) document, which serves as a formal agreement
between stakeholders regarding the scope and functionality of the software system.

b. Review and validate: Review and validate the SRS document with stakeholders to ensure
that it accurately captures their needs and expectations.

4. Requirements Verification and Validation:

 a. Verify requirements: Ensure that the requirements specified in the SRS document are
complete, consistent, and feasible by performing reviews, inspections, and walkthroughs.

b. Validate requirements: Validate the requirements with stakeholders to ensure that they
meet their intended needs and objectives by demonstrating prototypes, conducting user
acceptance testing, and soliciting feedback.

5. Requirements Management:

a. Baseline requirements: Establish a baseline version of the SRS document that serves as
the agreed-upon reference for subsequent development activities.

b. Manage changes: Manage changes to the requirements throughout the software

development lifecycle using a formal change control process to ensure that any
modifications are properly evaluated, documented, and communicated to stakeholders.

c. Traceability: Establish traceability relationships between requirements and other

artifacts, such as design documents, test cases, and code, to ensure alignment and
consistency throughout the development process.

6. Requirements Maintenance:

a. Maintain requirements: Continuously monitor and update the requirements as needed

to reflect changes in stakeholder needs, project scope, or external factors affecting the
software system.

b. Version control: Maintain version control of the SRS document and associated artifacts
to track changes and facilitate collaboration among stakeholders.

Requirement Validation
Requirement validation is the process of ensuring that the requirements specified for a software system
are correct, complete, consistent, and meet the needs of the stakeholders. It involves verifying that the
requirements accurately represent the desired behavior and functionality of the software system before
proceeding with its development. Requirement validation helps to mitigate risks associated with building
the wrong system or delivering a product that does not meet stakeholder expectations. Here are some
key aspects of requirement validation:

1. Verification vs. Validation:

a. Verification ensures that the requirements are well-defined, consistent, and internally
correct. It focuses on checking whether the requirements meet specified criteria and
standards.

b. Validation ensures that the requirements represent the actual needs and expectations of
the stakeholders. It involves confirming that the requirements address the right
problems and deliver value to the stakeholders.

2. Techniques for Requirement Validation:

 a. Prototyping: Building prototypes or mockups of the software system to demonstrate its
functionality and gather feedback from stakeholders.

b. Reviews and Inspections: Conducting formal reviews or inspections of the requirements

documents to identify errors, inconsistencies, and ambiguities.

c. Walkthroughs: Walking through the requirements with stakeholders to ensure mutual

understanding and agreement on the desired system behavior.

d. User Acceptance Testing (UAT): Involving end-users or representatives to test the

software against the requirements and provide feedback on its usability and suitability.

e. Simulation and Modeling: Using simulation tools or models to simulate the behavior of
the software system and validate its compliance with the specified requirements.

f. Traceability Analysis: Analyzing traceability relationships between requirements and

other artifacts to ensure that all requirements are adequately addressed and validated
throughout the development process.

3. Validation Criteria:

a. Correctness: Ensuring that the requirements accurately reflect the needs and
expectations of the stakeholders.

b. Completeness: Verifying that all relevant requirements are included and nothing
essential has been omitted.

c. Consistency: Checking for conflicts, redundancies, or contradictions between different

requirements.

d. Feasibility: Assessing whether the requirements are feasible to implement within the
constraints of the project, including technical, resource, and schedule constraints.

e. Relevance: Confirming that the requirements are relevant to the objectives and scope of
the software project.

4. Iterative Process:

a. Requirement validation is often an iterative process that involves multiple rounds of

review, feedback, and refinement to ensure that the requirements evolve and improve
over time.

b. Stakeholder involvement throughout the validation process is crucial to address any

concerns or issues early and to maintain alignment with stakeholder needs.

Requirement Management
Requirement management is the process of systematically identifying, documenting, organizing,
prioritizing, tracing, and controlling changes to requirements throughout the software development
lifecycle. Effective requirement management ensures that the software product meets the needs and
expectations of stakeholders while maintaining alignment with project goals and constraints. Here are
the key components and activities involved in requirement management:

1. Requirement Identification:

a. Identify stakeholders: Identify all stakeholders who have a vested interest in the
software project, including end-users, customers, managers, domain experts, and other
relevant parties.

b. Gather requirements: Employ various techniques such as interviews, surveys, workshops,

observations, and document analysis to elicit requirements from stakeholders.

c. Document requirements: Document the gathered requirements in a clear, concise, and

unambiguous manner using appropriate documentation formats, such as a Software
Requirements Specification (SRS) document.

2. Requirement Analysis and Prioritization:

a. Analyze requirements: Analyze and understand the implications, dependencies, and

constraints of the elicited requirements.

b. Model requirements: Model the requirements using techniques such as use cases, user
stories, data flow diagrams, or formal specification languages to represent the system's
behavior and structure.

c. Prioritize requirements: Prioritize requirements based on their importance, urgency, and

impact on the software system and its stakeholders.

3. Requirement Traceability:

a. Establish traceability relationships: Establish traceability links between requirements and

other artifacts, such as design documents, test cases, and code, to ensure alignment and
consistency throughout the development process.

b. Traceability matrix: Maintain a traceability matrix that maps requirements to

corresponding design elements, test cases, and other project artifacts to facilitate
impact analysis and change management.

4. Requirement Validation and Verification:

a. Verify requirements: Ensure that the requirements specified in the SRS document are
complete, consistent, and feasible by performing reviews, inspections, and walkthroughs.

b. Validate requirements: Validate the requirements with stakeholders to ensure that they
meet their intended needs and objectives by demonstrating prototypes, conducting user
acceptance testing, and soliciting feedback.

5. Requirement Change Management:

a. Manage changes: Implement a formal change control process to manage changes to the
requirements throughout the software development lifecycle.
 b. Assess impacts: Assess the impacts of proposed changes on project scope, schedule,
budget, and other constraints before approving or rejecting them.

c. Communicate changes: Communicate approved changes to stakeholders and update

relevant project documentation, including the SRS document and traceability matrix.

6. Requirement Maintenance:

a. Maintain requirements: Continuously monitor and update the requirements as needed

to reflect changes in stakeholder needs, project scope, or external factors affecting the
software system.

b. Version control: Maintain version control of the SRS document and associated artifacts
to track changes and facilitate collaboration among stakeholders.