P24CS1:A

Department of Computer Science (Shift- I)

James Daniel E
Bishop Heber College
 UNIT- 2
Software
Requirements
What Is Requirements Engineering?
“The hardest single part of building a software system is
deciding what to build. No other part of the conceptual work
is as difficult as establishing the detailed technical
requirements, including all the interfaces to people, to
machines, and to other software systems. No part of the
work so cripples the resulting systems if done wrong. No other
part is more difficult to rectify later.”
Frederick P. Brooks, American Computer Architect
 What Is Requirements Engineering?
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.
 Requirements Engineering
It focuses on assessing if the system is useful to the
business (feasibility study), discovering requirements
(elicitation and analysis), converting these requirements
into some standard format (specification), and checking
that the requirements define the system that the
customer wants (validation).
Requirements Engineering
Requirements Engineering
Feasibility Study
Requirement Elicitation and Analysis
Software Requirement Specification
Software Requirement Validation
Software Requirement Management
Types Of Requirements
Functional Requirements
Non- functional Requirements
Constraints
User Requirements
System Requirements
1. Functional Requirements
1.
Functional requirements define the specific behavior
or functions of the system.
They describe what the system should do and outline
the actions that the system must perform in
response to inputs or conditions.
Functional requirements are typically expressed in
the form of “shall” statements and focus on user
interactions and system operations.
Examples of Functional Requirements:
User Authentication: The system shall allow users to
log in using a username and password.
Data Entry: The system shall provide a form for users
to enter their contact information.
Report Generation: The system shall generate
monthly financial reports in PDF format.
Email Notifications: The system shall send email
notifications to users when their account balance
falls below a specified threshold.
2. Non- Functional Requirements
Non-functional requirements define the
system's quality attributes and describe how
the system performs a function rather than
the function itself.
These requirements often pertain to the
system's performance, usability, reliability,
security, and other operational aspects.
Categories of Non- Functional Requirements:
Performance: Specifies the speed, response time, and throughput of the system.
Example: The system shall process 100 transactions per second.
Security: Defines the measures that protect the system from unauthorized access
and data breaches.
Example: The system shall use 256-bit encryption for data storage and transmission.
Usability: Describes the ease with which users can learn and use the system.
Example: The system shall provide an intuitive user interface with clear navigation.
Reliability: Specifies the system's availability and fault tolerance.
Example: The system shall have 99.9% uptime and recover from failures within 5
minutes.
Scalability: Describes the system's ability to handle increased load or expand.
Example: The system shall support up to 10,000 concurrent users without performance
degradation.
 3. Constraints
Constraints are restrictions or limitations that
affect the design and implementation of the
system. These can be external factors, such as
regulatory requirements, or internal factors, like
budget and time constraints.
Constraints must be considered to ensure the
system adheres to necessary guidelines and
operates within specified boundaries.
 Examples of Constraints:
Regulatory Compliance: The system shall comply with GDPR
(General Data Protection Regulation) for data privacy.
Hardware Limitations: The system shall be designed to run
on existing hardware infrastructure with no additional
hardware costs.
Budget Constraints: The project shall not exceed a budget
of $500,000.
Time Constraints: The system shall be delivered within six
months from the start date.
 4. User Requirements
User requirements describe what the end-users
need or expect from the system. These requirements
are typically expressed in a user-friendly language
and focus on the goals and tasks that users want to
achieve with the system. User requirements provide
a high-level overview of the functionalities and
features from the user's perspective.
 Examples
E-commerce Website:
1. Users shall be able to search for products using keywords.
1.
2. Users shall be able to view product details, including images, descriptions, and
2.
prices.
3. Users shall be able to add items to a shopping cart and proceed to checkout.
3.
4. Users shall be able to track their order status after making a purchase.
4.
Banking Application:
1. Users shall be able to view their account balance and transaction history.
1.
2. Users shall be able to transfer funds between their accounts.
2.
3. Users shall be able to pay bills online.
3.
4. Users shall receive notifications for account activities, such as withdrawals
4.
and deposits.
 5. System Requirements
System requirements provide a detailed and technical description of the
system's functionalities, performance, and constraints. These requirements
are derived from user requirements and specify how the system will fulfill the
user needs. System requirements are intended for developers, designers, and
engineers who will build the system.

Characteristics
Detailed and technical: Written in a technical language that developers and engineers
understand.
Solution-oriented: Focus on how the system will achieve the specified user requirements.
Structured and precise: Often documented in a Software Requirements Specification
(SRS) and include functional and non-functional requirements.
 Examples
E-commerce Website:
The system shall provide a search functionality that indexes product names, descriptions,
and tags.
The system shall display product details retrieved from the database, including images,
descriptions, and prices.
The system shall allow users to add items to a shopping cart, update quantities, and remove
items.
The system shall process orders and generate order confirmation emails to users.
Banking Application:
The system shall provide real-time account balance updates by querying the database.
The system shall implement fund transfer functionality using secure API endpoints.
The system shall support bill payments through integration with third-party billing services.
The system shall send notifications via SMS and email using an external notification service.
 Feasibility Studies
A feasibility study assesses the practicality of a proposed
project or system. It determines whether the project is viable
and worth pursuing.
This involves evaluating various aspects of the project to
identify potential obstacles and ensure that the project can be
successfully completed within the constraints of time,
budget, and resources.
Conducting a feasibility study helps organizations make
informed decisions, avoid costly mistakes, and plan
effectively.
Feasibility Studies
Technical Feasibility
Economic Feasibility
Legal Feasibility
Operational Feasibility
 Technical Feasibility
Technical feasibility evaluates the technical
resources and expertise needed to complete the
project. It involves assessing whether the current
technology and technical skills are sufficient to meet
the project requirements and if new technology or
skills are necessary.
 Technical Feasibility
Technology Requirements: Availability and suitability of hardware,
software, and tools.
Technical Expertise: Skills and experience of the team members.
Infrastructure: Adequacy of existing infrastructure to support the
project.
Development Risks: Potential technical challenges and risks.

For a new mobile banking application, technical feasibility would

involve evaluating whether the existing IT infrastructure can
support the application, if the development team has the
necessary skills to build it, and whether the chosen technology
stack is appropriate.
 Economic Feasibility
Economic feasibility assesses the cost-effectiveness of the project.
It involves analyzing the projected costs and benefits to determine if
the project is financially viable and provides a good return on
investment (ROI).

For a proposed e-commerce platform, economic feasibility

would involve estimating the costs of development, marketing,
and maintenance, and comparing these costs to the expected
increase in sales and customer base to determine if the project
is financially justified.
 Economic Feasibility
Cost Analysis: Estimation of initial and ongoing costs,
including development, operation, and maintenance.
Benefit Analysis: Calculation of expected benefits, such
as increased revenue, cost savings, and improved
efficiency.
Financial Risks: Potential financial risks and
uncertainties.
ROI: Comparison of costs and benefits to assess the
project's overall profitability.
 Legal Feasibility
Legal feasibility examines any legal constraints or
requirements that may impact the project. This involves
ensuring that the project complies with relevant laws,
regulations, and contractual obligations.

For a health information system, legal feasibility would

involve ensuring compliance with healthcare regulations
like HIPAA (Health Insurance Portability and
Accountability Act) to protect patient data and privacy.
 Legal Feasibility
Regulatory Requirements: Compliance with industry
regulations and standards.
Legal Obligations: Adherence to existing contracts and
agreements.
Intellectual Property: Protection of intellectual
property rights.
Data Privacy: Compliance with data protection and
privacy laws.
 Operational Feasibility
Operational feasibility considers how the proposed system will
operate within the organization. It involves evaluating the
project's impact on current operations, organizational structure,
and personnel.

For a new customer relationship management (CRM)

system, operational feasibility would involve assessing
how the system will integrate with existing business
processes, whether employees will be willing to adopt the
new system, and if the necessary resources are available
to support its implementation.
 Operational Feasibility
Operational Impact: Effects on existing processes
and workflows.
User Acceptance: Likelihood of user acceptance and
adoption of the new system.
Resource Availability: Availability of necessary
resources, including personnel and equipment.
Organizational Fit: Alignment of the project with
organizational goals and culture.
Requirements
Elicitation
 Requirements Elicitation
Requirements elicitation is the process of gathering
requirements from stakeholders.
It is a critical step in the software development lifecycle as it
ensures that the system meets the needs and constraints of
all parties involved.
Effective requirements elicitation helps in identifying the
expectations of stakeholders, uncovering any hidden
requirements, and resolving any conflicts that may arise
between different stakeholders' needs.
Importance of Requirements Elicitation:
Understanding Stakeholder Needs: Ensures that the system fulfills the
actual needs and expectations of the users.
Reducing Ambiguity: Helps in clarifying and refining requirements to avoid
misunderstandings.
Identifying Constraints: Uncovers technical, legal, and operational
constraints that must be considered.
Facilitating Communication: Promotes better communication and
understanding between stakeholders and the development team.
Improving Project Success: Leads to more accurate requirements, which
increases the likelihood of project success by reducing rework and project
delays.
Techniques for Requirements Elicitation
 1. Interviews
The objective of conducting an interview is to understand the
customer’s expectations of the software.
It is impossible to interview every stakeholder hence representatives
from groups are selected based on their expertise and credibility.
Interviews may be open-ended or structured.

1.
1. In open-ended interviews, there is no pre-set agenda. Context-free
questions may be asked to understand the problem.
2.
2. In a structured interview, an agenda of fairly open questions is
prepared. Sometimes a proper questionnaire is designed for the
interview.
 2. Brainstorming Sessions
Brainstorming Sessions 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
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
Its objective is to bridge the expectation gap – the 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:

1. Part of the environment that surrounds the system.

2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, the 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.
 4. Quality Function Deployment
In this technique, customer satisfaction is of prime concern, hence it
emphasizes the requirements that are valuable to the customer.
3 types of requirements are identified:
1. Normal requirements: In this the objective and goals of the proposed software
are discussed with the customer. For example – normal requirements for a
result management system may be entry of marks, calculation of results, etc.
2. Expected requirements: These requirements are so obvious that the customer
need not explicitly state them. Example – protection from unauthorized access.
3. Exciting requirements: It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. For example –
when unauthorized access is detected, it should back up and shut down all
processes.
 5. Use Case Approach
Use Case 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.
1. Actor: It is the external agent that lies outside the system but interacts with it in some way. An
actor may be a person, machine, etc. It is represented as a stick figure.
Primary actors: It requires assistance from the system to achieve a goal.
Secondary actor: It is an actor from which the system needs assistance.
2. 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.
3. 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.
 Requirement Analysis
Requirements analysis is a crucial phase in the software development process
that focuses on refining and validating the requirements gathered during the
elicitation phase. The purpose of requirements analysis is to ensure that the
requirements are:
Clear: Requirements should be unambiguous and easily understood by all
stakeholders.
Complete: All necessary requirements are identified and documented, leaving
no gaps.
Feasible: Requirements should be practical and achievable within the project's
constraints, including technical, financial, and time limitations.
Effective requirements analysis helps prevent misunderstandings, reduces
the risk of project failure, and ensures that the final system meets
stakeholder needs and expectations.
Techniques for Requirements Analysis

Modeling
Prioritization
Conflict Resolution
 1. Modeling
Modeling involves creating diagrams and models to visually represent and
analyze requirements. This technique helps in understanding complex
requirements, identifying inconsistencies, and communicating
requirements to stakeholders.

Types of Models:
Use Case Diagrams: Show the interactions between users (actors) and the system,
capturing functional requirements.
Data Flow Diagrams (DFDs): Illustrate how data moves through the system and the
processes that transform the data.
Entity-Relationship Diagrams (ERDs): Represent the data entities, their attributes,
and the relationships between them.
Activity Diagrams: Depict the workflow of processes within the system.
 2. Prioritization
Prioritization involves ranking requirements based on their
importance, urgency, and impact on the project. This technique helps
in focusing on the most critical requirements and managing limited
resources effectively.
Methods for Prioritization:
MoSCoW Method: Categorizes requirements into Must-have, Should-have,
Could-have, and Won't-have categories.
Kano Model: Classifies requirements based on their impact on customer
satisfaction (e.g., basic needs, performance needs, and excitement needs).
Weighted Scoring: Assigns scores to requirements based on criteria like
cost, benefit, and risk.
 3. Conflict Resolution
Conflict resolution involves identifying and resolving conflicts between
requirements that may arise from differing stakeholder needs or
technical constraints. This technique ensures that the final set of
requirements is consistent and feasible.
Steps for Conflict Resolution:
Identify Conflicts: Detect inconsistencies or contradictions between requirements.
Analyze Impact: Assess the impact of conflicting requirements on the project.
Negotiate Solutions: Work with stakeholders to find acceptable compromises or
alternatives.
Document Resolutions: Record the agreed-upon solutions and update the
requirements documentation.
 Requirement Documentation
Requirement documentation in software engineering is the
systematic process of documenting all necessary information
related to a software project's requirements.
It serves as a single source of truth for project stakeholders,
including product managers, software testers, and
developers.
It serves as a roadmap, outlining functional requirements,
system features, and interface requirements for the
development team.
 Requirement Documentation
Software Requirements Document (SRD): The foundation of
requirement documentation, the SRD outlines functional
requirements, non-functional requirements, and external
components necessary for the software's functionality and
performance.
Software Requirements Specification (SRS) Document: An
elaboration of the SRD, the SRS document provides a detailed
breakdown of requirements, often including diagrams, code
snippets, and acronyms for clarity and precision.
 Requirement Documentation
Project Stakeholders: Vital contributors to requirement documentation,
including product managers, developers, testers, and key stakeholders from
client organizations.
Process Documentation: Describes the methodology for eliciting, analyzing,
and validating requirements, ensuring a smart, efficient approach to
software development.
External Interface Requirements: Specifies the interactions between the
software system and external components, such as APIs, databases, or third-
party services.
Test Automation Tutorials: Guides automated testing techniques to ensure
software quality and reliability.
Step 1: Identify Stakeholders and Gather Requirements
In requirement documentation in software engineering, the first crucial
step is to identify all stakeholders engaged in the project, including
clients, end-users, developers, testers, and project managers.
Recognizing these key players ensures comprehensive coverage of
perspectives and needs.
Gathering requirements is essential and is achieved through various
means such as interviews, surveys, workshops, or reviewing existing
documentation. Active stakeholder engagement facilitates a thorough
understanding of project objectives, constraints, and user
expectations.
Step 2: Document Functional Requirements
Step 2: Document Functional Requirements
Description: Clearly define what tasks or functions the software
must perform.
Priority: Assign priority levels to each requirement to guide
development efforts.
Acceptance Criteria: Establish criteria that must be met for each
requirement to be considered complete.
Dependencies: Identify any dependencies between requirements or
with external factors.
Step 3: Document Non-Functional Requirements
Step 3: Document Non-Functional Requirements
Performance: Specify metrics for response time, throughput,
and resource utilization.
Scalability: Define how the system should handle increasing
loads and data volume.
Security: Outline authentication, authorization, data
encryption, and audit trails.
Usability: Detail user interface guidelines, accessibility
features, and user experience expectations.
Step 4: Review and Validate Requirements
Active engagement with stakeholders is paramount in ensuring that
the requirement documentation in software engineering effectively
reflects their needs and expectations.
Stakeholder reviews provide valuable insights into the accuracy and
relevance of the documented requirements, allowing for
adjustments to be made in real time.
Validation processes rigorously assess the feasibility, consistency,
completeness, and clarity of the requirements, guaranteeing their
alignment with project objectives.
Step 5: Document Assumptions and Constraints
Step 5: Document Assumptions and Constraints
Identify Assumptions: Actively identify any assumptions made during requirement
elicitation. These could involve expectations about user behavior, system interactions, or
technological capabilities.
Document Explicitly: Document all assumptions to prevent misunderstandings and align
stakeholder expectations. Use concise language to describe each assumption and its
potential impact on the project.
Identify Constraints: Identify any constraints that could affect the development process.
These constraints may include budget limitations, technological restrictions, or regulatory
requirements.
Document Constraints: Document all constraints to guide the development team and ensure
compliance throughout the project lifecycle.
Maintain Clarity: Regularly review and update the documentation to reflect any changes in
assumptions or constraints.
Step 6: Maintain and Manage Requirements
In requirement documentation in software engineering,
maintaining and managing requirements is critical to ensure
project success.
Establishing a robust process ensures clarity and consistency from
inception to deployment. It begins with implementing version
control mechanisms to track changes and updates in the
documentation meticulously.
Teams can easily trace the evolution of requirements and address
any discrepancies effectively.
Best Practices for Creating and Maintaining
Requirement Documentation
Benefits of Creating Software
Requirements Document
Software Requirement Specification (SRS)
Software requirements specification is a technical document
describing your project’s functionality, features, design, limitations,
and goals.
Simply put, an SRS outlines how an application should operate and
how the product development team should build it.
While you as a client may use it to define your project expectations
and deliverables, your development company will use it to assess the
amount of work, define the technology stack, and estimate the
project cost.
Software Requirement Specification (SRS)
Software Requirement Specification (SRS)
Software Requirement Specification (SRS)
Software Requirement Specification (SRS)
Software Requirement Specification (SRS)
 Step 1. Create an Outline
The first step is to create an outline that will act as a framework for the document
and your guide through the writing process. You can either create your outline or
use an SRS document template as a basis. Anyway, the outline should contain the
following important elements: General description
Introduction Business requirements
Purpose User needs
Product limitations and constraints
Intended use and target audience Assumptions and dependencies
Product scope Features and requirements
Definitions Features
Functional
External interface
Non-functional
Supporting information
Step 2. Define What the Purpose of Your Software is
It allows you to write a clear picture of what you want your product
to do and how you want it to function. So, here you should include a
detailed description of the intended users, how they will interact with
the product, and the value your product will deliver. Answering the
following question will help you to write the purpose:
What problems does your product solve?
Who are the intended users?
Why is your product important?
 Step 3. Give an Overview
Here’s the section where you clarify your idea and explain
why it can be appealing to users.
Describe all features and functions and define how they will
fit the user’s needs.
Also, mention whether the product is new or a replacement
for the old one, is it a stand-alone app or an add-on to an
existing system?
Additionally, you can highlight any assumptions about the
product’s functionality.
 Step 4. Describe Functional and Non-
functional Requirements
Whether you write it internally or with the help of external
experts, you should detail all the requirements associated
with your app.
For your dedicated development team to understand it
properly, describe this information adequately.
It would help them if you include use cases here as well since
they can vividly illustrate how a user will interact with your
system.
 Step 5. Add Supplemental Details
If you have something else to add, any alternative ideas or proposals,
references, or any other additional information that could help
developers finish the job, write them down in this section of the
software requirements specification.
You may have suggestions on technologies you want to use, ideas for
design patterns, or examples of case studies that have tackled similar
challenges.
Here, you can also define priorities for certain features and highlight
areas where your development team has room for flexibility and
creativity.
 Step 6. Get Approval
Now it’s time to have stakeholders review the SRS report
carefully and leave comments or additions if there are any.
After edits, give them to read the document again, and if
everything is correct from their perspective, they’ll approve it
and accept it as a plan of action.
Here, it’s important to include every change in the latest SRS
version and inform your development team right away to
ensure everyone is on the same page.
 How to Write
Software Use Cases
in an SRS
Functional requirements
External interface requirements
System requirements
Non-functional requirements
 Tools for SRS
documentation
Context diagram
Functional decomposition
Use case diagram
Sequence diagram
AS-IS and TO-BE process model
TO-BE process model
User Stories
Mind Map
 REQUIREMENTS
06
VALIDATION
 Requirements Validations
Requirements validation is the process of checking that requirements
actually define the system that the customer really wants. It overlaps
with analysis as it concerned with finding problems with the
requirements.
The Cost of fixing a requirements problem by making a system change
is usually much greater than repairing design or coding errors.
During the requirements validation process, different types of checks
06
should be carried out on the requirements in the requirements
document.
Requirement Validation Techniques
1. Test Case Generation
2. Prototyping
3. Requirements Reviews
4. Automated Consistency Analysis
5. Walk-through
06 6. Simulation
7. Checklists for Validation
 1. Test Case Generation
The requirement mentioned in the SRS document should
be testable, the conducted tests reveal the error present
in the requirement.
It is generally believed that if the test is difficult or
impossible to design, this usually means that the
requirement will be difficult to implement and it should be
06

reconsidered.
 2. Prototyping
In this validation technique the prototype of the
system is presented before the end-user or
customer, they experiment with the presented
model and check if it meets their need.
This type of model is mostly used to collect
06

feedback about the requirement of the user.

 3. Requirements Reviews
In this approach, the SRS is carefully reviewed
by a group of people including people from both
the contractor organizations and the client side,
the reviewer systematically analyses the
document to check errors and ambiguity.
06
 4. Automated Consistency Analysis
This approach is used for the automatic detection of an
error, such as non-determinism, missing cases, a type
error, and circular definitions, in requirements
specifications.
First, the requirement is structured in formal notation then
the CASE tool is used to check the in-consistency of the
system, The report of all inconsistencies is identified, and
06

corrective actions are taken.

 5. Walk-through
A walkthrough does not have a formally defined procedure
and does not require a differentiated role assignment. Peer
review process.
Checking early whether the idea is feasible or not.
Obtaining the opinions and suggestions of other people.
Checking the approval of others and reaching an
06

agreement.
 6. Simulation
Simulating system behavior in order to verify
requirements is known as simulation.
This method works especially well for
complicated systems when it is possible to
replicate real-world settings and make sure the
06

criteria fulfil the desired goals.

 7. Checklists for Validation
It employs pre-made checklists to
methodically confirm that every prerequisite
satisfies predetermined standards.
Aspects like completeness, clarity and
viability can all be covered by checklists.
06
 Different types of Checks
Completeness checks
Consistency checks
Validity checks
Realism checks
Ambiguity checks
Variability
06

Verifiability
 1. Completeness Checks
Ensure that all required elements and functionalities are fully
implemented as specified in the requirements.
Example: For a project management tool, ensure that all
features listed in the requirement document (e.g., task
creation, assignment, deadline tracking) are present and
06

operational.
 2. Consistency Checks
Verify that there are no conflicting requirements or discrepancies
between different parts of the system or documentation.
Example: Ensure that the naming conventions for variables
and methods are consistent across the codebase and
documentation, such as using camelCase for variables and
06

PascalCase for classes.

 3. Validity Checks
Confirm that the system performs its intended functions correctly
and produces the expected results.
Example: Validate that a search feature in an e-commerce
application returns relevant products based on user
queries. For instance, searching for “laptops” should return
06

a list of laptop products.

 4. Realism Checks
Ensure that the requirements and design are practical and achievable
within the given constraints such as time, resources, and technology.
Example: Check if the proposed timeline for developing a new
feature is realistic based on the team’s workload and capacity.
For example, estimating that a complex feature will be completed
in two weeks might be unrealistic if it involves extensive
06

integration with other systems.

 5. Ambiguity Checks
Identify and clarify any vague or unclear requirements or specifications
to ensure that they are precise and actionable.
Example: In a requirements document, replace vague
statements like “the system should be fast” with specific
metrics such as “the system should process user requests
06

in under 2 seconds.”
 6. Variability Checks
Ensure that the system can handle various input scenarios,
configurations, and environmental conditions effectively.
Example: Test a web application on multiple browsers
(Chrome, Firefox, Safari) and devices (desktop, tablet,
mobile) to ensure that it functions consistently across
06

different environments.
 7. Verifiability Checks
Ensure that the software’s features and performance can be validated
through tests, and that the results can be consistently reproduced.
Example: For an API, write automated test cases to
verify that endpoints return the correct status codes and
data. Ensure that running the same tests multiple times
06

yields consistent results.

Importance of Requirements Validation Techniques
 REQUIREMENTS
06
MANAGEMENT
 Requirement Management
The requirement management process involves managing
evolving requirements during the requirements engineering
phase and system development. This includes tracking
individual requirements, maintaining links between
dependent requirements, assessing the impact of changes,
and establishing a formal process for handling change
06

proposals.
Key Components of Requirement Management
1. Requirements Identification:
Unique Identification: Each requirement must be
uniquely identified using a distinct identifier (e.g.,
REQ-001, REQ-002) to facilitate easy referencing
and tracking throughout the project lifecycle.
06
1. Requirements Identification:
Key Components of Requirement Management
2. Requirement Change Management Process:
Impact Assessment: Evaluate the potential effects of
proposed changes on the existing requirements,
project scope, cost, schedule, and resources.
Cost Evaluation: Determine the financial implications
of implementing changes, ensuring they are within the
06

project’s budget.
2. Requirement Change Management Process:
Key Components of Requirement Management
3. Traceability Policies:
Relationship Recording: Document the
relationships between requirements and system
components, including design elements,
implementation modules, and test cases.
06
 3. Traceability Policies

06
 Traceability Matrix:
A table correlating high-level requirements
with detailed requirements. It includes
different types of traceability tables such as
features, source, requirements, design, and
06 interface traceability tables.
 Types of Traceability
Traceability Table Description
Indicates how requirements relate to important features specified by the
Features Traceability user.

Identifies the source of each requirement by linking requirements to

Source Traceability stakeholders who proposed them. Useful for consulting stakeholders when
changes are proposed.

Indicates how dependent requirements in the SRS are related to one another.
Requirements Traceability Useful for evaluating the impact of proposed changes on other requirements.

Links requirements to the design modules where these requirements are

Design Traceability implemented. Useful for assessing the impact of proposed changes on design
and implementation.

Indicates how requirements are related to internal and external interfaces of

Interface Traceability a system.
Key Components of Requirement Management
[Link] Support:
MS Excel: Widely used for its simplicity and flexibility in
creating spreadsheets to track requirements.
Spreadsheets: General-purpose tools that allow for custom
tracking and analysis of requirements.
Database Systems: Simple databases can be used to store
and manage requirements data, providing more advanced
06

querying and reporting capabilities.

[Link] Support