1

Software Engineering

Semester- Fall 2019

 Software Requirements Specification
SRS Document

A software requirements specification (SRS) is a document that describes what the software will do
and how it will be expected to perform.

An SRS describes the functionality the product needs to fulfill all stakeholders (business, users)
needs.
A typical SRS includes:
•A purpose
•An overall description
•Specific requirements
 Why Use an SRS Document?

• It is the basis for your entire project. It lays the framework that every team involved in
development will follow.
• It’s used to provide critical information to multiple teams — development, quality assurance,
operations, and maintenance. This keeps everyone on the same page.
• Using the SRS helps to ensure requirements are fulfilled. And it can also help you make decisions
about your product’s lifecycle — for instance, when to retire a feature.
• Writing an SRS can also minimize overall development time and costs. Embedded development
teams especially benefit from using an SRS
How to Write an SRS
Document
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Scope
1.5 Definitions and Acronyms
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Nonfunctional Requirements
 1. Introduction

Purpose
 The introduction to your SRS is very important. It sets the expectation for the product you’re building.
Intended Audience and Intended Use
 Define who in your organization will have access to the SRS — and how they should use it. This may
include developers, testers, and project managers. It could also include stakeholders in other departments,
including leadership teams, sales, and marketing.
Product Scope
 Describe the software being specified. And include benefits, objectives, and goals. This should relate to
overall business goals, especially if teams outside of development will have access to the SRS.
Definitions and Acronyms
 Definition of terms and abbreviations used in your project
 2. Give an Overview of What
You’ll Build (Overall description)
User Needs
• You’ll need to define who is going to use the product and how.
• You may also need to define the needs of a separate buyer of the product (who may not be a
primary/secondary user). And, for example, if you’re building a medical device, you’ll need to describe the
patient’s needs.
Assumptions and Dependencies
• There might be factors that impact your ability to fulfill the requirements outlined in your SRS. What are
those factors?
• Are there any assumptions you’re making with the SRS that could turn out to be false? You should include
those here, as well.
• Finally, you should note if your project is dependent on any external factors. This might include software
components you’re reusing from another project.
 3. Detail Your Specific Requirements

Functional Requirements
• Functional requirements are essential to building your product. Typically, functional requirements will
specify a behaviour or function.

External Interface Requirements

• Provide a detailed description of all inputs into and outputs from the software. External interface
requirements are types of functional requirements. They’re important for embedded systems. And they
outline how your product will interface with other components. There are several types of interfaces
you may have requirements for, including:
• User
• Hardware
• Software
• Communications
 3. Detail Your Specific Requirements

System Features
• These are features that are required in order for a system to function.

Nonfunctional Requirements
• Nonfunctional requirements can be just as important as functional ones. These include:
• Performance
• Safety
• Security
• Quality
Functional VS Non-Functional
Requirements
 Characteristics of a good SRS

Correct
Systems Approach
• Specifies every true requirement known at that time and no incorrect specifications - no
wrong data The Element of a System
(continued)
Precise
• Remember this must eventually turn to executable code, fuzzy words in requirements are
not acceptable - fuzzy words
Unambiguous
• Each requirement has only one interpretation
Complete
• Everything included behavior (methods, use cases, systems, subsystems, business rules)
and data (objects, attributes )
 Characteristics of a good SRS

Verifiable
Systems
• Is the software built Approach
what was specified in the SRS
Consistent The Element of a System
• Conflicting terms, characteristics
Understandable (continued )
• Question: are formal specifications understandable, are informal specifications
understandable
Modifiable
• Changing requirements easily modified when specifying, designing, coding, implementing
Design Independent
• SRS should not specify a particular design
Q &A