Software Requirements Engineering

Chapter 1: Importance of Requirement Analysis

Introduction
In software engineering, requirement analysis is a systematic process of identifying,
documenting, and validating the needs and expectations of stakeholders for a software
application. It forms the foundation for system design and development. Misunderstood or
poorly documented requirements often lead to project delays, budget overruns, or even
complete failure.

Why Requirement Analysis is Crucial

Reason Explanation
Foundation for Provides a clear, agreed-upon reference for what the software
Development should do.
Cost Efficiency Errors in requirements are exponentially more expensive to fix at
later stages.
User Satisfaction Ensures software meets the actual needs and expectations of
users.
Project Scope Prevents scope creep by clearly defining what is within and outside
Control the project’s boundaries.
Risk Mitigation Early identification of technical or business risks reduces project
uncertainties.

Example
If a client wants an online ticket booking system, clear requirement analysis ensures:

• The system allows selecting seats.

• Integrates with a payment gateway.
• Generates e-tickets.
If requirements are vague like “make it user-friendly”, it could mean different things to
different stakeholders.
Merits of Proper Requirement Analysis
• Reduces project failure chances.
• Aligns technical and business teams.
• Builds stakeholder confidence.
• Provides a basis for testing and validation.
• Enhances maintainability.

Demerits of Poor Requirement Analysis

• High rework cost.
• Frequent requirement changes.
• User dissatisfaction.
• Incomplete or conflicting system features.
• Project delays and overruns.

Diagram: Software Requirement Analysis in SDLC

[User Needs] --> [Requirement Gathering] --> [Requirement Analysis] -->
[SRS Document] --> [Design]

Chapter 2: Understanding User Needs, Software Features, and

Requirements

Introduction
A successful software system must address the actual needs of its intended users. To
achieve this, developers must clearly understand three interconnected concepts:

• User Needs
• Software Features
• Software Requirements
Misunderstanding these concepts can lead to building a system that, while technically
sound, fails to satisfy its users.
User Needs
User needs are high-level desires or problems that stakeholders expect the software to
address. They usually lack technical precision and are often described in layman’s terms.

Characteristics:
• Often vague and subjective.
• Focus on what users want to achieve.
• Serve as a foundation for deriving software features and requirements.

Example:
A user wants an online library system where books can be reserved remotely.

Software Features
Software features are specific, user-facing functionalities derived from user needs. They
bridge the gap between informal user needs and formal software requirements.

Characteristics:
• Focus on what the software will offer.
• Directly visible to the end-user.
• Typically grouped under product marketing and UI discussions.

Example:
From the earlier user need:

• Online book reservation.

• View book availability.
• Manage user accounts.

Software Requirements
Software requirements are precise, testable, and formal statements detailing what the
software system must do.

Types:
• Functional Requirements: Define specific behaviors or functions.
• Non-Functional Requirements: Define system qualities or attributes
(performance, security, usability).
Example:
Functional Requirement:

• The system shall allow registered users to reserve books through an online
interface.
Non-Functional Requirement:

• The system shall support up to 500 simultaneous users without performance

degradation.

Comparison Table
Aspect User Needs Software Features Software Requirements
Definitio High-level goals or User-visible Formal, testable system
n problems. functionalities. specifications.
Specificit Vague Moderately specific Highly specific
y
Audience End-users, clients Users, marketers, Developers, testers,
developers managers
Formality Informal Semi-formal Formal

Merits of Clear Distinction

• Ensures all stakeholders have a common understanding.
• Prevents scope misunderstandings.
• Facilitates accurate estimation and planning.
• Enhances communication between technical and non-technical teams.

Demerits if Ignored
• Risk of building unnecessary features.
• Potential user dissatisfaction.
• Project delays due to misalignment.
• Wasted resources on unimportant aspects.

Chapter 3: Classes of User Requirements

Introduction
Requirements are not static — some remain stable while others evolve due to changes in
business processes, market needs, or technology. To manage this, requirements are
classified into two main types:

• Enduring Requirements
• Volatile Requirements

Enduring Requirements
Enduring requirements are those that reflect the core business needs of a system and tend
to remain stable over time. They typically originate from organizational policies, essential
business functions, or domain-specific rules.

Characteristics:
• Stable and long-lasting.
• Tied to fundamental business operations.
• Rarely subject to change.

Example:
A hospital management system must securely store patient medical records.

Volatile Requirements
Volatile requirements are those likely to change during a system’s lifecycle. They evolve
due to shifting user needs, market trends, or technological advancements.

Characteristics:
• Frequently updated.
• Driven by external influences.
• Need regular reassessment.

Example:
An online shopping platform should integrate with the latest digital payment APIs.
Comparison Table
Feature Enduring Requirements Volatile Requirements
Stability Stable over time Likely to change during system
evolution
Origin Core business policies, essential User feedback, market trends,
functions new tech
Change Frequency Rare Frequent
Impact on System Forms the base of system Requires modular, flexible
Design architecture design

Merits of Categorization
• Simplifies change management.
• Helps prioritize requirement implementation.
• Aids in project scope control.
• Supports risk assessment.

Demerits if Ignored
• Uncontrolled changes may disrupt project timelines.
• Risk of overlooking core system functionalities.
• Difficulty in project estimation and resource allocation.

Chapter 4: Sub-phases of Requirement Analysis

Introduction
Requirement analysis is not a single monolithic activity but consists of several sub-phases
that ensure accurate and reliable gathering and definition of requirements.

Sub-phases Explained
Requirements Discovery (Elicitation)
• Involves interacting with stakeholders to gather initial requirements.
• Tools: interviews, questionnaires, observation, document analysis.
Requirements Classification and Organization
• Grouping related requirements.
• Organizing them into categories: functional, non-functional, enduring, volatile.

Requirements Prioritization and Negotiation

• Resolving conflicts between stakeholders.
• Assigning priorities to ensure essential features are developed first.

Requirements Specification
• Converting gathered and organized requirements into formal, documented form.
• Typically results in an SRS document.

Diagram: Sub-phases Workflow

[Discovery] ➔ [Classification] ➔ [Prioritization] ➔ [Specification]

Merits
• Structured process ensures completeness.
• Simplifies conflict resolution.
• Enhances requirement traceability.

Demerits if Skipped
• Increased chance of missing critical requirements.
• Poorly prioritized features.
• Incomplete or conflicting specifications.

Summary
Dividing requirement analysis into sub-phases ensures systematic, accurate, and efficient
documentation of what the system must achieve.

Chapter 5: Functional vs Non-Functional Requirements

Introduction
Requirements are broadly classified into Functional Requirements and Non-Functional
Requirements. This classification is essential as it influences design, development,
testing, and validation activities.

Functional Requirements
These describe what the system should do. They outline specific behaviors or functions.
Examples
• User authentication and login functionality.
• Generating monthly sales reports.
• Sending notifications to users.

Merits
• Clear system behavior description.
• Helps in system validation.
• Guides developers in feature implementation.

Demerits
• Overlooking operational aspects like performance or security.

Non-Functional Requirements
These describe how the system performs its functions. They relate to system attributes
like performance, reliability, and usability.

Categories
• Product Requirements: Performance, reliability, usability.
• Organizational Requirements: Standards, legal constraints.
• External Requirements: Interoperability, legal compliance.

Examples
• The system shall respond to any user action within 1 second.
• The software shall comply with GDPR regulations.

Merits
• Ensures the system meets quality standards.
• Enhances user satisfaction.

Demerits
• Difficult to quantify.
• Often overlooked in early development.
Differences Table
Feature Functional Requirements Non-Functional Requirements
Defines What the system should do How the system should perform
Type Behavior-based Performance/attribute-based
Example User can reset password System shall respond within 1 sec
Testing By functional test cases By measuring attributes like speed
Importance Core operations Quality assurance

Chapter 6: Barriers to Eliciting User Requirements

Introduction
Eliciting user requirements is one of the most challenging aspects of requirements
engineering. Several barriers prevent the clear, complete, and correct capture of user
needs.

Common Barriers
Ambiguity
Users might express requirements vaguely or use non-technical language, leading to
misunderstanding. - Example: “The system should be fast” — fast in terms of what metric?

Conflicting Requirements
Different stakeholders may have differing or opposing needs. - Example: Marketing wants
frequent UI updates; Operations prefers long-term stability.

Changing Requirements
Business, technology, and market conditions evolve, causing requirements to shift during
development.

Communication Gaps
Stakeholders and developers may not share a common vocabulary or technical
understanding.

Organizational Politics
Internal power struggles or hidden agendas may prioritize certain features over others
irrationally.
Merits of Recognizing These Barriers
• Proactively planning mitigation strategies.
• Improves elicitation accuracy.
• Enhances communication clarity.

Demerits if Ignored
• Leads to incomplete, inconsistent, or invalid requirements.
• Increased rework and development costs.

Chapter 7: The Software Requirements Document and SRS Standards

What is a Software Requirements Specification (SRS)?
A Software Requirements Specification (SRS) is a formal document that systematically
captures all the software system’s requirements. It acts as a communication bridge
between stakeholders and developers, ensuring mutual clarity and agreement.

Characteristics of a Good SRS

• Correct: Accurately describes system requirements.
• Unambiguous: Each requirement has only one interpretation.
• Complete: Contains all significant requirements.
• Consistent: No conflicting requirements.
• Verifiable: Each requirement is testable.
• Modifiable: Easy to update.
• Traceable: Easy to trace requirements throughout the project lifecycle.

Standard Structure of an SRS

1. Introduction
2. Overall Description
3. Specific Requirements
4. External Interface Requirements
5. Appendices and Glossary
6. Index

Merits of a Well-Defined SRS

• Prevents scope creep.
• Acts as a reference for design, development, and validation.
• Enhances project estimation and planning.
• Reduces misunderstandings and rework.
Demerits if Poorly Created
• High risk of project failure.
• Frequent requirement changes.
• Stakeholder dissatisfaction.

Example Structure (For an Online Bookstore)

1. Introduction
o Purpose
o Scope
2. Overall Description
o Product perspective
o User characteristics
3. Specific Requirements
o Functional: Book search, purchase, user registration
o Non-Functional: Response time under 2 seconds

Chapter 8: Requirements Engineering Process

What is Requirements Engineering (RE)?
Requirements Engineering (RE) is the discipline concerned with identifying, documenting,
and maintaining a system’s requirements. It ensures that the software developed meets
business and user expectations effectively.

Phases of Requirements Engineering

1. Feasibility Study
o Assesses if the project is technically, operationally, and financially feasible.
2. Requirements Elicitation and Analysis
o Interacting with stakeholders to gather system requirements.
o Analyzing gathered information for conflicts, inconsistencies, and gaps.
3. Requirements Specification
o Documenting the gathered requirements formally, typically in an SRS
document.
4. Requirements Validation
o Ensuring documented requirements accurately reflect stakeholder needs
through reviews, inspections, and prototyping.
5. Requirements Management
o Handling requirement changes, traceability, and version control throughout
the project lifecycle.
Merits of a Proper RE Process
• Reduces project risks.
• Enhances system quality.
• Facilitates stakeholder communication.
• Ensures timely identification and resolution of issues.

Demerits if Poorly Executed

• Increased project cost.
• Delays and missed deadlines.
• Misaligned product delivery.
• User dissatisfaction.

Diagram: Requirements Engineering Process

[Feasibility Study] --> [Elicitation & Analysis] --> [Specification] -->
[Validation] --> [Management]

Chapter 9: Case Study — SRS for a Real-Time System

Introduction
Real-time systems are software applications where the correctness depends not only on
the logical result of computations but also on the time at which the results are produced.
Safety-critical systems like medical devices or industrial control systems often fall in this
category.

Example 1: Insulin Pump Control System

• Type: Embedded, real-time, safety-critical.
• Key Functional Requirements:
o Deliver insulin dosage accurately.
o Monitor blood glucose levels at regular intervals.
o Raise alarms on sensor failures.
• Key Non-Functional Requirements:
o High system availability.
o Fault tolerance.
o Quick response time under 500 milliseconds.

Example 2: Mental Health Care Patient Management System (MHC-

PMS)
• Type: Medical information system.
 • Key Functional Requirements:
o Store patient details and treatment records.
o Schedule appointments.
o Track prescriptions and lab results.
• Key Non-Functional Requirements:
o Data security and privacy compliance.
o System availability of 99.9%.
o Audit trail of data access.

Merits of Using Real-World Case Studies

• Clarifies requirement specification structure.
• Demonstrates integration of functional and non-functional requirements.
• Highlights domain-specific constraints.
• Enhances learning through practical scenarios.

Demerits if Ignored
• Poor system performance.
• Overlooked safety and legal requirements.
• Costly post-deployment fixes.
• User dissatisfaction and operational hazards.

Chapter 10: Tools for Requirements Gathering

Document Flow Charts
• Visualize the flow of documents, forms, and data within a system.
• Useful for understanding existing processes and identifying inefficiencies.
• Merits:
o Easy to understand and communicate.
o Helps detect redundancies.
• Demerits:
o Can become complex for large systems.
o Limited in expressing decision-based processes.

Decision Tables
• A tabular representation of different conditions and corresponding actions.
• Ideal for systems with complex decision logic.
• Merits:
o Simplifies handling of numerous conditions.
 o Uncovers missing or conflicting rules.
• Demerits:
o Can grow unwieldy with too many conditions.
o Difficult to modify without software tools.

Decision Trees
• A graphical way to visualize conditions and outcomes as branches.
• Easier to interpret than tables when dealing with few conditions.
• Merits:
o Intuitive and readable.
o Highlights decision paths clearly.
• Demerits:
o Becomes large and cluttered with many branches.
o Harder to update than tables for frequent changes.

Chapter 11: Structured Analysis Tools

Data Flow Diagrams (DFDs)
• Illustrate how data moves through a system.
• Depict processes, data stores, data sources, and destinations.
• Levels of DFD:
o Context Level (Level 0): Overview of the entire system as a single process.
o Level 1 DFD: Breaks the main process into major subprocesses.
o Level 2 DFD: Further decomposes Level 1 processes.
• Merits:
o Easy visualization of data processing.
o Simplifies system understanding.
• Demerits:
o Not suitable for capturing control logic.
o May oversimplify complex interactions.

Data Dictionary
• Repository containing definitions, formats, and usage of all data elements in a
system.
• Ensures consistency and clarity of data usage across documentation.
• Merits:
o Promotes data integrity.
o Reduces data ambiguity.
 • Demerits:
o Needs regular updates with requirement changes.
o Can become complex for large systems.

Chapter 12: Non-Traditional Requirements Analysis Tools

Finite State Machines (FSM)
• Model system behavior as states and transitions.
• Useful for embedded, control, and communication systems.
• Merits:
o Precise representation of control logic.
o Predictable system modeling.
• Demerits:
o Can be cumbersome for large systems.
o Hard to integrate with data-rich processes.

Statecharts
• Extended FSMs with hierarchy, concurrency, and broadcast communication.
• Better for modeling complex, reactive systems.
• Merits:
o Manage complex states elegantly.
o Incorporate parallel and nested states.
• Demerits:
o Steep learning curve.
o Requires advanced tooling support.

Petri Nets
• Mathematical modeling tool for concurrent, distributed systems.
• Consist of places, transitions, and tokens.
• Merits:
o Good for detecting deadlocks and resource conflicts.
o Supports formal analysis.
• Demerits:
o Complex for non-mathematical users.
o May require specialized software.