Software Requirements

Specification Document
Week 13
By
Dr. Muhammad Ali Memon
1
Systems Requirements Specification

Table of Contents
I. Introduction
II. General Description
III. Functional Requirements
IV. Non Functional Requirements
V. System Architecture
VI. System Models
VII. Appendices

2
Systems Requirements Specification

I. Introduction
A Purpose
B Scope
C Definition, Acronyms, or Abbreviations
D References
E Overview

3
Systems Requirements Specification

II. General Description

A Product Perspective
B Product Functions
C User Characteristics
D General Constraints
E Assumptions

4
Systems Requirements Specification
Correct Complete
Precise Organized
Unambiguous Verifiable
Consistent Understandable
Modifiable Traceable
Design Independent Annotated
Concise

5
Systems Requirements Specification
Correct -
specifies every true requirement known at that time and no incorrect specifications - no wrong data

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 - English interpretation

Complete -
everything included behavior (methods, use cases, systems, subsystems, business rules) and data
(objects, attributes

6
Systems Requirements Specification

Verifiable
is the software built what was specified in the SRS

Consistent
conflicting terms, characteristics

Understandable
question: are formal specifications understandable, are informal
specifications understandable

7
Systems Requirements Specification

Modifiable
changing requirements easily modified when specifying, designing, coding, implementing

Traceable
can I locate the SRS origin of software components.

Design Independent
SRS should not specify a particular design

8
Systems Requirements Specification
• Section One
– Overview document for executives describing the system from a
management perspective
• Section Two
– General Description describing the system from a user and system
perspective in general terms.
• Section Three
– Detailed document for users and developers describing the system
in detailed terms.

9
Systems Requirements Specification
SRS - Section I - Introduction

Definition of section contents

In the next slides, the deliverable is defined

using blue and black font. Then an small
example of the needed deliverable is
documented with a gray background
10
Systems Requirements Specification

I. Introduction

A Purpose
B Scope
C Definition, Acronyms, or Abbreviations
D References
E Overview 11
Systems Requirements Specification
I. Introduction
A Purpose
The purpose of this Software
Requirements Specification document

Intended audience of this document

12
Systems Requirements Specification
I. Introduction
A Purpose
The purpose of the Software Requirements
Specification document is to clearly define the system
under development, namely the Video Rental System
(VRS). The intended audience of this document
includes the owner of the video store, the clerks of the
video store, and the end users of the VRS. Other
intended audience includes the development team such
as the requirements team, requirements analyst, design
team, and other members of the developing
13
organization.
Systems Requirements Specification
I. Introduction
B. Scope

Origin of need
High-level description of the system
functionality
Goals of proposed system

14
Systems Requirements Specification

I. Introduction
B. Scope

Origin of the need

• who and what triggered the request for
this software development activity
• gives developers an understanding of
the goals for the proposed system

15
Systems Requirements Specification

I. Introduction
B. Scope

High-level functionality
• defined for the system
• usually in list separated by commas

16
Systems Requirements Specification
I. Introduction
B. Scope

Goals are general purposes of a system.

They are fuzzy and non measurable.

A typical goal would be things like

•Increase customer satisfaction
•Make xyz easier for the customer
•Improve customer relationships

17
Systems Requirements Specification
I. Introduction
B. Scope
The owner of a local video store wanted to create a new business plan
where everything about renting a video (except the picking up and
returning of videos) was done online. Therefore, the new VRS will
allow the following functionality online: to search for videos, to
become members, to rent videos, to modify membership information,
and to pay overdue fees. The store personnel may use the VRS to
process the rented or returned videos, to add or remove videos to/from
his store’s video inventory and to update video information. The VRS
is intended to increase the owner’s profit margin by increasing video
sales with this unique business approach and by allowing him to reduce
the staffing needed in his stores.

18
Systems Requirements Specification
I. Introduction
C. Definitions, Acronyms..

As you begin to define a system, you will

encounter words which need definition and
general usage acronyms. These should be
documented for new personnel and for clarity of
all concerned parties.

19
Systems Requirements Specification
I. Introduction C Definitions, Acronyms..

FSU – Florida State University

CS - Computer Science
MSES - Masters in Software Engineering Science
DOE - Department of Education
….

20
Systems Requirements Specification
I. Introduction
D. References

Many references may be used to define existing

systems, procedures (both new and old),
documents and their requirements, or previous
system endeavors. These references are listed
here for others.

If any of these references are provided in the

21
appendices, it should be noted here.
Systems Requirements Specification
I. Introduction D References

Clerk - Personnel staff who is working in a video

store
Customer - Anyone who interacts with the VRS
with becoming a member
Functional requirement - A service provided by the
software system
Member - Anyone who registers with the VRS to
acquire membership in the video store 22
Systems Requirements Specification
I. Introduction
E. Overview

This section defines the organization of the entire

document. It will lay the framework for reading
the document.

23
Systems Requirements Specification
I. Introduction E Overview

Section 2 of the SRS describes the product in

more detail. Section 3 provides a complete list
of the functional requirements of the
intended system. Section 4 provides the non-
functional requirements. Section 5 shows the
class diagram, and Section 6 the use case
diagram. The appendices appear next.
24
 Section I of SRS
I.A Purpose Paragraph form

I.B Scope of the System Paragraph form

Specified
I.C Definitions, Acronyms, and Table form or
Abbreviations bulleted list
I.D References to Supporting Bulleted list
Documents
I.E Overview of rest of SRS Paragraph form

25
Systems Requirements Specification

II. General Description

A Product Perspective
B Product Functions
C User Characteristics
D General Constraints
E Assumptions 26
Systems Requirements Specification
II General Description
A Product Perspective

This defines the relationship this product has in the

entire spectrum of products.
It defines who will be responsible for the product
and what business purpose it serves.
It also defines what interfaces it may have to other
systems.

27
Systems Requirements Specification
II General Description
A Product Perspective
The VRS is a web-based system. The system interfaces
with two other systems, the owner’s email system, the
video distributor’s video system, and the browsers used
by VRS customers. The system provides a secure
environment for all financial transactions and for the
storing and retrieving of confidential member
information.
28
Systems Requirements Specification
II. General Description B Product Functions

This section lists the major functions of the system.

It provides a summary of all the functions of the software. The
functions should be organized in a way that makes the list of
functions understandable to the customer or to anyone else
reading the document for the first time.
This section should be consistent with the functional
requirements defined in Section III.

29
Systems Requirements Specification
II. General Description – B Product Functions
The VRS allows customers to search the video inventory
provided by this video store. To rent videos through the VRS, one must
register as a member using the VRS. Upon becoming a member and
logging into the VRS, the VRS provides the functionality for renting
videos, modifying membership information, and paying overdue fines.
The clerks of the video store use VRS to process the return of
rented videos. The owner of the video store uses VRS to add new videos
into the system, remove videos from the system, and modify video
information.
The VRS sends emails to members concerning video rentals.
One day before a rented video is due to be returned, VRS emails the
member a reminder of the due date for the video(s). For any overdue
videos, VRS emails the member every 3rd day with overdue notices. At
the 60-day limit for outstanding videos, VRS debits the member’s credit
card with the appropriate charge and notifies the member of this 30
charge.
Systems Requirements Specification

II. General Description – C User Characteristics

List the users involved with the proposed system

including the general characteristics of eventual users
(for example, educational background, amount of
product training).
List the responsibility of each type of user involved, if
needed.

31
Systems Requirements Specification
II. General Description – C User Characteristics
The three main groups of VRS users are customers,
members, and store personnel. A customer is anyone who is not a
member. The customer can only search through the video inventory.
The amount of product training needed for a customer is none since
the level of technical expertise and educational background is
unknown. The only skill needed by a customer is the ability to browse
a website.
Member is someone who has registered with VRS. A member
can rent videos and pay fees online. As with a customer, these
activities require no product training since the level of technical
expertise and educational background of a member is unknown. The
only skill needed by a member is the ability to browse a website.
The store personnel are divided into two groups: the clerk-
level personnel and owner-level personnel. Their educational level is32
unknown and both group needs little to no training.
Systems Requirements Specification

II. General Description – D General Constraints

D General Constraints
In this section, the constraints of the system are
listed. They include hardware, network, system
software, and software constraints. It also includes
user constraints, processing constraints, timing
constraints, and control limits.

33
Systems Requirements Specification
II. General Description – D General Constraints

This system provides web access for all customer

and member functions. The user interface will be
intuitive enough so that no training is required by
customers, members, or store personnel. All
online financial transactions and the storage of
confidential member information will be done in
a secure environment. Persistent storage for
membership, rental, and video inventory
information will be maintained. 34
Systems Requirements Specification
II General Description – D Assumptions and
Dependencies
This includes assumptions made at the beginning of the
development effort as well as those made during the
development.
List and describe each of the factors that affect the
requirements stated in the SRS. These factors are not design
constraints on the software but any changes to them can
affect the requirements in the SRS. For example, an
assumption might be that a specific operating system will be
available on the hardware designated for the software
product. If, in fact, the operating system is not available, the
35
 Section II of SRS
II.A Product Perspective Paragraph form

II.B Product Functions Paragraph form

II.C User Characteristics Paragraph form

II.D General Constraints Paragraph form

II.E Assumptions and Paragraph form

Dependencies
36
Systems Requirements Specification
III Functional Requirements

Functional requirements are those business functions which

are included in this software under development. It
describes the features of the product and the needed
behavior.
The functional requirements are going to be written in
narrative form identified with numbers. Each requirement
is something that the system SHALL do. Thus, it has a
common name of a shall list. You may provide a brief design
rationale for any requirement which you feel requires
explanation for how and/or why the requirement was
derived. 37
Systems Requirements Specification
IV Non Functional Requirements

Non functional requirements are properties that the system

must have such as performance, reusability, usability, user
friendliness, etc.

The same format as the functional requirements is to be

used for the non-functional requirements. You may provide
a brief design rationale for any requirement which you feel
requires explanation for how and/or why the requirement
was derived.

38
39
Systems Requirements Specification
V System Architecture

This section presents a high-level overview of the

anticipated system architecture using a class
diagram. It shows the fundamental objects/classes
that must be modeled with the system to satisfy its
requirements. Each class on the diagram must
include the attributes related to the class. All the
relationships between classes and their multiplicity
must be shown on the class diagram. The classes
specified in this document only are those directly
derived from the application domain. 40
Architecture Samples

41
The organization of the Model-
View-Controller

42
The architecture of the iLearn
system

43
A repository architecture for an
IDE

44
A client–server architecture for a
film library

45
An example of the pipe and filter
architecture used in a payments
system

46
Architecture patterns

1. Blackboard system 9. Entity–component–system

2. Broker pattern 10. Entity-control-boundary
3. Event-driven architecture 11. Multitier architecture (often
4. Implicit invocation three-tier or n-tier)
5. Layers 12. Naked objects
6. Hexagonal architecture 13. Operational data store (ODS)
7. Microservices 14. Peer-to-peer
8. Action-domain-responder 15. Pipe and filter architecture
, Model–view– 16. Service-oriented architecture
controller, Presentation- 17. Space-based architecture
abstraction-control, Model-view-
18. Distributed hash table
presenter, and Model-view-
viewmodel

47
Systems Requirements Specification
VI System Models

This section presents the use case diagram for the

system under development. The use case diagram
should be a complete version containing all the use
cases needed to describe the functionality to be
developed.

48
Systems Requirements Specification
VII Appendixes
Appendix A. Data dictionary

Appendix B. Raw use case point analysis

Appendix C. Screens and reports with navigation matrix.

Appendix D. Scenario analysis tables

Appendix E. Screens/reports list

Appendix F and following. Other items needed

49