Requirements Engineering

Objectives
The objective of this module is to introduce software requirements and to explain the processes involved in discovering
and documenting these requirements.
▪ Understand the concepts of user and system requirements and why these requirements should be written in different
ways;
▪ Understand the differences between functional and non-functional software requirements;
▪ Understand the main requirements engineering activities of elicitation, analysis, and validation, and the relationships
between these activities;
▪ Understand why requirements management is necessary and how it supports other requirements engineering
activities.
What are Software Requirements?
•Definition:
Software requirements are the descriptions of the services and functionalities a system must provide, along with the
constraints and qualities it should satisfy.
They represent “what the system should do” rather than “how it should do it.”
________________________________________
Importance of Software Requirements
• Serve as a blueprint for design and development.
• Act as a communication bridge between customers, developers, and testers.
• Reduce misunderstandings and costly rework.
• Help in project estimation (time, cost, resources).
Types of Software Requirements
Software requirements are broadly divided into two categories:
A. Functional Requirements (FR)
•Define what the system should do.
•Specify system behavior, features, and services.
Examples:
1.A banking app must allow users to transfer money between accounts.
[Link] e-commerce app must provide search functionality for products.
3.A university system must allow students to register for courses.
B. Non-Functional Requirements (NFR)
•Define how the system should perform.
•Focus on quality attributes like performance, security, usability, reliability, etc.
Examples:
[Link] system should handle 1,000 users concurrently (Performance).
[Link] must be encrypted during transfer (Security).
[Link] mobile app should load within 3 seconds (Usability).
[Link] software must be scalable to support future features.
Levels of Requirements in Software Engineering
In software engineering, requirements are usually documented at three major levels:
[Link] Requirements
[Link] Requirements
[Link] (or Software) Requirements
Each level refines and adds detail to the previous one.
1. Business Requirements
•Definition: High-level statements that describe the overall goals, objectives, and needs of the organization.
•Audience: Business stakeholders (e.g., clients, managers, investors).
•Nature: Broad, abstract, and strategic.
•Purpose: Explain why the system is being developed.
Example – Online Banking System
•The bank wants to reduce customer service costs by providing online account management.
•The system should allow 24/7 banking services to increase customer satisfaction.

Business requirement example:

"Develop an online banking system to provide customers with 24/7 access to their accounts and reduce branch visits by
50% within the first year."
2. User Requirements
•Definition: Describe what the end users expect from the system.
•Audience: Users and system analysts.
•Nature: More detailed than business requirements, but still understandable by non-technical people. Often written in
natural language or use cases.
•Purpose: Capture what the user needs.

Example – Online Banking System

•Users must be able to log in securely using a username and password.
•Users should be able to transfer money between accounts.
•Users should be able to download account statements in PDF format.
User requirement example:
"A customer shall be able to transfer funds between their own accounts in less than 5 minutes."
3. System (or Software) Requirements
•Definition: Detailed technical specifications describing the functional and non-functional behavior of the system.
•Audience: Developers, testers, and project managers.
•Nature: Very detailed, precise, and often documented with models, UML diagrams, or formal specifications.
•Purpose: Serve as a blueprint for design, coding, and testing.
Example – Online Banking System
•The system shall validate user login credentials against the bank’s authentication database using SHA-256 encryption.
•The system shall process fund transfers and update both source and destination accounts within 3 seconds.
•The system shall generate monthly account statements in PDF format and store them for 7 years.

System requirement example:

"The system shall log out users automatically after 10 minutes of inactivity."
What are Software Requirements?
•A requirement describes what a software system should do or how it should perform.
•Two main types:
• Functional Requirements (FRs) – What the system should do.
• Non-Functional Requirements (NFRs) – How the system should work.

Functional Requirements (FRs)

Definition
Functional requirements specify the services, functions, and features that the software must provide.
Examples (E-commerce Website )
•User must be able to log in with a username & password.
•The system should allow users to search for products.
•The system must process online payments.
•Order confirmation email should be sent after purchase.
👉 They describe what the system does (behaviors).
Non-Functional Requirements (NFRs)
Non-functional requirements define the quality attributes, constraints, and standards of the system.
They describe how the system should work, not what it does.

Examples (E-commerce Website )

•Performance: Search results must load within 2 seconds.
•Security: Passwords must be stored using encryption.
•Scalability: System should support 10,000 concurrent users.
•Usability: The website must be mobile-friendly.
•Reliability: System uptime should be 99.9%.
👉 They describe how well the system works.
Key Differences Between FR & NFR

Non-Functional Requirements
Aspect Functional Requirements (FR)
(NFR)
What the system should do (functions, How the system should behave (quality
Focus
features). attributes).
Performance, Security, Scalability,
Examples Login, Search, Payment, Notifications.
Usability.
Nature Objective, task-oriented. Subjective, measurable quality constraints.
Verified through performance, security,
Testing Verified through functional testing.
usability tests.
Dependency Independent features. Apply across multiple features.
Real-Life Example – ATM System
Functional Requirements:
•User should be able to insert card and enter PIN.
•System must allow cash withdrawal and balance inquiry.
•ATM should print transaction receipt.

Non-Functional Requirements:
•Response time for cash withdrawal must be < 10 seconds.
•System should have 99.9% availability.
•PIN must be encrypted and secured.
 Requirements Engineering Process

What is Requirements Engineering?

Requirements Engineering (RE) is the systematic process of discovering, analyzing, documenting, validating, and
managing the requirements of a software system.
•Goal: Ensure that the final software meets the stakeholders’ needs and is feasible, complete, and consistent.

Phases of Requirements Engineering Process

The RE process typically consists of three major activities:

A. Requirements Elicitation & Analysis

B. Requirements Specification
C. Requirements Validation
A. Requirements Elicitation Requirements Analysis

•Gathering requirements from stakeholders (customers, •Analyzing the gathered requirements to:

users, domain experts). • Identify conflicts (e.g., one user wants feature A,

•Techniques used: another doesn’t).

• Interviews • Remove ambiguities (unclear language).

• Questionnaires • Prioritize requirements.

• Brainstorming Example:

• Prototyping •Conflict: Management wants fast checkout, but finance

• Observation team wants multiple verification steps.

Example (Online Shopping App): •Solution: Balance both by introducing one-click checkout

•Stakeholders say: “We need a feature to track orders in real with optional verification.

time.”
B. Requirements Specification
•Documenting the requirements in a structured format.
•Types of documents:
• SRS (Software Requirements Specification) – Formal document containing functional & non-functional
requirements.
• Use cases, UML diagrams, user stories.
Example:
"The system shall allow users to log in using email and password, and provide a ‘forgot password’ option."
C. Requirements Validation
•Checking whether requirements are correct, complete, consistent, and verifiable.
•Techniques used:
• Reviews
• Walkthroughs
• Prototypes
• Test-case generation
Example:
•A prototype of the shopping cart is shown to stakeholders for approval before final development.
Example Scenario – Online Food Delivery System

•Elicitation: Customers want order tracking, restaurant owners want menu flexibility.
•Analysis: Conflicts between fast delivery vs. delivery zone restrictions.
•Specification: SRS defines functional requirements (order placement, tracking) and non-functional requirements (system
uptime 99.9%).
•Validation: Prototype is tested by selected users.
•Management: Later, add support for contactless delivery due to new health regulations.
 Requirements Elicitation Techniques
Requirements Elicitation in Software Engineering
•Requirements Elicitation is the process of gathering requirements from stakeholders (clients, users, domain experts,
etc.) to understand what the system should do.
•It is the first step of Requirements Engineering and is often the most critical, because unclear or incomplete
requirements lead to project failure.

Techniques of Requirements Elicitation

1. Interviews
•Description: Direct conversation with stakeholders. Can be structured (fixed set of questions) or unstructured (open
discussion).
•Example: Asking a bank employee what features are needed in a mobile banking app.
2. Questionnaires/Surveys
•Description: Distributing a set of written questions to many users for feedback. Useful for large user bases.
•Example: Sending a survey to e-commerce customers asking what payment methods they prefer.

3. Brainstorming
•Description: A group activity where stakeholders and developers suggest ideas without criticism. Encourages creativity.
•Example: A team discusses what features an online learning platform should include (chat, quizzes, AI tutor, etc.).

4. Workshops / Joint Application Development (JAD)

•Description: Intensive sessions where users, clients, and developers work together to define requirements.
•Example: A healthcare software team conducts workshops with doctors and nurses to design an electronic medical
records (EMR) system.
5. Document Analysis
•Description: Studying existing documents, manuals, policies, or system logs to extract requirements.
•Example: Reviewing existing payroll system manuals to define requirements for a new HR system.

6. Prototyping
•Description: Building a quick working model of the system to clarify requirements through user feedback.
•Example: Showing a mock-up of a mobile app to customers before final development.

7. Use Cases / Scenarios

•Description: Writing narratives of how users will interact with the system.
•Example: A use case: “A student logs into the portal, views exam schedule, and downloads admit card.”

Summary:
•No single technique is perfect. Often, a combination is used.
•For example: Interviews + Observation + Prototyping is a powerful combo in most real-world projects.
 Software Requirement Specification
An SRS (Software Requirements Specification) is the authoritative contract of what a system must do and under what
constraints. It describes functional and non-functional requirements clearly enough that designers, developers, and testers
can build and verify the product.
Think: single source of truth for the product scope.

Why write an SRS?

•Aligns stakeholders (no hidden assumptions).
•Guides design & estimates (scope → effort/cost).
•Enables testing (turns into acceptance criteria & test cases).
•Reduces rework (early clarity is cheaper than late fixes).
•Supports compliance (audits, safety, security).
Qualities of a Good SRS
•Correct (matches stakeholder intent)
•Unambiguous (one interpretation only)
•Complete (all significant requirements stated)
•Consistent (no conflicts)
•Ranked (priority: Must/Should/Could/Won’t)
•Verifiable (measurable/ testable)
•Modifiable (well-structured, easy to update)
•Traceable (each requirement ↔ design, code, tests)

So in short: SRS is like a blueprint – it tells what the system must do (functional), how well it must do it (non-
functional), and the rules/constraints it must follow.
 Typical SRS Structure
1. Introduction
Describes what the system is, its scope, and purpose.
Example (Library Management System):
•Purpose: To manage borrowing/returning of books by students.
•Scope: The system will allow librarians to add/remove books, students to search, borrow, and return books.
•Intended Audience: Developers, testers, librarians, and administrators.

2. Overall Description
Provides a high-level view of the system and environment.
Example:
•Product Perspective: The system will replace the existing manual register-based system.
•User Characteristics: Librarians (moderate IT knowledge), Students (basic IT knowledge).
•Assumptions: Users will have valid login credentials and access to the internet.
3. System Features (Functional Requirements)
List of functions the software shall perform.
Example (Functional Requirements):
•FR-01: The system shall allow students to search for books by title, author, or subject.
•FR-02: The system shall allow librarians to add, edit, and remove books.
•FR-03: The system shall allow students to borrow a book if it is available.

4. External Interface Requirements

Specifies how the system interacts with users, hardware, and other systems.
🔹 Example:
•User Interface: Simple web-based UI with login page and search bar.
•Hardware Interface: Works on standard desktops/laptops with 4GB RAM.
•Software Interface: Database connectivity with MySQL.
•Communication Interface: Supports HTTPS protocol for security.
5. Non-Functional Requirements
Specifies quality attributes.
•Performance: Search results must be returned in ≤ 2 seconds.
•Security: Passwords shall be stored in encrypted format.
•Availability: System shall be available 99% of the time.
•Usability: Interface shall follow accessibility guidelines

6. Data Requirements
Describes what data will be stored/handled.
Example:
•Entities: Books, Students, Librarians, Borrowed Records.
•Data Retention: Borrow history stored for 5 years.
7. System Constraints
Limitations on technology, regulations, or resources.
Example:
•Must be implemented using Java and MySQL.
•System must comply with college IT security policy.

8. Use Cases / Scenarios

Step-by-step description of user interactions.
Example (Use Case: Borrow a Book):
[Link] logs in.
[Link] searches for book.
[Link] book is available → borrow → system updates record.
[Link] not available → system displays “Book not available”.
9. Appendices
Extra information, glossary, or references.
Example:
•Glossary: ISBN = International Standard Book Number.
•References: IEEE 830 SRS guidelines.

Mini Example Table (Snapshot)

Section Example (Library System)
Functional Requirement Students can borrow books.
Non-Functional Req. Search must respond ≤ 2s.
Interface Req. HTTPS connection required.
Data Requirement Store book records with ISBN.
Constraint Must use MySQL database.
 Use Case Diagrams
A Use Case Diagram shows who (actors) interacts with what (use cases) in a system to achieve goals. It’s a high-level
scope & interactions view—great for discussing requirements with non-technical stakeholders.

Core elements
•Actor: External role that interacts with the system (person, device, another system).
•System boundary: A box naming the system; use cases inside are in scope.
•Use case: An oval naming a goal the actor achieves (e.g., Place Order).
•Associations: Lines connecting actors ↔ use cases (interaction).
•Relationships (between use cases):
• «include»: Always reuse another use case (mandatory sub-flow).
• Example: Check out «include» Calculate Shipping.
• «extend»: Optional/conditional behavior that extends a base use case.
• Example: Login «extend» Two-Factor Authentication.
• Generalization: Actor or use case specialization (inheritance of behavior).
How to build one
[Link] actors (who/what is outside the system).
[Link] goals each actor wants from the system → name use cases.
[Link] associations and system boundary.
[Link] out common steps with «include»; add optional flows with «extend».
[Link] names goal-oriented and business-friendly (“Place Order”, not “SubmitOrderAPI”).
1. «include» in Use Case Diagrams
•Meaning:
• Used when one use case always uses the behavior of another use case.
• It’s like mandatory reuse of functionality.
•Notation:
• Dotted arrow with label «include».
• Direction: From the base use case to the included use case.
Example (E-commerce App):
• Check out «include» Calculate Total.
•Every time a customer checks out, the system must calculate the total — it’s unavoidable.
2. «extend» in Use Case Diagrams
•Meaning:
• Used when a use case adds optional or conditional behavior to another use case.
• The base use case works without it, but sometimes the extension is triggered.
•Notation:
• Dotted arrow with label «extend».
• Direction: From the extending use case to the base use case.
✅ Example (E-commerce App):
• Check out «extend» Apply Coupon.
•Normally, checkout happens without coupons.
•If the customer enters a coupon code, the Apply Coupon extension gets triggered.
Visual Mini Example
 UML Use Case Diagram Examples

Automated Teller Machine (ATM)

• Customer (actor) uses the bank ATM

to Check Balances of his/her bank
accounts, Deposit Funds, Withdraw
Cash and/or Transfer Funds (use
cases).
• ATM Technician provides
Maintenance and Repairs.
• All these use cases also involve the
Bank actor, whether it is related to
customer transactions or to the ATM
servicing.
 Airport Check-In and Security Screening
Business actors are Passenger, Tour
Guide, Minor (Child), Passenger with Special
Needs (e.g. with disabilities), all
playing external roles in relation to airport
business.
Business use cases are Individual Check-
In, Group Check-In (for groups of tourists),
Security Screening, etc. - representing
business functions or processes taking place
in the airport and serving the needs of
passengers.
Business use cases Baggage Check-in and
Baggage Handling extend Check-In use cases,
because passengers might have no luggage,
so baggage check-in and handling are
optional.
Online Shopping
Library Management
 User Stories

• Short, conversational requirements that capture who wants what and why, used to plan and deliver in iterations
• A User Story is a short, simple description of a software feature told from the perspective of the end-user.
• Captures who needs something, what they need, and why they need it.
• Used in Agile Software Development (especially Scrum) to manage requirements in a flexible, incremental way.

Structure of a User Story Examples (Food Delivery)

The most common template is: •As a customer, I want to pay with UPI so that
As a [user/role], I want [feature/function] so that [benefit/value]. checkout is faster.
•As a → identifies who (user role). •As a courier, I want to see optimized routes so
•I want → describes what they need. that I deliver on time.
•So that → explains why (the benefit).
 Acceptance Criteria (make stories testable)
Acceptance Criteria are conditions that a software product must meet for a feature (user story or requirement) to be
considered complete and acceptable..
👉 They define the “Definition of Done” for a user story.
👉 Think of them as the checklist that developers and testers use to confirm if a feature works correctly.

Use Given–When–Then to define the completeness of a user story.

Story: As a customer, I want to apply a coupon at checkout so that I save money.
Acceptance criteria
•Given a valid coupon When I apply it Then the order total reflects the discount.
•Given an expired coupon When I apply it Then I see “Coupon expired” and the total is unchanged.
•Given minimum order value not met When I apply the coupon Then I see “Min ₹500 required”.
Why Are Acceptance Criteria Important?
•Avoid ambiguity in requirements (no “I thought you meant…”).
•Provide a shared understanding between developers, testers, and stakeholders.
•Form the basis for test cases in QA.
•Help determine if a feature is ready for release.

Examples
Example 1: E-commerce App (User Story: Apply Coupon)
Story: As a customer, I want to apply a coupon during checkout so that I get a discount.
Acceptance Criteria:
•Given I have a valid coupon, When I enter it, Then the discount is applied to the total price.
•Given I enter an expired coupon, When I try to apply it, Then I see “Coupon expired” and no discount is applied.
•Given the cart total is below the coupon’s minimum order value, When I apply it, Then I see “Minimum order not
met.”
Example 2: Banking App (User Story: Login with Fingerprint)
Story: As a user, I want to log in with fingerprint so that I can access my account securely.
Acceptance Criteria:
•Fingerprint option is available on login screen for devices with fingerprint sensors.
•System allows 3 failed attempts → then fallback to password.
•Login is successful only if the fingerprint matches stored credentials.

Example 3: Online Learning Platform (User Story: Download Videos)

Story: As a student, I want to download lecture videos so that I can watch offline.
Acceptance Criteria:
•Download button visible for each video.
•Video downloads only if user is logged in.
•Downloaded file is encrypted and expires after 30 days.
 Formats of Acceptance Criteria (AC)

Why Different Formats?

•To make AC clear, testable, and unambiguous.
•To ensure both developers and testers understand the expectations.
Common Formats of Acceptance Criteria
1. Scenario-Oriented Format (Given–When–Then)
•Used in BDD (Behavior-Driven Development).
•Expresses AC as structured scenarios.
Format:
•Given [initial context]
•When [action taken]
•Then [expected result]
✅ Example (E-commerce App, User Story: Apply Coupon)
•Given I have a valid coupon, When I enter it at checkout, Then the discount should be applied to the total.
•Given I enter an expired coupon, When I apply it, Then I should see the message “Coupon expired” and the total
remains unchanged.
👉 Benefits: Highly testable, clear for automation.
2. Rule-Oriented (Bullet Points)
•Simple list of conditions that must hold true.
•Commonly used when scenarios are straightforward.
Format:
•Requirement shall [condition].
✅ Example (Banking App, User Story: Login with Fingerprint)
•Fingerprint option is available only on devices that support it.
•System allows 3 failed attempts, then asks for PIN/password.
•Login is granted only if fingerprint matches stored data.
👉 Benefits: Quick, concise, easy to read.
3. Checklist Format
•Similar to rules but written as a checklist for testers/stakeholders.
✅ Example (Online Learning Platform, User Story: Download Videos)
❑ Download button visible for each video.
❑ Only logged-in students can download.
❑ Downloads expire after 30 days.
❑ Encrypted storage of downloaded videos.
👉 Benefits: Easy for QA teams to track pass/fail.
4. Scenario Table Format
•Acceptance conditions represented in a tabular form for clarity.
✅ Example (ATM Withdrawal System, User Story: Withdraw Cash)

Condition Input Expected Output

Sufficient balance ₹2000 withdrawal Cash dispensed, balance updated

Insufficient balance ₹2000 withdrawal Error: “Insufficient funds”

Exceeds daily limit ₹30,000 withdrawal Error: “Limit exceeded”

5. Hybrid Format
•Combines scenario style + rules.
•Example: use Given-When-Then for key flows and bullets for edge cases.
✅ Example (Food Delivery App, User Story: Track Order)
•Scenario (Main flow):
• Given I am logged in, when I click “Track Order,” then I should see live order status.
•Rules (Edge cases):
• Tracking link expires 24 hours after delivery.
• If the courier app is offline, status shows “Last updated X minutes ago.”
👉 Benefits: Covers both main scenarios and exceptions efficiently.
Summary of Formats

Format Best For Example

Given–When–Then Testable workflows, BDD Applying a coupon at checkout
Rule-Oriented Simple, direct rules Login with fingerprint
Checklist QA verification Downloading videos
Scenario Table Input/output-heavy systems ATM withdrawals
Hybrid Combining flows + edge cases Food order tracking
 User Story Hierarchy

User stories are not all the same size. To manage complexity, Agile teams organize them into a hierarchy of levels:
[Link] → Broad business objective or large area of functionality.
[Link] → Big chunk of work that delivers value, but too large for one sprint.
[Link] Story → A small, sprint-sized requirement written in “As a…, I want…, so that…” format.
[Link]/Sub-task → Technical implementation steps to complete a story.
 Levels Explained with Examples
1. Theme (Highest Level)
•Represents a large business goal or strategic objective.
•Usually spans multiple epics.
Example (Food Delivery App):
•Theme: “Seamless Online Food Ordering.”

2. Epic
•A large user story that can’t be delivered in a single sprint.
•Needs to be broken down into smaller stories.
✅ Example (Food Delivery App):
•Epic 1: “Customer places an order.”
•Epic 2: “Courier delivers the order.”
3. User Story 4. Task / Sub-task (Lowest Level)
•Small, actionable requirement that fits into one sprint. •Technical implementation details of a user story.
•Written in standard user story format. •Assigned to developers/testers.
Examples under Epic: Customer places an order: ✅ Example (Story: Apply a coupon):
•As a customer, I want to browse restaurant menus so •Task 1: Create UI field for entering coupon code.
that I can decide what to eat. •Task 2: Validate coupon code against database.
•As a customer, I want to add items to my cart so that I •Task 3: Adjust total price after applying coupon.
can place an order. •Task 4: Write test cases for valid and invalid coupons.
•As a customer, I want to apply a coupon so that I can
get a discount.
Why User Story Hierarchy Matters
•Helps organize requirements from strategic to technical level.
•Makes large goals manageable.
•Supports backlog grooming and sprint planning.
•Ensures traceability from business goals → working software.
 Requirements Validation
Requirements Validation is the process of ensuring that the documented software requirements accurately represent
the needs, goals, and expectations of stakeholders.
It checks “Are we building the right product?” (vs. verification which asks, “Are we building the product right?”).

Objectives of Requirements Validation

[Link] requirements reflect stakeholder needs.
[Link] and correct errors, ambiguities, or inconsistencies early.
[Link] requirements are complete, correct, feasible, and testable.
[Link] costly rework later in design, coding, or testing.

👉 Studies show that fixing a requirements error after deployment can cost 100x more than fixing it during validation!
 Activities in Requirements Validation
1. Reviewing the Requirements Document
1. Conduct walkthroughs or inspections.
2. Look for missing, contradictory, or unclear requirements.

2. Prototyping
1. Build a simple prototype or mock-up of the system.
2. Stakeholders interact and give feedback.

[Link] Validation
1. Validate UML diagrams, use case models, or data models.
2. Check if they match real-world workflows.

[Link] Testing (Feasibility & Testability)

1. Ensure each requirement can be implemented and tested.
2. Example: “System should be user-friendly” ❌ (too vague), vs. “System should allow users to complete checkout
within 3 clicks” ✅.

[Link] & Completeness Check

1. No contradictions between requirements.
2. All critical features covered.
Techniques for Requirements Validation
[Link]/Inspections – Formal group examination of the SRS.
Example: Peer review of functional requirements for an ATM system.
[Link] – Build a partial system or UI mockup for feedback.
Example: Prototype of a mobile banking app login screen.
[Link]-case Generation – Derive test cases directly from requirements to check testability.
Example: From requirement “Password must be at least 8 characters”, create a test case with a 6-character password →
expect rejection.
[Link] – Predefined criteria to evaluate correctness, completeness, clarity, consistency, feasibility, and verifiability.
Example: ATM System Validation
•Requirement: “ATM shall dispense cash only if sufficient balance exists.”
•Validation:
• Review → No ambiguity? Yes.
• Prototype → Simulate withdrawal.
• Test case → Try withdrawing ₹2000 with only ₹1500 balance → Should fail.

Output of Requirements Validation

•Validated Software Requirements Specification (SRS)
•Identified defects/ambiguities with corrections
•Sign-off from stakeholders confirming agreement