Unit 3: Requirements Engineering
Unit Learning Outcomes
At the end of this unit, the student must be able to:
1. Identify functional and non-functional requirements of a software system.
2. Apply requirements elicitation techniques to gather and analyze user needs.
3. Document and validate requirements using structured and standard specifications.
Introduction to Requirements Engineering
Requirements Engineering (RE) is a critical phase in software engineering that focuses on
understanding what a system should do and the constraints under which it must operate.
Many software project failures happen not because of poor coding, but because the system was
built based on unclear, incomplete, or incorrect requirements.
Requirements Engineering acts as the bridge between stakeholders (users, clients,
managers) and developers. It ensures that everyone has a shared understanding of the
system before development begins. A well-executed requirements engineering process reduces
rework, controls scope creep, and improves software quality and user satisfaction.
In real-world projects—such as mobile apps, banking systems, e-commerce platforms, and
school information systems—requirements engineering helps teams answer questions like:
● What problem are we solving?
● Who will use the system?
● What features are required?
● How secure, fast, and reliable should the system be?
1. Types of Requirements
1.1 Functional Requirements
Functional requirements describe what the system must do. These requirements define
specific behaviors, functions, or features of the system.
They answer the question:
What services should the system provide?
Characteristics of Functional Requirements
● Describe system behavior
● Focus on inputs, processes, and outputs
● Can usually be tested directly
Examples:
● The system shall allow users to register using email and password.
● The system shall generate a monthly sales report.
● The system shall allow students to view their grades online.
Simple Scenario:
In an online shopping system:
● Add items to cart
● Place an order
● Receive order confirmation
All of these are functional requirements.
1.2 Non-Functional Requirements
Non-functional requirements describe how well the system performs its functions. They focus
on quality attributes, constraints, and system characteristics.
They answer the question:
How should the system perform?
Common Types of Non-Functional Requirements
● Performance – response time, throughput
● Security – authentication, data protection
● Usability – ease of use, accessibility
● Reliability – system availability, fault tolerance
● Scalability – ability to handle growth
● Maintainability – ease of modification
Examples:
● The system shall respond to user requests within 2 seconds.
● User passwords must be encrypted.
● The system shall be available 99.9% of the time.
Comparison Example:
Functional Non-Functional
User can log in Login must be secure
User can upload files Upload must complete within 5 seconds
2. Stakeholder Analysis
Definition
Stakeholders are individuals or groups who have an interest in the system or are affected by it.
Stakeholder analysis identifies:
● Who the stakeholders are
● Their roles and expectations
● Their influence on the system
Types of Stakeholders
● Primary stakeholders – end users, clients
● Secondary stakeholders – developers, testers
● Key stakeholders – project sponsors, managers
● External stakeholders – regulators, third-party services
Example:
For a school management system:
● Students – want easy access to grades
● Teachers – want efficient grade submission
● Administrators – want accurate reports
● IT staff – want maintainable systems
Importance of Stakeholder Analysis
● Avoids conflicting requirements
● Ensures all user needs are considered
● Helps prioritize features
3. Requirements Elicitation Techniques
Requirements elicitation is the process of gathering requirements from stakeholders.
3.1 Interviews
● One-on-one or group discussions
● Structured or unstructured
Advantages:
● Detailed information
● Clarifies user expectations
Disadvantages:
● Time-consuming
● Depends on communication skills
3.2 Questionnaires and Surveys
● Written questions distributed to many users
Advantages:
● Cost-effective
● Reaches many stakeholders
Disadvantages:
● Limited depth
● Low response rate
3.3 Observation
● Watching users perform tasks
Example: Observing a cashier using a POS system to identify inefficiencies.
3.4 Workshops and Focus Groups
● Group discussions facilitated by analysts
Benefits:
● Encourages collaboration
● Resolves conflicts early
3.5 Prototyping
● Creating mock-ups or early versions of the system
Benefits:
● Helps users visualize requirements
● Reduces misunderstandings
4. Requirements Specification (SRS)
Definition
A Software Requirements Specification (SRS) is a formal document that clearly describes the
system’s requirements.
Purpose of an SRS
● Acts as a contract between client and developers
● Guides design and development
● Serves as a reference for testing
Typical SRS Structure
1. Introduction
2. Overall Description
3. Functional Requirements
4. Non-Functional Requirements
5. System Models
6. Assumptions and Constraints
Characteristics of a Good SRS
● Clear and unambiguous
● Complete
● Consistent
● Verifiable
● Modifiable
5. Requirements Validation and Management
5.1 Requirements Validation
Validation ensures that requirements:
● Reflect real user needs
● Are complete and correct
● Are feasible to implement
Validation Techniques
● Reviews and inspections
● Prototyping
● Test case generation
● Stakeholder approval
5.2 Requirements Management
Requirements management deals with handling changes throughout the project lifecycle.
Key Activities:
● Version control
● Change requests
● Impact analysis
● Traceability
Example:
If a client requests a new feature, the team analyzes:
● Cost impact
● Schedule changes
● Technical feasibility
6. Use Cases and User Stories
6.1 Use Cases
A use case describes how a user interacts with the system to achieve a goal.
Components of a Use Case
● Actor
● Use case name
● Description
● Main flow
● Alternative flows
Example: Use Case: Submit Assignment Actor: Student
6.2 User Stories
User stories are short, simple descriptions used in Agile development.
Format:
As a [user], I want [feature], so that [benefit].
Example:
● As a student, I want to view my grades online so that I can track my performance.
Difference Between Use Cases and User Stories
Use Case User Story
Detailed Simple
Formal Informal
Traditional models Agile methods
Guide Questions
1. Why are non-functional requirements as important as functional requirements?
2. What problems may occur if stakeholders are not properly identified?
3. How does an SRS help prevent project failure?
4. When should user stories be preferred over use cases?
Activity
Activity: Mini Requirements Engineering Exercise
Students will:
1. Choose a simple system (e.g., online food ordering, library system).
2. Identify at least 5 functional and 5 non-functional requirements.
3. Identify stakeholders.
4. Write 3 user stories.
5. Present and validate requirements with groupmates.
Exercises
1. Identifying Requirements
Objective:
● Identify functional and non-functional requirements.
Instructions:
1. Choose one system:
○ Online Food Ordering System
○ Library/Hospital Management System
○ Student Information System
2. List at least:
○ 5 Functional Requirements
○ 5 Non-Functional Requirements
Output:
● Requirements list (table format)
2. Stakeholder Analysis and Elicitation
Objective:
● Identify stakeholders and apply elicitation techniques.
Instructions:
1. Using the same system from Exercise 1:
○ Identify at least 4 stakeholders
○ Describe their roles and expectations
2. Select two elicitation techniques (e.g., interview, survey, observation).
3. Create sample questions for each technique.
Output:
● Stakeholder table
● List of elicitation questions