Chapter - 2

Software requirement and specification

Course Outline
➢Introduction SRS, Classification of requirements
➢The Software Requirements Document (SRS)
➢Requirements Engineering Process
➢Requirements Elicitation
➢Requirements Analysis and Modeling
➢Requirements Specification
➢Requirements Validation
➢Example
Introduction Software requirement and specification

▪ SRS is a formal document that describes in detail what the software

system will do and how it will perform its functions.
▪ It serves as a bridge between the customer’s needs and the
developer’s design and implementation.
▪ According to Sommerville, an SRS defines:
“The complete description of the behavior of a system to be
developed, including both functional and non-functional requirements.”
Introduction Software requirement and specification

Software requirements
▪ It describe what the system should do.
▪ Constraints are restrictions on the solution space of a software system.
▪ Software requirements are capabilities that the system must deliver.
▪ They express the needs and expectations of customers and users
that must be satisfied by the software.
▪ Requirements can be viewed from two levels:
✓User Requirements
✓System Requirements
Introduction Software requirement and specification
Introduction Software requirement and specification

A feasibility study is a short, focused study that should take place

early in the Requirements engineering process.

It should answer three key questions:

1. Does the system contribute to the overall objectives of the

organization?

2. Can the system be implemented within schedule and budget using

current technology? and

3. Can the system be integrated with other systems that are used?
Introduction Software requirement and specification

❖ Importance of Requirements in the Software Development

Lifecycle
▪ It is the foundation of design, implementation, testing, and
maintenance.
▪ Clearly defined requirements ensure that:
✓Developers know what to build.

✓Customers know what to expect.

✓Testers know what to verify.

Introduction Software requirement and specification

❖ Importance of Requirements in the Software Development

Lifecycle
▪ Well-written requirements reduce ambiguity, rework, and
project delays.
▪ Requirements act as a contract between the customer and
development team.
Poor requirements → poor software;
Good requirements → successful, high-quality software.
Introduction Software requirement and specification
Relationship Between Requirements and Other Software
Engineering Activities
Activity Relationship to Requirements
Uses requirements as the input to determine
System Design
architecture and components.
Implementation Developers translate requirements into executable code.
Testing Test cases are derived directly from the requirements.
Requirement changes are common after delivery;
Maintenance
updated requirements guide software modification.

▪ The requirements phase connects customer needs with technical development.

▪ A misunderstanding at this stage can propagate errors throughout the entire
project.
Introduction Software requirement and specification
The Cost of Errors in Requirements

▪ Mistakes made during the requirements phase are the most

expensive to fix later in development.

▪ The cost of correcting a requirement error increases exponentially

the later it is discovered.
Example:
✓Error found during requirements stage → low cost
✓Error found during testing → 10× more costly
✓Error found after deployment → up to 100× more costly
Introduction Software requirement and specification

The Cost of Errors in Requirements

▪Causes include:
✓Miscommunication with stakeholders
✓Incomplete or ambiguous requirements
✓Lack of validation and review
Classification of requirements
❖User Requirements:
✓High-level natural language descriptions of what users expect
✓Typically written for customers and end-users

❖System Requirements:
✓Detailed functional and non-functional specifications
✓Define what should be implemented in the system

❖Functional vs. Non-functional Requirements:

✓Functional: describe system behavior or functions
e.g., login, report generation
✓Non-functional: describe quality attributes
e.g., performance, quality, safety, interface, security
Classification of requirements

User Requirements
▪ User requirements are high-level descriptions of the system’s
functions and constraints, written in natural language (often with
simple diagrams or use cases).

▪ They express what the users and customers expect from the system.

▪ Example: library system

Classification of requirements

User Requirements
▪ Characteristics:
✓Written for non-technical stakeholders (e.g., clients, managers,
end-users).
✓Expressed in a way that is easy to understand.
✓Focus on what the system should do, not how it will be done.
✓Often included in a requirements document as an overview.
Classification of requirements

System Requirements
▪ System requirements provide a detailed and precise specification
of the system’s functions, services, and constraints.
▪ They describe what should be implemented by developers and form
the basis for system design.
Example:
The system shall store user search queries in a database
Classification of requirements

System Requirements
Characteristics:
✓Written for software engineers and system designers.
✓Can be expressed using structured language, models, or formal
methods.
✓Include both functional and non-functional specifications.
✓Serve as a contract between the client and the development team.
Classification of requirements

Functional vs. Non-functional Requirements

Functional Requirements

▪ it describe the specific behaviors, services or functions that the

system must provide.

▪ They define what the system should do in response to particular

inputs or situations.

▪ Its’ purpose is to ensure the system provides all the necessary

features and operations to satisfy user needs.
Classification of requirements

Functional vs. Non-functional Requirements

Functional Requirements

▪ Examples:
✓“The system shall allow users to log in using a username and
password.”
✓“The system shall generate monthly sales reports.”
✓“The ATM shall dispense cash when a valid PIN is entered.”
Classification of requirements

Functional vs. Non-functional Requirements

Non-functional Requirements

▪ It describe the quality attributes or constraints of the system how

the system performs its functions rather than what it does.

▪ Examples: Performance, Reliability, Usability, Security.

▪ Its’ purpose is to determine user satisfaction and system quality.

Even if all functional requirements are met, poor performance or
usability can lead to system failure.
Classification of requirements

Metrics for specifying nonfunctional requirements

Property measure
Speed Processed transactions/second User/event response time
Screen refresh time
Size Megabytes/Number of ROM chips
Ease of use Training time Number of help frames
Reliability Mean time to failure Probability of unavailability Rate of
failure occurrence Availability
Robustness Time to restart after failure Percentage of events causing
failure Probability of data corruption on failure
Portability Percentage of target dependent statements Number of
target systems
Classification of requirements
Summary

▪ User requirements describe what users need in simple language.

▪ System requirements define technical details of what will be built.

▪ Functional requirements specify what the system does.

▪ While Non-functional requirements specify how well it performs

those functions.

▪ A successful software project requires all types of requirements

to be clearly defined, documented, and validated.
SRS Document

▪ Purpose and importance of the SRS

▪ Characteristics of a good SRS
(complete, consistent, verifiable, modifiable)

▪ Standard structure of an SRS document (IEEE Std 830):

▪ Introduction
▪ Overall description
▪ System features
▪ External interface requirements
▪ Non-functional requirements
▪ Other requirements
SRS Document
▪ The main purpose of an SRS is to ensure a clear and mutual
understanding between clients, users, and developers regarding what the
system should achieve.

▪ Importance:
✓Communication tool: Acts as a contract between customer and developer.
✓Project foundation: Guides system design, coding, and testing.
✓Verification reference: Helps verify that the final product meets the stated
requirements.
✓Maintenance support, Reduced cost
A good SRS ensures the right product is built, and the product is built right.
SRS Document
According to Sommerville and IEEE Std 830 a high-quality SRS should
possess the following characteristics:

Characteristic Explanation
All significant requirements are included.
Complete
No necessary function or constraint is left out.
There are no conflicting requirements or contradictions within
Consistent
the document.
Every requirement can be tested or measured to confirm it has
Verifiable
been met.
Modifiable The structure allows easy updates and revisions when
requirements change.
SRS Document
Standard Structure of an SRS Document (IEEE Std 830)
The IEEE 830 standard provides a recommended structure for writing a Software
Requirements Specification.
✓ Introduction
✓ Purpose of the document
✓ Scope of the software system
✓ Definitions, acronyms, and abbreviations
✓ References to related documents
✓ Overview of the rest of the SRS

Example: “This document describes the requirements for the Online Library
Management System.”
Requirements Engineering Process

▪ Steps in Requirements Engineering:

✓Feasibility Study
✓Requirements Elicitation and Analysis
✓Requirements Specification
✓Requirements Validation
✓Requirements Management
Requirements Engineering (RE)
RE is a systematic process of discovering, documenting, and maintaining the
requirements for a software system.
It focuses on understanding what the system should do and the constraints under
which it must operate.
According to Ian Sommerville (10th Edition):
“Requirements engineering is the process of establishing the services that the
customer requires from a system and the constraints under which it operates and is
developed.”
The RE process is iterative which means requirements are refined and updated
throughout the software development lifecycle.
Steps in the Requirements Engineering Process

1. Feasibility Study
✓A feasibility study is conducted to determine whether the proposed
system is technically, economically, and operationally possible.
✓It evaluates if the system can be developed within the constraints
of budget, time, and technology.
✓Its’ purpose is to assess whether the project is worth pursuing.
✓To identify potential risks and alternative solutions.
Steps in the Requirements Engineering Process

Types of Feasibility:
▪ Technical Feasibility: Is the required technology available and
reliable?
▪ Economic Feasibility: Is the project cost-effective and financially
viable?
▪ Operational Feasibility: Will users and stakeholders accept and
use the system?
▪ Output: A feasibility report summarizing findings and
recommending whether or not to proceed with the project.
Introduction Software requirement and specification

Requirements Elicitation and Analysis

▪ This stage involves gathering requirements from stakeholders
(e.g., users, customers, managers) and analyzing them to
understand needs, conflicts and priorities.
▪ Its Purpose is to collect, clarify, and refine all necessary
requirements for the system.
Introduction Software requirement and specification

Requirements Elicitation and Analysis

Techniques for Elicitation:
✓Interviews and questionnaires
✓Observation of user behavior
✓Workshops and brainstorming sessions
✓Use cases and scenarios
✓Prototyping
Introduction Software requirement and specification

Requirements Elicitation and Analysis

Challenges:
✓Miscommunication between users and developers
✓Incomplete or ambiguous requirements
✓Changing stakeholder needs

▪ Outcome: A set of analyzed and prioritized requirements that

form the foundation for specification.
Introduction Software requirement and specification

Requirements Specification
▪ The process of documenting the collected requirements in a clear,
structured, and unambiguous way.
✓The output of this stage is the SRS document.
✓Its’ purpose is to provide a formal reference for developers,
testers, and stakeholders.
✓To describe what the system should do, including functional
and non-functional requirements.
Introduction Software requirement and specification

Requirements Specification
▪ Typical Contents:
✓System objectives and scope
✓Functional and non-functional requirements
✓Constraints and assumptions
✓Interface and performance details

▪ Outcome: A complete and verifiable SRS document that guides

design and implementation.
Introduction Software requirement and specification

Requirements Validation
✓Requirements validation ensures that the documented
requirements accurately reflect stakeholder needs and are
feasible, correct, and testable.
✓Its’ purpose is to identify and correct errors, inconsistencies, or
omissions in the requirements before development begins.
Introduction Software requirement and specification

Requirements Validation

Techniques for Validation:

✓Reviews and inspections (peer review of SRS)
✓Prototyping (demonstrating partial system behavior)
✓Model validation (using diagrams or models)
✓Test-case generation (checking if requirements can be tested)
Introduction Software requirement and specification

Requirements Validation

Common Issues Found:

✓Ambiguous language
✓Incomplete or missing requirements
✓Conflicts between stakeholder goals

• Outcome: A set of validated requirements approved by all key

stakeholders.
Introduction Software requirement and specification

5. Requirements Management
• Requirements management is the process of tracking and
controlling changes to requirements throughout the project’s life
cycle.

• Its’ purpose to ensure requirements remain up-to-date, consistent,

and traceable as the system evolves.
Introduction Software requirement and specification

5. Requirements Management
▪ Key Activities:
✓Version control of requirements
✓Tracking changes and their impact
✓Maintaining traceability links (from requirements → design →
implementation → testing)
✓Managing stakeholder communication about changes
Introduction Software requirement and specification

5. Requirements Management
Tools Commonly Used:
✓JIRA

✓IBM Rational DOORS

✓RequisitePro

• Outcome: A controlled and updated set of requirements that

reflect the current project state.
Introduction Software requirement and specification

Iterative Nature of Requirements Engineering

✓The RE process is not linear — it is iterative and continuous.
✓Why Iterative?
✓Stakeholders may change their needs as they better understand the system.
✓New constraints or technologies may emerge.
✓Early errors or misunderstandings may require rework.
✓Thus, requirements are revisited, refined, and validated throughout the
software lifecycle.
• Example: During design or testing, developers might discover
missing or unclear requirements, leading to updates in the SRS and
further stakeholder discussions.
Introduction Software requirement and specification

Step Purpose Main Output

Determine project
Feasibility Study Feasibility report
viability
Requirements Gather and understand List of analyzed
Elicitation and Analysisstakeholder needs requirements
Requirements Document requirements
SRS document
Specification formally
Ensure requirements are
Requirements Validation Validated requirements
correct and complete
Requirements Handle changes and
Updated requirement set
Management maintain traceability
Introduction Software requirement and specification

Requirements Analysis and Modeling

▪ Identifying conflicts and inconsistencies

▪ Prioritizing requirements

▪ Modeling techniques:
✓Data Flow Diagrams (DFD)
✓Entity-Relationship Diagrams (ERD)
✓Use Case Diagrams
✓State Transition Diagrams
Introduction Software requirement and specification

Example
▪ ATM System or Library Management System
✓Identify user and system requirements
✓Write sample functional and non-functional requirements
✓Create a simple SRS outline
Questions

1. What is a Software Requirements Specification (SRS)?

2. What is the primary purpose of an SRS document?

3. What are the characteristics of a good SRS?

4. What is the Requirements Engineering Process?

5. What are the main activities in the Requirements Engineering Process?

6. What are some common techniques for eliciting requirements?

7. What is the goal of Requirements Analysis and Modeling?

8. What are some common models used in Requirements Analysis?

9. What are some techniques used for Requirements Validation?

Questions
Case Study Scenario: "Connect you" Campus App
❖A university wants to develop a new mobile application called "Connect
you" to improve student engagement and communication on campus. The
primary goal is to provide a single platform for students to access campus
news, view event schedules, and connect with clubs and organizations.
❖The key stakeholders identified are:
✓Students: The primary users of the app.
✓University Administration: Wants to ensure official information is communicated
effectively and that the app reflects the university's brand.
✓Club Leaders: Need a way to manage their club's page, post events, and communicate
with members.
✓IT Department: Will be responsible for maintaining the app and ensuring it integrates
with existing university systems (like the student authentication service).
Questions

Based on the above scenario answer the following questions.

1. Why it is crucial to first invest resources and time into creating a

detailed SRS document for this project? (Answer this questions as
we discussed in the class).

2. Identify and write four distinct functional requirements.

3. Classifying Non-Functional Requirements

4. Identifying and Improving a Poor Requirement