Introduction to Requirements Engineering

What is Requirements Engineering?

Requirements Engineering is the process of understanding what a system (like
software or an app) should do before it is built. It helps make sure that the final
product meets the needs of the users and works as expected..

Why is Requirements Engineering Important?

If you don't understand what the user wants:
• You might build the wrong thing.
• It could waste time and money.
• The user might not be happy with the result.

The 4 Key Steps in Requirements Engineering

1. Gather Requirements (Ask Questions!)
o Talk to users, customers, and stakeholders (people who care about
the product).
o Ask: "What do you want the system to do?"
o Example: For a ride-sharing app, users might say:
▪ "I want to book a ride with one click."
▪ "I need to see the driver’s location on a map."
2. Document Requirements (Write It Down Clearly)
o Turn vague wishes into clear, specific statements.
o Bad: "Make it fast."
o Good: "The app should load in under 2 seconds."
 3. Analyze & Validate (Check for Problems)
o Ask: "Does this make sense? Is it possible? Does it conflict with other
requirements?"
o Example: If one user wants "no login" but another wants "secure
payments," you’ll need to find a balance.
4. Manage Changes (Stay Flexible)
o Needs can change over time (new laws, user feedback, etc.).
o Keep track of updates so the team doesn’t get confused.

Software Requirements
What are Software Requirements?
Software requirements are the specific needs and expectations that a software
product must fulfill. They describe what the software should do (functional
requirements) and how it should perform (non-functional requirements). Think of
them as a detailed blueprint for building software, guiding developers on what to
create.
Types of Software Requirements
1. Functional Requirements:
• These describe what the software should do. They outline specific
behaviors, functions, and features that the software must have.
• Example: For a banking app, functional requirements might include:
• Users can create an account.
• Users can transfer money between accounts.
• Users can view their transaction history.
2. Non-Functional Requirements:
• These describe how the software should perform. They cover aspects
like performance, security, usability, and reliability.
 • Example: For the same banking app, non-functional requirements
might include:
• The app should load within 2 seconds.
• The app should be secure and protect user data.
• The app should be easy to use for people of all ages.
Why Are Software Requirements Important?
• Clarity: They provide a clear understanding of what the software should
achieve, reducing confusion among team members.
• Guidance: They serve as a roadmap for developers, helping them know
what to build and how to prioritize tasks.
• Validation: They allow stakeholders to verify that the final product meets
their needs and expectations.
• Cost-Effectiveness: Well-defined requirements can help avoid costly chan

Classification of Requirements
Requirements can be classified in various ways to help organize and manage them
effectively. Here are the main classifications of requirements:
1. Functional Requirements
• Definition: These specify what the system should do. They describe the
specific functions, features, and behaviors of the software.
• Examples:
• A user must be able to log in using a username and password.
• The system should send an email confirmation after a purchase.
• Users can search for products by name or category.
2. Non-Functional Requirements
• Definition: These specify how the system performs its functions. They cover
quality attributes, system performance, and constraints.
 • Examples:
• The system should respond to user requests within 2 seconds.
• The application must be available 99.9% of the time (uptime).
• The software should comply with data protection regulations (e.g.,
GDPR).
3. User Requirements
• Definition: These describe what the users need from the system. They are
often expressed in natural language and focus on user interactions.
• Examples:
• Users should be able to reset their passwords easily.
• The interface should be intuitive and user-friendly.
4. System Requirements
• Definition: These provide a detailed description of the system's
functionality and constraints. They can be further divided into:
• High-Level Requirements: Broad statements about what the system
should achieve.
• Detailed Requirements: Specific and precise descriptions of system
behavior.
• Examples:
• High-Level: The system should manage customer orders.
• Detailed: The system must allow users to add items to their cart and
proceed to checkout.
5. Business Requirements
• Definition: These outline the high-level goals and objectives of the
organization that the software must support. They focus on the value the
software will bring to the business.
• Examples:
 • Increase online sales by 20% within the next year.
• Improve customer satisfaction ratings by implementing a feedback
system.

Requirements Process
The requirements process is the set of activities used to identify, analyze,
document, and manage the needs and expectations of stakeholders for a new or
modified product.

1. Requirements Elicitation
• Definition: Gathering information from stakeholders about what they need
from the system.
• Activities include:
o Interviews
o Surveys
o Observation
o Brainstorming sessions
• Example: Talking to users to understand how they currently use a billing
system.

2. Requirements Analysis
• Definition: Understanding, refining, and organizing the collected
requirements.
• Activities include:
o Detecting conflicts or duplicates
o Prioritizing requirements
o Creating models (use case diagrams, data flow diagrams)
 • Example: Analyzing if two features requested by users are in conflict.

3. Requirements Specification
• Definition: Clearly documenting the requirements in an organized and
structured format.
• Output: A Software Requirements Specification (SRS) document.
• Example: Writing down “The system shall allow password reset via email.”

4. Requirements Validation
• Definition: Ensuring the documented requirements are complete,
consistent, and correct.
• Methods:
o Reviews
o Prototyping
o Walkthroughs
• Example: Reviewing the SRS with users and developers to confirm accuracy.

5. Requirements Management
• Definition: Handling changes to requirements throughout the project
lifecycle.
• Activities include:
o Tracking requirement changes
o Updating documentation
o Managing version control
• Example: Adding a new requirement when a stakeholder changes their
needs.
Levels/Layers of Requirements
In software development, requirements can be organized into different levels or
layers to provide a structured approach to understanding and managing them.
This classification helps ensure that all aspects of the system are considered and
that requirements are aligned from high-level business goals down to detailed
specifications. Here are the main levels/layers of requirements:
1. Business Requirements
• Definition: These are high-level needs and objectives that the organization
aims to achieve with the software. They focus on the overall goals of the
business and the value the software will provide.
• Examples:
• Increase market share by 15% within the next year.
• Improve customer satisfaction ratings by implementing a new
support system.
2. Stakeholder Requirements
• Definition: These requirements capture the needs and expectations of
various stakeholders, including users, clients, and other parties involved in
the project. They bridge the gap between business requirements and
system requirements.
• Examples:
• Users need a way to track their orders in real-time.
• Administrators require tools to manage user accounts and
permissions.
3. System Requirements
• Definition: These are detailed specifications that describe what the system
must do to meet stakeholder and business requirements. System
requirements can be further divided into:
 • Functional Requirements: Specific behaviors and functions the
system must perform.
• Non-Functional Requirements: Quality attributes such as
performance, security, usability, and reliability.
• Examples:
• Functional: The system must allow users to create and manage their
profiles.
• Non-Functional: The system should handle 1,000 concurrent users
without performance degradation.
4. Technical Requirements
• Definition: These requirements specify the technical aspects of the system,
including hardware, software, and network specifications. They ensure that
the system can be built and operated effectively.
• Examples:
• The application must be compatible with Windows, macOS, and
Linux.
• The system should be developed using the Java programming
language and hosted on AWS.
5. User Requirements
• Definition: These are specific needs and expectations of end-users
regarding how they will interact with the system. User requirements often
focus on usability and user experience.
• Examples:
• Users should be able to reset their passwords via email.
• The interface should be accessible for users with disabilities.
Requirement Characteristics
When defining and managing requirements for a software project, it’s essential to
ensure that they possess certain characteristics. Well-defined requirements help
ensure that the final product meets user needs and business goals. Here are the
key characteristics of good requirements:
1. Clear
• Definition: Requirements should be easily understood and unambiguous.
They should avoid vague language and be specific about what is needed.
• Example: Instead of saying "The system should be fast," a clear requirement
would be "The system should process user requests within 2 seconds."
2. Concise
• Definition: Requirements should be stated in a straightforward manner
without unnecessary details. They should convey the necessary information
succinctly.
• Example: "Users must be able to log in using their email and password" is
concise compared to a lengthy explanation of the login process.
3. Consistent
• Definition: Requirements should not conflict with one another. They should
be aligned and support each other to avoid confusion during development.
• Example: If one requirement states that "Users can view their order
history," another requirement should not contradict this by saying "Users
cannot access their order history."
4. Complete
• Definition: Requirements should cover all necessary aspects of the system.
They should provide a comprehensive understanding of what is needed
without leaving gaps.
 • Example: A complete requirement for a payment feature would include
details about accepted payment methods, security measures, and user
notifications.
5. Verifiable
• Definition: Requirements should be testable, meaning that there should be
a clear way to verify whether the requirement has been met once the
system is developed.
• Example: "The system should allow users to reset their password via email"
is verifiable because it can be tested by attempting to reset a password.
6. Feasible
• Definition: Requirements should be realistic and achievable within the
project's constraints, including time, budget, and technology.
• Example: A requirement stating "The system should support 10,000
concurrent users" is feasible only if the infrastructure can handle that load.
7. Prioritized
• Definition: Requirements should be ranked based on their importance and
urgency. This helps teams focus on delivering the most critical features first.
• Example: A requirement for a core functionality, like user registration,
would be prioritized higher than a nice-to-have feature, like customizable
themes.
8. Traceable
• Definition: Requirements should be linked to their source and related
requirements, allowing for easy tracking throughout the project lifecycle.
• Example: Each requirement should reference the business goal it supports
and be linked to design documents and test cases.
9. Understandable
• Definition: Requirements should be written in a way that all stakeholders,
including technical and non-technical team members, can understand.
 • Example: Using simple language and avoiding technical jargon helps ensure
that everyone involved can grasp the requirements.

Process-to-Process Communication and Circuit

Switching: Analyzing Quality Requirements
In the context of computer networks and telecommunications, understanding the
quality requirements for process-to-process communication and circuit switching
is essential for ensuring effective data transmission. Here’s an overview of both
concepts and the quality requirements associated with them.
Process-to-Process Communication
Definition: Process-to-process communication refers to the exchange of data
between applications (processes) running on different devices over a network.
This communication is typically facilitated by protocols that ensure data is sent
and received correctly.
Quality Requirements:
1. Reliability:
• Description: The communication must ensure that data is delivered
accurately and without loss.
• Example: If a file is sent from one application to another, it should
arrive intact and in the correct order.
2. Latency:
• Description: The time it takes for data to travel from the source
process to the destination process should be minimized.
• Example: In real-time applications like video conferencing, low
latency is crucial to maintain a natural conversation flow.
3. Throughput:
• Description: The amount of data that can be transmitted over the
network in a given time period should meet application needs.
 • Example: Streaming services require high throughput to deliver high-
quality video without buffering.
4. Scalability:
• Description: The communication system should be able to handle an
increasing number of processes or users without degrading
performance.
• Example: A messaging application should support thousands of users
simultaneously without significant delays.
5. Security:
• Description: Data transmitted between processes should be
protected from unauthorized access and tampering.
• Example: Encryption protocols should be used to secure sensitive
information during transmission.
6. Quality of Service (QoS):
• Description: The ability to prioritize certain types of traffic to ensure
that critical applications receive the necessary bandwidth and low
latency.
• Example: VoIP calls may be prioritized over regular data traffic to
ensure clear audio quality.

Circuit Switching
Definition: Circuit switching is a method of communication where a dedicated
communication path (circuit) is established between two endpoints for the
duration of the communication session. This method is commonly used in
traditional telephone networks.
Quality Requirements:
1. Connection Establishment Time:
• Description: The time taken to establish a dedicated circuit before
communication begins should be minimized.
 • Example: In a telephone call, the time taken to connect the call
should be short to enhance user experience.
2. Bandwidth:
• Description: The dedicated circuit should provide sufficient
bandwidth for the communication needs of the users.
• Example: A voice call requires a certain amount of bandwidth to
maintain clear audio quality without interruptions.
3. Reliability:
• Description: The established circuit should maintain a consistent
connection without drops or interruptions during the communication
session.
• Example: A stable phone call should not experience sudden
disconnections or static.
4. Latency:
• Description: The delay in transmitting data over the established
circuit should be minimal to ensure smooth communication.
• Example: In a conversation, low latency is essential to avoid talking
over each other.
5. Quality of Service (QoS):
• Description: The circuit should provide guaranteed performance
levels, such as bandwidth and latency, for the duration of the
connection.
• Example: A dedicated circuit for a video conference should ensure
that video and audio quality remain high throughout the session.
6. Scalability:
• Description: The circuit-switched network should be able to
accommodate an increasing number of simultaneous connections
without degrading service quality.
 • Example: A telephone exchange should handle multiple calls without
causing delays or dropped calls.

Software Requirements in the Context of Systems

Engineering

What is Systems Engineering?

Systems Engineering is an interdisciplinary field that focuses on designing,
integrating, and managing complex systems throughout their life cycles. These
systems may include hardware, software, human interaction, and processes.

What Are Software Requirements?

Software Requirements are the specific needs and expectations that a software
system must meet to be effective within a larger system. In systems engineering,
software is treated as a subsystem of the whole system (e.g., an aircraft control
system, hospital management system).

Type Description Example

Functional Define what the "The system shall record patient

Requirements software must do temperature every 10 minutes"

Non-Functional Define how the "System must encrypt data to

Requirements software performs ensure confidentiality"

Interface Specify interaction with "Software must communicate with

Requirements other system parts blood pressure sensor over USB"

Performance Set speed, reliability, "Response time must not exceed 2

Requirements and resource limits seconds under 1000 users"
Type Description Example

Security Ensure system is safe "Only authorized users may access

Requirements from threats patient records"

Feature System Requirement Software Requirement

Whole system (hardware,

Scope Software part of the system
software, users)

“The drone must fly “Navigation software shall update

Example
autonomously for 1 hour” coordinates every second”

Owner Systems Engineer Software Engineer/Developer

Requirement Evolution
Definition:
Requirement evolution refers to the changes that occur in the system or software
requirements over time as a result of changing business needs, new insights,
technological advancements, or feedback from stakeholders.
Requirements are not static; they evolve throughout the project lifecycle. Effective
management of this evolution is crucial for the success of any system or software
development project.

Reasons for Requirement Evolution:

1. Changing Business Needs:
o As markets evolve or business priorities change, the requirements
may need to be adjusted.
 o Example: A company may initially want a simple e-commerce
platform, but later add advanced features like personalized
recommendations.
2. Technological Advancements:
o New technologies may make previous solutions obsolete or introduce
new capabilities.
o Example: A new database technology might make previously planned
data storage solutions inefficient.
3. Feedback from Stakeholders:
o Stakeholders (e.g., users, clients, or regulatory bodies) may provide
feedback that leads to changes in requirements.
o Example: After testing a new software version, users may request an
easier interface or new features.
4. Discovery of New Requirements:
o As the system is developed, unforeseen needs may arise.
o Example: A mobile application for healthcare might require
integration with new medical devices not anticipated at the start.
5. Regulatory Changes:
o Changes in laws or regulations can force the system requirements to
adapt.
o Example: Data privacy regulations (e.g., GDPR) might require
adjustments to how user data is handled.

What is Requirement Traceability?

Requirement Traceability is the ability to track every requirement throughout a
project—from the beginning (when it is created) to the end (when it is fulfilled). It
ensures that each requirement is properly implemented, tested, and delivered.
 Purpose of Requirement Traceability
• Ensures that all requirements are met.
• Helps identify changes and their impact.
• Maintains a clear path from user needs to final product.
• Improves communication among teams.

Types of Traceability
1. Forward Traceability: This tracks the relationship from requirements to
design, implementation, and testing. It ensures that each requirement is
implemented in the final product.
2. Backward Traceability: This tracks the relationship from the final product
back to the original requirements. It helps in verifying that all implemented
features are based on documented requirements.
3. Bi-directional Traceability: This combines both forward and backward
traceability, providing a comprehensive view of the relationships between
requirements and other project elements.

What is Requirement Prioritization?

Requirement Prioritization is the process of deciding which requirements are the
most important and should be worked on first. It helps teams focus on delivering
the most valuable features early in the project.

Purpose of Requirement Prioritization

• Helps manage limited time, budget, and resources.
• Ensures important features are delivered early.
• Aligns development with business goals and customer needs.
 Common Prioritization Techniques
1. MoSCoW Method
o M – Must have: Essential features.
o S – Should have: Important but not critical.
o C – Could have: Nice to have if time allows.
o W – Won’t have: Not planned for now.
2. 100-Point Method
o Stakeholders are given 100 points to distribute among all
requirements.
o Helps determine what's most valued by users.
3. Kano Model
o Classifies features into:
▪ Basic needs (expected),
▪ Performance features (more = better),
▪ Delighters (unexpected but pleasing).
4. Value vs. Risk Matrix
o Evaluates each requirement based on how much value it adds and
the risk it involves.
o Helps balance reward and difficulty.

What is Trade-off Analysis?

Trade-off Analysis is the process of comparing different options by weighing their
pros and cons to make the best possible decision when resources (like time,
money, or quality) are limited.
 When Do We Use Trade-off Analysis?
• When two or more requirements cannot be implemented together.
• When adding a new feature may increase cost or delay delivery.
• When optimizing for one aspect (e.g., speed) affects another (e.g., cost).

Common Trade-off Areas

Area Trade-off Example

Cost vs Quality Higher quality may increase project cost.

Time vs Features Delivering faster may require dropping features.

Performance vs Usability High performance systems may be harder to use.

Security vs Convenience More secure systems may be less user-friendly.

Steps in Trade-off Analysis

1. Identify the Options
o List all possible choices.
2. List the Criteria
o Define what matters (cost, time, performance, etc.).
3. Evaluate Pros and Cons
o Note benefits and drawbacks for each option.
4. Score or Compare
o Rank or rate each option based on priorities.
5. Choose the Best Option
o Select the option that offers the best balance.
 What is Risk Analysis?
Risk Analysis is the process of identifying potential problems or threats that may
negatively affect a project, system, or process..

Steps in Risk Analysis

1. Identify Risks
o What can go wrong? (e.g., system failure, budget overrun)
2. Assess Likelihood
o How likely is the risk to occur? (High / Medium / Low)
3. Assess Impact
o What will be the result if it occurs? (Severe / Moderate / Minor)
4. Prioritize Risks
o Focus on high-probability, high-impact risks first.
5. Plan Responses
o Create plans to avoid, reduce, or handle the risks.

What is Impact Analysis?

Impact Analysis is the process of evaluating the effects or consequences of a
change, failure, or decision in a system or project.

When to Use Impact Analysis

Before implementing a change request.
• After detecting a fault or bug.
• While planning upgrades or feature additions.
 Steps in Impact Analysis
1. Identify the Change
o What is being changed?
2. Identify Affected Areas
o What modules, users, or documents are impacted?
3. Estimate Impact
o How serious is the effect? (Functional, financial, technical)
4. Plan and Decide
o Decide whether to proceed with the change.

Title: Requirement Management

What is Requirement Management?

Requirement Management is the process of documenting, analyzing, tracking, and
controlling all requirements throughout the life of a project to ensure that the
final product meets the agreed-upon needs.

Key Activities in Requirement Management

1. Requirement Gathering
o Collect requirements from users, stakeholders, and documents.
2. Requirement Documentation
o Record requirements in a clear and organized manner.
3. Requirement Analysis
 o Examine requirements for completeness, clarity, and feasibility.
4. Requirement Prioritization
o Rank requirements by importance (Must, Should, Could).
5. Requirement Validation
o Ensure that the documented requirements meet user needs.
6. Requirement Traceability
o Track each requirement from start to finish (design, development,
testing).
7. Requirement Change Management
o Handle changes through formal processes to control impact.

Title: Interaction Between Requirement and

Architecture

What Does It Mean?

The interaction between requirements and architecture refers to how the needs of
the users (requirements) influence the design of the system (architecture), and
how the architecture supports or limits those requirements.

Why Is This Important?

• Requirements define what the system should do.
• Architecture defines how the system will do it.
Both need to work together for a system to be successful.

Two-Way Relationship
 1. Requirements → Influence Architecture
o Functional and non-functional requirements guide the structure of
the system.
o Example: A requirement for high performance may lead to a
microservices architecture.
2. Architecture → Shapes Requirements
o Some architectural decisions may affect how requirements are
defined or changed.
o Example: Choosing a cloud-based architecture might allow for new
requirements like remote access.

Types of Requirements That Affect Architecture

Requirement Type Impact on Architecture

Functional Determines system components and interactions

Performance Requires fast processing and efficient design

Security May need encryption, authentication mechanisms

Scalability Influences use of distributed or modular design

Availability Affects decisions like backup servers or failover

Title: Requirement Elicitation, Sources, and

Techniques

What is Requirement Elicitation?

Requirement Elicitation is the process of collecting requirements from
stakeholders, users, and other sources to understand what a system should do.
It’s like asking the right questions to get a complete picture of what the client or
user needs.

Purpose of Requirement Elicitation

• To gather accurate, complete, and clear requirements.
• To ensure the final product meets user expectations.
• To avoid misunderstandings and costly rework.

Elicitation Sources
These are the people or documents from which we gather requirements:

Source Description

Stakeholders People affected by the system (e.g., clients, users).

End Users The actual users who will operate the system.

Domain Experts Specialists who understand the field or industry.

Documents Existing reports, forms, policies, and systems.

Market Research Data about user needs and competitors.

Requirement Elicitation Techniques

Here are common methods used to collect requirements:
1. Interviews
• One-on-one conversation with stakeholders.
• Helps understand expectations in detail.
• Example: Interviewing a manager about system features.
2. Questionnaires/Surveys
 • Written questions sent to many users.
• Useful for gathering input from large groups.
• Example: Sending a Google Form to employees.
3. Workshops
• Interactive meetings with stakeholders and users.
• Encourages group discussions and brainstorming.
4. Observation
• Watching users do their work to identify needs.
• Example: Observing a cashier to design a billing system.
5. Document Analysis
• Studying existing manuals, reports, or software.
• Useful for understanding the current system.
6. Brainstorming
• Group discussion to generate new ideas.
• Helps in identifying innovative requirements.
7. Prototyping
• Building a simple model of the system to get feedback.
• Users interact with the prototype and suggest changes.
8. Focus Groups
• A selected group of users discusses their needs.
• Useful for collecting opinions and suggestions.

What is Requirement Specification?

Requirement Specification is the process of documenting all the gathered
requirements in a clear, detailed, and structured format. The result is usually a
formal document known as the Software Requirement Specification (SRS).
 Purpose of Requirement Specification
• To define what the system should do.
• To serve as a reference for developers, testers, and stakeholders.
• To avoid confusion and ensure everyone is on the same page.

What is a Software Requirement Specification (SRS)?

An SRS is a document that describes:
• Functional Requirements (What the system should do)
• Non-Functional Requirements (Performance, security, usability, etc.)
• Constraints (Technology, design, policies)
• Interfaces (How the system interacts with users and other systems)

Sources of Specification
These are the origins from which detailed specifications are derived:

Source Description

Requirement Elicitation Data collected through interviews, surveys, etc.

Stakeholders Clients, users, project sponsors.

Business Documents Company policies, contracts, business rules.

Existing Systems Old applications or competitor products.

Standards & Regulations Legal, technical, and industry standards.

Techniques for Writing Specifications

Here are common methods used to write clear and effective requirement
documents:
1. Use of Templates
• Standardized formats help maintain consistency.
• Common sections: Introduction, Scope, Functional Requirements, etc.
2. Use Cases
• Describe how a user will interact with the system.
• Example: “Student logs in and views grades.”
3. User Stories
• Simple, informal descriptions of features.
• Format: “As a [user], I want [function], so that [benefit].”
4. Functional Decomposition
• Break down high-level features into smaller detailed requirements.
5. Flowcharts & Diagrams
• Visuals like Data Flow Diagrams (DFDs), Use Case Diagrams, etc. for better
understanding.
6. Prototyping
• A visual or working mock-up that helps refine and document
Requirement

Title: Requirements Validation and Techniques

What is Requirements Validation?

Requirements Validation is the process of making sure that the documented
requirements are:
• Correct (they match what the user needs),
 • Complete (nothing important is missing),
• Clear (easy to understand), and
• Feasible (realistic and possible to implement).

Common Techniques for Requirements Validation

1. Reviews / Walkthroughs
• Stakeholders and team members review the requirements document.
• Helps catch missing, unclear, or conflicting requirements.
2. Prototyping
• Build a mock-up or early version of the system.
• Users interact with it and give feedback.
3. Model Validation
• Use diagrams like UML or DFDs and check if they represent the
requirements properly.
4. Checklists
• Use predefined questions to ensure completeness and quality.
• Example: “Is every requirement testable?”, “Is any requirement
ambiguous?”
5. Requirement Testing (Test Cases)
• Write test cases from requirements and check if each requirement can be
tested.
• If it can’t be tested, it’s likely unclear or incomplete.
6. Inspections
• A formal, structured review process led by trained moderators.
• Detects more errors than informal reviews.
 Title: Management of Requirements

What is Requirements Management?

Requirements Management is the process of organizing, tracking, and controlling
all requirements throughout a project’s life cycle to ensure that the final system
meets user expectations.
It includes how we gather, document, trace, prioritize, update, and verify
requirements during the development process.

Objectives of Requirements Management

• Keep requirements accurate and up to date
• Manage changes efficiently
• Maintain traceability from origin to implementation
• Ensure stakeholder agreement
• Help teams build the right product

Key Components of Requirements Management

Component Description

Requirement
Assigning unique IDs to each requirement for tracking.
Identification

Requirement Writing requirements in a clear, structured format

Documentation (e.g., SRS).

Mapping requirements through design, development,

Requirement Traceability
and testing.

Change Management Handling modifications in a controlled way.

Component Description

Requirement Deciding which requirements are most important to

Prioritization implement first.

Requirement Validation Checking that requirements meet stakeholder needs.

Tools Used in Requirement Management

Tool Type Examples

Requirement Tools IBM DOORS, Jama, ReqView

Project Tools Jira, Trello, Azure DevOps

Documentation Tools MS Word, Confluence, Google Docs

What is Requirements Management?

Requirements Management is the process of documenting, analyzing, tracing,
prioritizing, and agreeing on requirements, then controlling any changes and
communicating with stakeholders. It ensures everyone involved understands what
the project will deliver.
Why is it Important?
Effective Requirements Management helps prevent scope creep (unplanned
changes), reduces misunderstandings, and ensures the final product meets
customer and stakeholder needs. Without it, projects risk missed deadlines,
budget overruns, and dissatisfaction.
The Requirements Management Process
1. Elicitation: Gathering requirements from stakeholders.
2. Documentation: Recording requirements clearly and in detail.
 3. Analysis: Checking requirements for feasibility, clarity, and
completeness.
4. Prioritization: Ranking requirements based on importance and
resources.
5. Traceability: Linking requirements throughout the project lifecycle
to ensure coverage.
6. Change Control: Managing any changes to requirements in an
organized way.
7. Communication: Sharing updates and changes with all stakeholders.

Requirements Management Problems

1. Poorly Defined Requirements
When requirements are vague, incomplete, or unclear, it leads to confusion.
Teams may misunderstand what needs to be built, causing errors and rework later.
2. Changing Requirements
Requirements often change due to evolving business needs or customer feedback.
Without proper change control, these changes can cause delays, increase costs, or
lead to project failure.
3. Lack of Stakeholder Involvement
If stakeholders are not actively involved throughout the project, requirements
may not reflect their real needs. This results in a product that does not satisfy
users or business goals.
4. Ineffective Communication
Miscommunication between team members and stakeholders causes
misunderstandings about requirements, priorities, and progress, leading to errors
and frustration.
5. Scope Creep
Uncontrolled addition of new requirements without assessing their impact leads
to scope creep. This causes projects to exceed budget, miss deadlines, or deliver
incomplete solutions.
6. Inadequate Traceability
Without traceability, it is difficult to track the origin, status, and relationships of
requirements throughout the project. This leads to missed requirements or
duplicated efforts.
7. Poor Prioritization
Failing to prioritize requirements properly can result in focusing on less important
features while critical ones get delayed or ignored.
8. Insufficient Documentation
If requirements are not well documented, team members may interpret them
differently, causing inconsistencies in the final product.
9. Lack of Tools or Processes
Not using proper tools or defined processes for managing requirements can lead
to confusion, lost information, and inefficient management.

Requirements Engineering for Agile Methods

What is Agile Requirements Engineering?
In Agile development, requirements engineering adapts to support flexible and
iterative workflows. Instead of detailed upfront documentation, Agile focuses on
continuous collaboration, frequent feedback, and evolving requirements.
Key Characteristics of Agile Requirements Engineering:
• User Stories:
Requirements are captured as user stories, short descriptions of a feature
from the end user’s perspective. For example:
 “As a user, I want to reset my password so that I can regain access if I forget
it.”
• Incremental and Iterative:
Requirements evolve throughout the project. Teams work in short cycles
(called sprints) delivering small, functional pieces regularly. Feedback from
each sprint shapes the next set of requirements.
• Collaboration:
Constant communication between developers, customers, and stakeholders
helps clarify and prioritize requirements. This reduces misunderstandings
and adapts to changing needs quickly.
• Prioritization:
Requirements are prioritized based on business value and urgency. The
highest priority user stories are worked on first to maximize value early.
• Just Enough Documentation:
Documentation is lightweight and focused on what’s needed to build and
test the feature. Excessive paperwork is avoided to keep things agile.
Agile Requirements Engineering Process
1. Backlog Creation:
A product backlog is created containing user stories representing all
features and tasks.
2. Backlog Grooming:
The backlog is regularly reviewed and refined, adding details, splitting
stories, or reprioritizing.
3. Sprint Planning:
The team selects high-priority user stories from the backlog to implement
during the sprint.
4. Development and Feedback:
Stories are implemented, tested, and demonstrated at the end of each
sprint. Feedback is gathered and new or changed requirements are added
to the backlog.
 5. Continuous Improvement:
Teams reflect on the process and adapt their approach to requirements
engineering as needed.

Managing Requirements in an Acquisition Organization

What is an Acquisition Organization?
An acquisition organization is responsible for obtaining products, systems, or
services from external suppliers. This is common in government, defense, and
large enterprises where specialized solutions are purchased rather than developed
in-house.

Why is Requirements Management Important in Acquisition?

When an organization outsources a system or product, clear and complete
requirements are critical. They ensure that:
• The supplier understands what is needed.
• The product or service meets the organization’s expectations.
• Contracts are clear and enforceable.
• Project risks are minimized.

Key Activities in Requirements Management for Acquisition

1. Requirements Elicitation
Stakeholders define what they need.
This includes functional needs (what the system should do) and non-
functional needs (performance, security, etc.).
2. Requirements Specification
Documenting requirements clearly and in detail.
This specification becomes part of the contract and sets expectations for
the supplier.
 3. Request for Proposal (RFP) Preparation
The RFP includes the requirements and invites vendors to propose
solutions. Clear requirements help vendors estimate accurately.
4. Evaluation and Selection
Vendors are evaluated based on how well they can meet the requirements.
5. Contractual Agreement
The final contract is based on the agreed-upon requirements. It often
includes penalties for not meeting key requirements.
6. Monitoring and Verification
The organization monitors the supplier’s work to ensure they are meeting
the requirements, using tests, inspections, and progress reports.
7. Change Management
Requirements may need to change during the project. A formal process is
used to review, approve, and update changes while controlling impact on
cost and schedule.

Supplier Organizations
What is a Supplier Organization?
A Supplier Organization is a company or group that provides goods, services, or
systems to another organization, known as the client or customer. In project
development—especially in government, IT, and manufacturing—supplier
organizations are key players in delivering required solutions.

Role of Supplier Organizations

Supplier organizations play a critical role by:
• Understanding Customer Requirements:
They study the customer’s needs and expectations to deliver a solution that
meets the specified requirements.
 • Developing or Delivering the Product:
Suppliers either create custom solutions or deliver existing
products/services based on the contract.
• Maintaining Communication:
They keep regular contact with the client to report progress, get feedback,
and address changes.
• Ensuring Compliance:
Suppliers must follow standards, regulations, and contract terms defined by
the customer.

Responsibilities of Supplier Organizations

1. Requirements Analysis:
Carefully study the customer's requirements to ensure clarity and feasibility
before starting development.
2. Proposal Submission:
Provide detailed proposals in response to RFPs (Request for Proposals),
including cost, timeline, and how requirements will be met.
3. Project Planning:
Develop detailed project plans, including timelines, resources, and delivery
milestones.
4. Design and Development:
Build the system, product, or service according to the customer’s
specifications.
5. Quality Assurance:
Conduct internal testing to ensure the product meets all technical and
functional requirements.
6. Delivery and Deployment:
Deliver the final product to the customer and assist with setup, installation,
or training if required.
 7. Support and Maintenance:
Provide post-delivery support, updates, or warranty services based on the
contract.

Product Organizations
What is a Product Organization?
A Product Organization is a type of organization that focuses on designing,
developing, maintaining, and evolving products—either physical items (like
electronics, machinery) or digital systems (like software and apps). Their primary
goal is to deliver products that satisfy customer needs and generate value for the
business.

Key Responsibilities of a Product Organization

1. Understanding Market Needs:
They analyze the market and customer behavior to identify what kind of
products should be built.
2. Product Planning and Strategy:
Define product goals, roadmaps, and features aligned with business
objectives.
3. Requirements Engineering:
Gather, analyze, and prioritize user and stakeholder requirements to ensure
the product meets expectations.
4. Design and Development:
The engineering and design teams build the product based on the defined
requirements.
5. Testing and Quality Assurance:
Ensure the product works as intended and meets quality standards.
6. Product Delivery and Deployment:
Launch the product to users, often in phases or versions.
 7. Maintenance and Support:
Continuously improve the product based on user feedback, bug reports,
and evolving market needs.

Requirements Engineering for Agile

Methods
What is Requirements Engineering?
• The process of identifying, documenting, and managing the needs of a
system or product to ensure it meets user expectations.

How Agile Changes Requirements Engineering

• Agile emphasizes flexibility, collaboration, and iterative delivery.
• Less focus on detailed upfront documentation, more on continuous
communication and adaptation.

Key Features of Agile Requirements Engineering

• User Stories:
o Requirements captured as brief, user-focused stories.
o Example: “As a user, I want to reset my password so I can regain
access.”
• Product Backlog:
o A prioritized list of user stories and requirements.
o Continuously updated throughout the project.
• Incremental Delivery:
o Work is done in short iterations (sprints), delivering functional
features regularly.
• Stakeholder Collaboration:
 o Continuous communication with customers and stakeholders to
refine requirements.
• Minimal Documentation:
o Just enough detail to guide development; avoids heavy, inflexible
documents.

Agile Requirements Engineering Process