1

Software
Engineering

Requirements
Engineering

Instructor: Engineer Sonia Rafaqat

 Introduction to
Requirements Engineering 2
Lecture #10
Process

Learning Objectives
Students will be able to: Understand the importance of requirements engineering
in software development.

Define the key phases of the requirements engineering

process.

Identify common challenges in the requirements

engineering process and how to overcome them.

Identify the key techniques used for gathering

requirements.

Understand the difference between functional and non-

functional requirements.

Understand the challenges and best practices for

capturing non-functional requirements.

By: Engineer Sonia Rafaqat

 Introduction to Requirements
Engineering Process 3
Requirements Engineering:
Requirements Engineering (RE) is the process of defining, documenting, and
maintaining the requirements for a software system. It helps ensure that the
development team understands what the client or user needs, and that the final
product is built to fulfill those needs. The RE process reduces ambiguity,
minimizes the risk of misunderstanding, and increases the likelihood of project
success.
Key Aspects of Requirements Engineering:

Identification of Needs: Understanding the needs of users and

stakeholders.

Documentation: Clearly and accurately documenting those needs as

requirements.

Validation: Ensuring that the requirements meet the stakeholders' needs.

Management: Handling changes in requirements over time.

By: Engineer Sonia Rafaqat

 Introduction to
Requirements Engineering 4
Process

Importance of Requirements Engineering:

Requirements engineering is critical for the success of any software project. Poorly defined requirements
are a leading cause of project failures, leading to products that do not meet user needs, missed deadlines,
and budget overruns. Requirement Engineering :

1. Clarifies Project Goals: Clearly defined requirements help the development team understand the
project scope and goals, reducing confusion and scope creep.

2. Minimizes Risk: By understanding requirements early, teams can mitigate risks related to unclear or
changing expectations.

3. Improves Communication: RE ensures effective communication between developers, stakeholders,

and users, aligning everyone on the project's goals.

4. Cost and Time Efficiency: Addressing requirements issues early prevents costly redesigns or project
delays later.

By: Engineer Sonia Rafaqat

 Introduction to
Requirements Engineering
Process
5

The Requirements Engineering Process:

The RE process consists of several key stages. Each stage is essential to ensuring that the software
system is developed according to the user's needs.

1. Requirements Elicitation:
• Objective: Gather information from stakeholders to understand their needs and expectations for the
system.
• Techniques: Interviews, surveys, observation, and brainstorming sessions are commonly used to
gather requirements.
• Challenges: Stakeholders may not fully understand or articulate their needs, or requirements may
conflict with each other.

2. Requirements Analysis:
• Objective: Analyze and prioritize the gathered requirements to identify conflicts, gaps, and feasibility.
• Key Activities: Clarifying ambiguous requirements, resolving conflicts, and determining the priority of
different requirements.
• Outcome: A refined set of requirements that can be realistically implemented.

3. Requirements Specification:
• Objective: Document the requirements in a structured format that all stakeholders can understand.
• Key Deliverable: The Software Requirements Specification (SRS), a detailed document that defines
functional and non-functional requirements.
By: Engineer Sonia Rafaqat
• Importance: The SRS serves as a blueprint for the development team, ensuring that they build the
 Introduction to
Requirements Engineering 6
Process

cont.
4. Requirements Validation:
• Objective: Ensure that the documented requirements accurately reflect stakeholder needs and are
feasible to implement.
• Techniques: Prototyping, reviews, and walkthroughs can be used to validate the requirements with
stakeholders.
• Outcome: Validation reduces the likelihood of miscommunication and ensures that the system will meet
user expectations.

5. Requirements Management:
• Objective: Handle changes to the requirements over the course of the project.
• Challenges: Requirements can change due to evolving business needs or market conditions, and these
changes must be managed to prevent project disruption.
• Techniques: Version control, change impact analysis, and traceability matrices help track changes and
assess their impact.

By: Engineer Sonia Rafaqat

 Introduction to
Requirements Engineering 7
Process
Role of Stakeholders in Requirements
Engineering:
Stakeholders play a critical role in the RE process. They provide input on what the
system should do and validate that the system will meet their needs.

Types of Stakeholders:

End Users: Those who will interact with the system directly.

Clients/Customers: The organization or individual paying for the software

development.

Developers: The team responsible for building the system.

Project Managers: Individuals responsible for ensuring the project stays on time
and within budget.

Regulators: Agencies or individuals who ensure the system complies with laws and
regulations.

By: Engineer Sonia Rafaqat

 Introduction to
Requirements 8
Engineering Process

Requirements Engineering
for the London Ambulance
System
(Case Study
1)
In the early 1990s, the **London Ambulance Service (LAS)** attempted to implement a new
computer-aided dispatch system to improve response times. However, the project failed due to
poorly managed requirements and miscommunications between stakeholders and developers.
 Introduction to
Requirements Engineering
Process
9

Requirements Gathering Techniques:

There are various techniques for gathering requirements, and the appropriate technique depends on
the project’s size, complexity, and the stakeholders involved. We will review some of the most
common techniques below.
1. Interviews:
One-on-one discussions with stakeholders to understand their needs and expectations.
• Best For: Projects where the stakeholders are few in number and where a deeper understanding of the
requirements is needed.
• Example: Conducting interviews with key stakeholders of an e-commerce website, such as the
marketing team, to understand their specific needs for user tracking and sales analysis.

2. Surveys/Questionnaires:
Written sets of questions sent to stakeholders to gather requirements.
• Best For: Projects with many stakeholders or users where direct interaction with each one is impractical.
• Example: A survey might be used to gather feedback from potential users of a mobile app to
understand which features are most desired.
3. Workshops:
• Group meetings with stakeholders and team members to collaboratively discuss and define
requirements.
• Best For: Projects that involve multiple stakeholders with potentially conflicting requirements.
• Example: A workshop for a hospital management system might include doctors, nurses, and
administrators to gather a broad range of requirements and perspectives.
By: Engineer Sonia Rafaqat
 Introduction to
Requirements Engineering
Process
10

cont.
4. Focus Groups:
A small group of stakeholders or users is brought together to discuss their needs and expectations for the
system.
• Best For: Projects where feedback from representative users or stakeholders is needed to validate ideas
or prototypes.
• Example: A focus group might be used to gather input from a select group of teachers for an online
education platform to refine specific features like grading systems or attendance tracking.

5. Observation (Job Shadowing):

Observing users in their natural environment to understand how they currently perform tasks that the
software will automate or improve.
• Best For: Projects where users may not be able to clearly articulate their needs or where real-world
context is important.
• Example: Observing customer service representatives at work to understand their workflow and identify
how a new CRM system could improve efficiency.

6. Prototyping:
Building a simple, working version of the system (or part of it) to help stakeholders visualize the end
product and provide feedback.
• Best For: Projects where requirements are not well understood or where stakeholders need help
By: Engineer articulating
Sonia Rafaqattheir needs.
• Example: A prototype of a banking app might be created to demonstrate the interface and transaction
 Introduction to
Requirements Engineering
Process
11

cont.
7. Document Analysis:
Reviewing existing documentation, such as manuals, reports, or regulations, to
gather information about the system requirements.
• Best For: Projects where detailed documentation exists that can inform the
requirements process.
• Example: Analyzing existing system documentation for a legacy inventory
management system to gather baseline requirements for an upgrade.

By: Engineer Sonia Rafaqat

 Introduction to Requirements
Engineering Process 12
Best Practices for Effective Requirements
Elicitation:
To ensure successful requirements elicitation, teams should follow these best
practices:
1. Use Multiple Techniques:
• Relying on a single technique (e.g., just interviews or just surveys) can lead to
incomplete requirements. Use a combination of techniques to gather a
comprehensive set of requirements.

2. Involve Stakeholders Continuously:

• Regularly engage stakeholders throughout the project to ensure their needs are
understood and incorporated.

3. Prioritize Requirements:
• Not all requirements have the same importance. Use prioritization techniques
(such as MoSCoW) to identify "Must-have" versus "Nice-to-have" requirements.

4. Validate Requirements:
• After gathering requirements, validate them with stakeholders through reviews,
prototypes, or walk-throughs to ensure accuracy and completeness.

5. Document Clearly:
• Use clear, unambiguous language to document requirements, avoiding technical
jargon where possible to ensure that all stakeholders understand the
requirements.

By: Engineer Sonia Rafaqat

 Introduction to
Requirements Engineering 13
Process

Common Challenges in Requirements Engineering:

Several challenges can arise during the RE process. Understanding these challenges helps teams
anticipate and mitigate potential issues.

1. Ambiguous Requirements:
Sometimes requirements are not clear or specific enough, leading to misunderstandings.
Solution: Use prototypes, user stories, and detailed descriptions to clarify requirements.

2. Changing Requirements:
Requirements may evolve due to changes in the business environment or user needs.
Solution: Implement a solid requirements management process to track changes and assess their impact.

3. Conflicting Requirements:
Different stakeholders may have conflicting needs or expectations.
Solution: Prioritize requirements based on the overall goals of the project and involve stakeholders in resolving
conflicts.

4. Communication Gaps:
Miscommunication between stakeholders and the development team can lead to inaccurate requirements.
Solution: Regular meetings, reviews, and feedback loops can ensure alignment between stakeholders and
developers.
By: Engineer Sonia Rafaqat
 Introduction to
Requirements 14
Engineering Process

Eliciting Requirements for the London

Heathrow Terminal 5 Baggage Handling
System
(Case Study
2) Handling System was designed to improve the
The London Heathrow Terminal 5 Baggage
efficiency of baggage handling at one of the busiest airports in the world. However, the system
faced significant challenges upon launch, with many bags being lost or delayed. This was largely
due to poorly gathered requirements.
 Functional & Non-Functional
Requirements 15
Functional Requirements:
Functional requirements specify what the system should do, focusing on the core
functionality and behavior of the software. These requirements describe the actions or
operations the system must perform to meet the needs of the users and stakeholders.

Key Characteristics:
Describes System Behavior: Functional requirements define specific tasks or actions
the system should carry out.

User-Oriented: These requirements are often written from the perspective of what the
user expects the system to do.

Can Be Tested: Functional requirements can be validated through testing to ensure the
system behaves as expected.

Examples:
1. User Authentication: The system must allow users to log in using a username and
password.

2. Search Functionality: The system must provide a search feature to allow users to
find items by keyword.

3. Data Entry and Validation: The system must allow users to input personal
information and validate the data for correctness (e.g., email format validation).

4. Payment Processing: The system must process credit card transactions securely.

By: Engineer Sonia Rafaqat

 Functional & Non-Functional
Requirements 16
Non-Functional Requirements:
Non-functional requirements describe the qualities or constraints of the system, focusing on
how the system performs its tasks rather than what the system does. These requirements
ensure that the system is usable, reliable, secure, and scalable, addressing aspects like
performance, security, and usability.
Key Characteristics:
Describes System Qualities: Non-functional requirements focus on system
performance, usability, and other qualities rather than specific actions.

System-Oriented: These requirements are often technical and describe how well the
system must perform under certain conditions.

Difficult to Test: Non-functional requirements can be harder to test directly, often

requiring performance metrics or user feedback for validation.

Key Characteristics:
1. Performance: The system must handle 1000 concurrent users without performance
degradation.

2. Security: The system must encrypt all sensitive user data using AES-256 encryption.

3. Usability: The system must allow a new user to learn how to navigate and use core
functions within 10 minutes.

4. Availability: The system must have an uptime of 99.99% over a one-month period.

5. Scalability: The system must be able to scale to accommodate a 50% increase in traffic
during peak hours.
By: Engineer Sonia Rafaqat
 Functional & Non-Functional
Requirements 17

Importance:
Both functional and non-functional requirements are critical to the success of a software
project. While functional requirements define what the system should do, non-functional
requirements ensure that the system performs those tasks efficiently, securely, and reliably.
Below are a few reasons:
1. Completeness: If you only capture functional requirements, you may build a system
that works but fails to meet user expectations for performance, reliability, or
security.

2. User Satisfaction: Non-functional requirements often directly impact the user

experience. A system that meets functional requirements but has poor performance
or usability will not satisfy users.

3. System Stability and Scalability: Non-functional requirements ensure that the

system can handle growth, is secure, and performs reliably, even under high loads.

By: Engineer Sonia Rafaqat

 Functional & Non-
Functional Requirements
18

Capturing Functional and Non-Functional

Requirements
Functional Requirements Capture
Techniques: Interviews, user stories, and use cases are often used to capture
functional requirements.

Non-Functional Requirements Capture

Techniques: Performance testing, benchmarking, and security assessments can
help capture non-functional requirements.

Challenges in Capturing Non-Functional

Requirements
• Vagueness: Non-functional requirements can often be vague or difficult to
quantify. For example, "The system must be fast" is a subjective requirement
that needs to be more specific.

• Measuring Success: Non-functional requirements can be challenging to test

and verify. Clear metrics or benchmarks should be set to measure success.

• Conflicting Priorities: Non-functional requirements, like performance and

security, can sometimes conflict. For example, increasing security measures
might slow down performance. Trade-offs may need to be made.

By: Engineer Sonia Rafaqat

 Functional & Non-Functional
Requirements 19
Best Practices for Defining Functional and Non-
Functional Requirements
Several challenges can arise during the RE process. Understanding these challenges helps teams
anticipate and mitigate potential issues.
1. Be Specific and Measurable:
• Ensure that each requirement, whether functional or non-functional, is clear, measurable, and testable. Example:
Instead of stating, "The system should perform well," define the specific performance targets, such as "The system
must handle 500 transactions per second."

2. Prioritize Requirements:
• Not all requirements are equally important. Work with stakeholders to prioritize both functional and non-functional
requirements, focusing first on "must-have" items. Example: Prioritize security requirements for a financial
application while performance might be more critical for an entertainment platform.

3. Balance Functional and Non-Functional Requirements:

• Functional requirements ensure the system works as intended, while non-functional requirements ensure it works
well. Both should be given attention in the project’s planning and development phases.

4. Use a Requirements Traceability Matrix (RTM):

• An RTM can help track which requirements have been implemented and tested, ensuring that both functional and
non-functional requirements are met during development. Example: A matrix that maps each non-functional
requirement, such as performance, to its corresponding test cases and results.

By: Engineer Sonia Rafaqat

 Functional & Non-
Functional Requirements
20

Functional and Non-Functional

Requirements in the Development of
Facebook
(Case Study)
When Facebook (now Meta) was developed, both functional and non-functional requirements
played key roles in shaping the platform. Initially, Facebook’s core functional requirements
included user registration, profile creation, posting updates, and connecting with friends.
However, as the platform grew, non-functional requirements became critical to its success.
 Functional & Non-Functional
Requirements 21

Lecture Task!
Why is stakeholder involvement critical to the success
of the requirements engineering process?

What are some techniques you can use to clarify

ambiguous requirements?

How would you prioritize functional and non-functional

requirements in a high-stakes project, such as an online
banking system?

What are some examples of non-functional

requirements that might conflict with each other, and
how would you handle these conflicts?
By: Engineer Sonia Rafaqat
 Introduction to
Requirements Engineering 22
Process

Lecture Task!
Why is stakeholder involvement critical to the success
of the requirements engineering process?

What are some techniques you can use to clarify

ambiguous requirements?

How can a team effectively manage changes in

requirements throughout the development process?

By: Engineer Sonia Rafaqat

 Introduction to
Requirements Engineering 23
Process

Food for
Thought!

Without self-
discipline
success is
By: Engineer Sonia Rafaqat