Unit – 4

Software Requirements
Specification
BE Sem – 7 SE – 3173213

Ms. Zarana Gajjar (IT-ICT Department)

 Requirement Engineering

• Tasks and techniques that lead to

an understanding of requirements
is called requirement
engineering.

• Refers to the process of defining, documenting, and

maintaining requirements in the engineering design process.

Ms. Zarana Gajjar (IT-ICT Department)

 Requirement Engineering

• What customer wants

• Analyzing needs
• Assessing feasibility
• Negotiating a reasonable solution
• Specifying solution unambiguously
• Validating the specification
• Managing requirements

Ms. Zarana Gajjar (IT-ICT Department)

 Requirements Analysis and Specification
Many projects fail:
• because they start implementing the
system :
• without determining whether they are
building what the customer really wants.

It is important to learn:
• requirements analysis and specification
techniques thoroughly.

Ms. Zarana Gajjar (IT-ICT Department)

Goals - Requirements Analysis & Specification

• Fully understand the user requirements

• Remove inconsistencies, anomalies, etc.
from requirements
• Document requirements properly in an SRS
document

Ms. Zarana Gajjar (IT-ICT Department)

Ms. Zarana Gajjar (IT-ICT Department)
 Requirements Analysis is hard
“The hardest single part of “The seeds of major
building a software system is software disasters are
deciding what to build. No part usually sown in the
of the work so cripples the first three months of
resulting system if done wrong.” commencing the
software project.”

"Fred" Brooks Jr. is an American computer

architect, software engineer, and computer Capers Jones is an
scientist, best known for managing the American specialist in
development of IBM's System/360 family of software engineering
computers methodologies

Ms. Zarana Gajjar (IT-ICT Department)

 1. Tasks
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Requirement Management

Ms. Zarana Gajjar (IT-ICT Department)

 Inception
• Roughly define scope
• ask a set of questions that establish …

✓ basic understanding of the problem

✓ the people who want a solution
✓ the nature of the solution that is
desired
✓ the effectiveness of preliminary
communication and collaboration
between the customer and the
developer

Ms. Zarana Gajjar (IT-ICT Department)

 Elicitation
• Define requirements
• Collect from …

✓ Users
✓ Customers
✓ Stakeholders

• Issues …

✓ Scope
✓ Understanding
✓ Volatility

Ms. Zarana Gajjar (IT-ICT Department)

 Elaboration

• Further define requirements

• Expand and refine requirements
obtained from inception &
elicitation
• Create an analysis model that
identifies data, function, features,
constraints and behavioral
requirements

Ms. Zarana Gajjar (IT-ICT Department)

 Negotiation
• Reconcile conflicts
• Agree on a deliverable system that
is realistic for developers and
customers
✓ rank requirements by priority
(conflicts arise here …)
✓ identify and analyze risks
associate with each requirement
✓ eliminate, combine and / or
modify requirements to make
project realistic

Ms. Zarana Gajjar (IT-ICT Department)

 Specification
• Create analysis model
• Can be any one (or more) of the
following:
✓ A written document
✓ A set of models
✓ A formal mathematical model
✓ A collection of user scenarios
(use-cases)
✓ A prototype
• SRS is a document that is created
when a detailed description of all
aspects of software to build must
be specified before starting of
project

Ms. Zarana Gajjar (IT-ICT Department)

 Validation
• Ensure quality of requirements
• A review mechanism that looks for:
✓ errors in content or
interpretation
✓ areas where clarification may be
required
✓ missing information
✓ inconsistencies (a major
problem when large products or
systems are engineered)
✓ conflicting or unrealistic
(unachievable) requirements
✓ tests for requirements

Ms. Zarana Gajjar (IT-ICT Department)

 Requirement Management
• Involves managing change :
✓ Feature traceability: how requirements
relate to observable system/product
features
✓ Source traceability: identifies source of
each requirement
✓ Dependency traceability: how
requirements are related to each other
✓ Subsystem traceability: categorizes
requirements by the sub system (s) they
govern
✓ Interface traceability: how
requirements relate to both external
and internal system interfaces

Ms. Zarana Gajjar (IT-ICT Department)

 2. Requirement Elicitation
• Collaborative Elicitation
• Quality Function Deployment
• Usage Scenarios
• Categories of Requirements
• Functional Requirement
• Non-Functional Requirement
• Elicitation Work Products

Ms. Zarana Gajjar (IT-ICT Department)

 Collaborative Elicitation
• One-on-one Q&A sessions rarely
succeed in practice; collaborative
strategies are more practical
• Meetings are conducted & attended
• Rules are established
• Goal is to :

✓ Identify the problem

✓ Propose elements of the solution
✓ Negotiate different approaches
✓ Specify a preliminary set of
solution

Ms. Zarana Gajjar (IT-ICT Department)

 Quality Function Deployment
• This is a technique that translates the needs of the customer
into technical requirements for software
• It emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the
engineering process through functions, information, and tasks
• Goals : maximize customer satisfaction
• identifies three types of requirements

✓ Normal requirements
✓ Expected requirements
✓ Exciting requirements

Ms. Zarana Gajjar (IT-ICT Department)

 Usage Scenarios
• An overall vision of system functions and features
• How they will be used?
• Create a set of scenarios that identify a thread of usage for the
system to be constructed
• Use-case : provide a description of how the system will be used
• Represented by Scenario based diagram

Ms. Zarana Gajjar (IT-ICT Department)

Ms. Zarana Gajjar (IT-ICT Department)
 Categories of Requirements
• Functional requirements

✓ Any requirement which specifies what the system Should do.

✓ Describe a particular behavior of function of the system when
certain conditions are met, for example: “Send email when a new
customer signs up” or “Open a new account”.

• Non-Functional requirements

✓ Any requirement which specifies how the system performs a

certain function.
✓ Describe how a system should behave and what limits there are on
its functionality.

Ms. Zarana Gajjar (IT-ICT Department)

Example - Library Management System
• Functional requirements

✓ Add Book
✓ Update Book
✓ Delete Book
✓ Inquiry Members
✓ Inquiry Issuance
✓ Check out Book
✓ Check In Book
✓ Inquiry waiting for approvals
✓ Reserve Book

• Non-Functional requirements

✓ Safety Requirements
✓ Security Requirements
✓ Software Constraints

Ms. Zarana Gajjar (IT-ICT Department)

 Elicitation Work Products
• Collaborative elicitation should result in
several work products

✓ A bounded statement of scope

✓ A list of stakeholders, users & customers
who participated in elicitation
✓ A description of the technical environment
✓ A list of requirements and constraints
✓ Any prototypes developed to define
requirements
✓ A set of use cases

Ms. Zarana Gajjar (IT-ICT Department)

 3. Requirement Modeling

• Need for model

• Analysis model
• Approaches of Requirement Modeling
• Elements of Model

Ms. Zarana Gajjar (IT-ICT Department)

 Requirement Modeling
Requirements modeling uses a combination of text &
diagrammatic forms to depict requirements in a way
that is relatively easy to understand

System Information
System Function
System Behaviors

Ms. Zarana Gajjar (IT-ICT Department)

 Requirement Modeling

Purpose - Describe what the customer wants built

- Establish the foundation for the software design
- Provide a set of validation requirements

Ms. Zarana Gajjar (IT-ICT Department)

 Need for model Analysis model

• Focus on - what not how • Make sure all points of view

• Follow iterative approach of are covered
development • Every element should add
• It describes… value
✓ What customer needs? • Keep it simple
✓ Basis for software • Maintain a high level of
creation abstraction
✓ Requirement validations • Focus on the problem
after build domain
• Analysis model bridges gap • Minimize system coupling
between system-level & • Model should provides value
software designs to all stakeholders

Ms. Zarana Gajjar (IT-ICT Department)

 Approaches of Requirement Modeling
Structured Analysis Object Oriented Analysis
• Models data elements • Models analysis classes
⁻ Attributes ⁻ Data
⁻ Relationships ⁻ Processes
• Models processes that • Models class
transform data collaborations

• Any one modeling approach is chosen

• Combination of both approach can be applied

Ms. Zarana Gajjar (IT-ICT Department)

 Elements of Requirement Model
Scenario-based Models Class Models
e.g. e.g.
Use cases Class diagrams
User Stories Collaboration diagrams

Software
Requirements

Behavioral Models Flow Models

e.g. e.g.
State diagrams DFDs
Sequence diagrams Data models

Ms. Zarana Gajjar (IT-ICT Department)

 Software Requirement Specification (SRS)
• Software Requirement Specification
• Characteristics of good software
• Template of SRS
• Importance of SRS

Ms. Zarana Gajjar (IT-ICT Department)

 Software Requirement Specification
• Software Requirement Specification (SRS) is a
document that completely describes what the
proposed software should do without describing how
software will do it.
• SRS is also helping the clients to understand their
own needs.
• SRS Contains
o A representation of system behavior
o A complete information description
o A detailed functional description
o An indication of performance requirements and design
constraints
o Appropriate validation criteria
o Other information suitable to requirements
Ms. Zarana Gajjar (IT-ICT Department)
 Characteristics of good software
• Should be accurate, complete, efficient, & of high quality, so
that it doesn’t affect the entire project plan.
• An SRS is said to be of high quality when the developer and
user easily understand the prepared document.
• Characteristics of a Good SRS:
o Correct
o Unambiguous
o Complete
o Ranked for Importance/Stability
o Modifiable
o Traceable
o Verifiable
o Consistent

Ms. Zarana Gajjar (IT-ICT Department)

 Correct
• SRS is correct when all user requirements are stated in
the requirements document.
• Note that there is no specified tool or procedure to assure
the correctness of SRS.

Unambiguous
• SRS is unambiguous when every stated requirement has
only one interpretation.

Complete
• SRS is complete when the requirements clearly define
what the software is required to do.

Ms. Zarana Gajjar (IT-ICT Department)

 Ranked for Importance/Stability
• All requirements are not equally important, hence each
requirement is identified to make differences among
other requirements.
• Stability implies the probability of changes in the
requirement in future.

Modifiable
• The requirements of the user can change, hence
requirements document should be created in such a
manner that those changes can be modified easily.

Traceable
• SRS is traceable when the source of each requirement is
clear and facilitates the reference of each requirement in
future.
Ms. Zarana Gajjar (IT-ICT Department)
 Verifiable
• SRS is verifiable when the specified requirements can be
verified with a cost-effective process to check whether
the final software meets those requirements.

Consistent
• SRS is consistent when the subsets of individual
requirements defined do not conflict with each other.

Ms. Zarana Gajjar (IT-ICT Department)

 Problems Without SRS
• Without developing the SRS document, the system would
not be properly implemented according to customer
needs.
• Software developers would not know whether what they
are developing is what exactly is required by the
customer.
• Without SRS, it will be very difficult for the maintenance
engineers to understand the functionality of the system.
• It will be very difficult for user document writers to
write the users’ manuals properly without understanding
the SRS.

Ms. Zarana Gajjar (IT-ICT Department)

 Standard Template for writing SRS
1. Introduction 3. System Features
1.1 Purpose 3.1 System Feature 1
1.2 Project Scope 3.2 System Feature 2 (and so on)
1.3 Definitions, Acronyms, & 4. External Interface Requirements
Abbreviations 4.1 User Interfaces
1.4 References 4.2 Hardware Interfaces
1.5 Overview 4.3 Software Interfaces
2. Overall Description 4.4 Communications Interfaces
2.1 Product Perspective 5. Other Non-functional Requirements
2.2 Product Functions 5.1 Security
2.3 User Classes & Characteristics 5.2 Reliability
2.4 Operating Environment 5.3 Availability
2.5 Design and Implementation 5.4 Maintainability
Constraints 5.5 Reusability
2.6 User Documentation 6. Other Requirements
2.7 Assumptions and Dependencies

Appendix A: Glossary | Appendix B: Analysis Models | Appendix C: Issues List

Ms. Zarana Gajjar (IT-ICT Department)
 Importance of SRS
• System can’t be implemented as per customer’s needs.
• Developers : Is developed product is as per customer
requirement?
• Maintenance Engineer : can’t maintain & understand
software
• Documentation : User manuals can’t be created properly

Ms. Zarana Gajjar (IT-ICT Department)

 Formal Specification
• A formal software specification is a statement expressed
in a language whose vocabulary, syntax and semantics
are formally defined.
• Need for a formal semantic definition means that the
specification languages cannot be based on natural
language; it must be based on mathematics.
• It is mathematical method used to specify a hardware or
software system requirements.
• Goal – Describe external behavior without describing or
constraining implementation.

Ms. Zarana Gajjar (IT-ICT Department)

 Advantages of Formal Specification

• Provides insights and understanding of the software

requirements and the software design.
• It may be possible to prove that a program conforms to
its specifications.
• Formal specification may be automatically processed.
Software tools can be built to assist with their
development, understanding, and debugging.
• Formal specifications are mathematical entities and may
be studied and analyzed using mathematical methods.
• Formal specifications may be used as a guide to the
tester of a component in identifying appropriate test
cases.

Ms. Zarana Gajjar (IT-ICT Department)

 Disadvantages of Formal Specification
• All the requirements can not be specified by formal
specification.
• Use of mathematical sound to represent requirements.
• Difficult to learn & use.
• Can not specify very complex problem.

Ms. Zarana Gajjar (IT-ICT Department)

 Types of Formal Specification
• Property Oriented : State desired properties in a purely
declarative way.
• Axiomatic
• Algebraic
• Model Oriented : Provide direct way of describing system
behavior.

Ms. Zarana Gajjar (IT-ICT Department)

 Axiomatic Specifications
• Use a set of stateless functions; each function has a set
of pre- and post-conditions.
• Pre- and post-conditions are predicates over the inputs
and outputs of a function.
• A predicate is a Boolean expression which is true or false
and whose variables are the parameters of the function
being specified.
• Pre-Condition : Must satisfied before operation invoked.
• Post-Condition : Must satisfied after operation invoked.

Ms. Zarana Gajjar (IT-ICT Department)

 Stages of axiomatic specification of a function

• Establish the range of the input parameters over which

the function is intended to behave correctly. Specify the
input parameter
• Specify a predicate defining a condition which must hold
on the output of the function if it behaves correctly.
• Establish what changes (if any) are made to the
function's input/output parameters.
• Combine these into pre- and post-conditions for the
function.

Ms. Zarana Gajjar (IT-ICT Department)

 Example
• Consider a search function that accepts an array of
integers and some integer key of its parameters. The
array members are sorted in increasing order. The
function returns the array index of the member of the
array whose value is equal to that of the key. The
original input is unchanged. If the key is not matched,
return an array index that is one number larger than the
array's maximum index.

Ms. Zarana Gajjar (IT-ICT Department)

 Example cont.
• A specification is:
function Search (X: INTEGER-ARRAY; Key: INTEGER)
return INTEGER;
• Pre: exists i in X'FIRST...X'LAST:
X(i)=Key and for-all i,j in X'FIRST...X'LAST:
i<j implies X(i)<=X(j)
• Post: X''(Search (X, Key))=Key and X=X''
• Error: Search (X, Key)=X'LAST + 1

• X'' refers to the value of the array X after the function

has been evaluated.

Ms. Zarana Gajjar (IT-ICT Department)

 Algebraic Specifications
• In the Algebraic Specification technique, an object class
or type is specified in terms of relationships existing
between the operations defined on that type.
• Use Heterogeneous algebra
• It contain 4 parts
• Type Section – Type (Datatypes) used by specification.
• Exception Section – Exception conditions occurs
during operation.
• Syntax Section – Procedure signature (Operation
name, argument, return type).
• Equations Section – Rules for equations.

Ms. Zarana Gajjar (IT-ICT Department)

 Example
• Point – datatype Create, xcord, ycord, isequal
• Types – Define point. Uses Boolean, integer
• Syntax – create : integer * integer -> point
xcord : point -> integer
ycord : point -> integer
isequal : point * point -> Boolean
• Equations – xcord (create(x,y)) = x
ycord (create(x,y)) = y
Isequal(create(x1,y1), create(x2,y2)) = ((x1=x2) and
(y1=y2))

Ms. Zarana Gajjar (IT-ICT Department)

Ms. Zarana Gajjar (IT-ICT Department)