Chapter – 3

INTRODUCTION TO SOFTWARE
REQUIREMENTS SPECIFICATION
REQUIREMENT ENGINEERING
 A requirement : is a feature of the system or a
description of something the system is capable of
doing in order to fulfill the system’s purpose
 Requirements engineering produces one large
document, written in a natural language, and contains
a description of what the system will do without
describing how it will do it.
The Process of Determining Requirements
Types of Requirements
 Based on their priority:
 Requirements should be absolutely met.
 Requirements are highly desirable but not necessary.
 Requirements are possible but could be eliminated.
Types of Requirements
 Based on their functionality:
 Functional requirements: can defined as a factors, such
as I/O formats, storage structure, computational
capabilities, timing, and synchronization.
 Non-functional requirements: can define as a properties
or qualities of a product including usability, efficiency,
performance, space, reliability, portability, etc.
 Chapter – 3

3.2 PROCESS OF REQUIREMENTS ENGINEERING

PROCESS OF REQUIREMENTS ENGINEERING
 Requirements engineering consists of:
1. Requirements elicitation.
2. Requirements analysis and modeling.
3. Requirements documentation.
4. Requirements review.
5. Requirements management.
1. Requirement Elicitation
 Meetings, interviews, video conferencing, e-mails, and
existing documents study and facts findings.
 More than 95% elicitation should be complete in this stage
while the remaining 5% is completed during the
development life-cycle.
 The sources are:
 Customer (Initiator)
 Primary Users, Secondary Users, and End Users
 Stakeholders
2. Requirement Analysis (1/2)
 The process activities are:
 Domain Understanding: For example, if a system for a
supermarket is required, the analyst must find out how
supermarkets operate.
 Requirements Collection: interacting with stakeholders to
discover their requirements.
 Classification: organizes requirements into coherent clusters.
 Conflict Resolution: When stakeholders are involved,
requirements may conflict.
2. Requirement Analysis (2/2)
 The process activities are:
 Prioritization: This stage involves interaction with stakeholders to
discover the most important requirements.
 Requirements Checking: The requirements are checked to
discover if they are complete, consistent, and in accordance with
what stakeholders really want from the system.
3. Requirements Documentation (1/2)
 First, outline the general purpose of the system. References
to other related systems are included,
 Next, describe the background and objectives of system
development.
 For example, if a system is to replace an existing approach, we
explain why the existing system is unsatisfactory.
 If the customer has a proposed new approach to solving
the problem, outline a description of the approach
3. Requirements Documentation (1/2)
 Once we record this overview of the problem, we describe the
detailed characteristics of the proposed system. We define the
system boundaries and interfaces across it. The system functions
are also explained. Also, we include a complete list of data
elements and classes and their characteristics.
 Finally, we discuss the environment in which the system will
operate. We include requirements for support, security, and
privacy and any special hardware or software constraints should
be addressed.
4. Requirements Review
 Informal Review. involve contractors with stakeholders.
 conformation that the documented requirements are what the
stakeholders really said they wanted.
 Formal Review
 Verifiability: requirements are testable
 Comprehensibility: understood by the end-users.
 Traceability: is the origin of requirements clearly stated?
 Adaptability: can the requirement be changed without
large-scale effects on other system requirements.
5. Requirements Management Planning
 During the requirements management stage, you must
decide on:
 Identification: Each requirement must be uniquely identified.
 A change management process. This is the set of activities that
assess the impact and cost of changes.
 Traceability policies: define the relationships between
requirements and the system design.
 CASE tool: involves the processing of large amounts of Tools,
which may be used, such as spreadsheets, editors, designers,
modelers and many other tools.
 Chapter – 3

Preparing SRS
Software Requirements Specification
 Chapter – 3

Preparing SRS
Software Requirements Specification
Software Requirements Specification (SRS)
 What is an SRS?
 What is the purpose of an SRS?
 Who reads the SRS?
 Who writes the SRS?
 What information is put into an SRS?

 What do you need to do for phase 1?

What is an SRS?
 It is a document that you prepare:
 after customer gives you their system specifications.
 before you design the system.
Purpose
1. It provides feedback to the customer.
2. It decomposes the problem into component parts.
3. It serves as an input to the design specification.
4. It serves as a product validation check.
Who reads the SRS?
 The purpose of an SRS is to communicate with:
 The customer:
The SRS must make clear to the customer whether you have
understood their system specification correctly and completely.
SRS is written in plain language (not a formal language).
 The designers:
The SRS must be detailed enough that the designers can
construct a design for the system from this document.
Who writes the SRS?
 Developers
 Architects
 Programmers
 Technical writers.
 For examples MIS guys.
 Customer may be involved.
Basis for User Manual
 The SRS can serve as the basis for a User Manual for
the software:
 Use case descriptions in SRS describe required
functionality of the system, from the perspective of a
user.
 This can be extended to become a description of how to
carry out these required tasks with the finished system.
What information is put into an SRS?
 Varies between
 Organizations
 Customers
 Projects
IEEE Std 830-1998
Characteristics of a good SRS
1. Correct 6. Modifiable
2. Unambiguous 7. Traceable
3. Complete
4. Consistent
5. Ranked for importance
and/or stability
6. Verifiable
Characteristics of a good SRS
 Correct: every requirement given in SRS is a
requirement of the software
 Unambiguous: every requirement has exactly one
interpretation.
 Complete: includes all functional, performance,
design, external interface requirements; definition of
the response of the software to all inputs (valid and
invalid)
Characteristics of a good SRS
 Consistent: internal consistency.
 Ranked importance: essential vs. desirable.
 Verifiable: for each requirement there must be a
“finite cost-effective” method to verify process with
which a person or machine can check that the
software product meets the requirement.”
Characteristics of a good SRS
 Modifiable: SRS must be structured to permit
effective modifications (e.g. don’t be redundant,
keep requirements separate)
 Traceable: origin of each requirement is clear.
IEEE Std 830-1998: Parts of an SRS
 Introduction
 Purpose.
Determine the purpose of SRS.
Who is the intended audience for SRS.
 Scope.
identify software to be produced by name.
describe application of SW benefits and objectives
IEEE Std 830-1998: Parts of an SRS
Content:
 Introduction
 Overall description
 Specific requirements
 Supporting Information
IEEE Std 830-1998: Parts of an SRS
 Introduction (continued)
 Definitions/acronyms/abbreviations.
 Overview
brief description of rest of SRS.
organization of SRS.
IEEE Std 830-1998: Parts of an SRS
 Overall description
 Product perspective (related products?)
Block diagram
Constraints
System interfaces
• identify functionality that fulfills each system requirement.
User interfaces
Hardware interfaces
IEEE Std 830-1998: Parts of an SRS
 Overall description (continued)
 Product functions
summary of major functions sw will perform.
 Intended user characteristics
educational level.
Experience.
technical expertise.
IEEE Std 830-1998: Parts of an SRS
 Overall description (continued)
 Constraints (limitations of developer options)
regulatory policies
hardware limitations (e.g. signal timing requirements)
interfaces to other applications
parallel operation
control functions
higher-order language requirements
reliability requirements
criticality of the application
safety and security considerations
IEEE Std 830-1998: Parts of an SRS
 Overall description (continued)
 Assumptions and dependencies.
e.g. specific OS available.
Requirements that may be delayed to future versions.
IEEE Std 830-1998: Parts of an SRS
 Specific requirements
 External interfaces.
 Functions.
 Performance requirements.
 Logical database requirements.
 Design constraints.
Standards compliance
IEEE Std 830-1998: Parts of an SRS
 Specific requirements (continued)
 Software system attributes
Reliability
Availability
Security
Maintainability
Portability
IEEE Std 830-1998: Parts of an SRS
 Specific requirements (continued)
 Organizing the specific requirements
System mode
User class
Objects
Feature
Response
Functional hierarchy
 Additional comments
IEEE Std 830-1998: Parts of an SRS
 Supporting Information
 Table of contents
 Index
 Appendixes