Chapter 3 – SRS

Requirements analysis
Requirements specification
SRS document
Decision table
Decision tree
 Introduction
Many projects fail –


 Because they start

implementing the system
without determining
whether they are building
what the customer really
wants
t to learn requirements analysis and specification t
Goal of Requirement Analysis
and Specification
◦ Fully understand the user
requirements.
◦ Remove inconsistencies,
anomalies, etc. from
requirements.
◦ Document requirements
properly in an SRS document
Requirement gathering and Specificati
Analysis on
Requirement gathering
Also known as requirement
elicitation
Analyst gathers requirements
through:
◦ Observation of existing systems,
◦ Studying existing procedures,
◦ Discussion with the customer
and end-users,
◦ Analysis of what needs to be
done, etc.

Contd..
If the project is to automate some
existing procedures
◦ e.g., automating existing manual
accounting activities,
◦ The task of the system analyst is a
little easier
◦ Analyst can immediately obtain:
 input and output formats
accurate details of the operational
procedures

Requirement Gathering
Activities
1. Studying the existing
documentation
2. Interview
3. Task analysis
4. Scenario analysis
5. Form analysis

Contd..
In the absence of a working
system,
◦ Lot of imagination and creativity
are required.
Interacting with the customer to
gather relevant data:
◦ Requires a lot of experience.
Some desirable attributes of a good
system analyst:
◦ Good interaction skills,
◦ Imagination and creativity,
Analysis of gathered
requirement
Main purpose of requirements
analysis:
 Clearly understand the user
requirements,
Detect inconsistencies,
ambiguities, and
incompleteness.
Incompleteness and
inconsistencies:
◦ Resolved through further
discussions with the end-users
Ambiguous Requirement
Words like good, bad, high low are
ambiguous.


 Eg. If the numbers of users logged

into the system are very high the
system should show a warning
message
Inconsistent requirement
Two requirements contradicting
each other cause inconsistency

E.g – If a student does not pass a
minimum of two subjects out of
the total five he will have to
repeat the entire semester
The system does not allow any
student to repeat a semester
Incomplete requirement
Caused by the inability of the
customer to visualize a system and
anticipate all the features

E.g – If a students fails in three
subject, then the parent of the
student will be informed of the
same through email and postal
letter.

In the system there is no provision
Software Requirement
Specification
Main aim of requirements
specification:
systematically organize the requirements
arrived during requirements analysis
document requirements properly.

The SRS document is useful in

various contexts:
◦ Statement of user needs
◦ Contract document
◦ Reference document
◦ Definition for implementation

Who uses the SRS?
One of the toughest document to
write as it caters to a wide
audience
◦ Users, customers and marketing
personnel
◦ Software developers
◦ Test Engineers
◦ User documentation writers
◦ Project Managers
◦ Maintenance engineers
SRS as a black box
specification
The SRS document is known as
black-box specification:
◦ The system is considered as a
black box whose internal details
are not known.
◦ Only its visible external (i.e.
input/output) behaviour is
documented.
Output Data
 Input Data S
Contd..
SRS document concentrates on:
◦ What needs to be done
◦ Carefully avoids the solution (“how
to do”) aspects.
The SRS document serves as a
contract
◦ Between development team and
the customer.
◦ Should be carefully written

Good SRS Document
It should be concise without
ambiguity
It should specify what the system
must do and not how to do it.
Easy to change i.e. it should be well-
structured.
It should be consistent.
It should be complete.
It should be traceable
It should be verifiable
◦ e.g. “system should be user
Bad SRS document
Over – specification
◦ How to aspects are addressed
Forward references
◦ Reference to aspects that are
discussed later in SRS
Wishful thinking
◦ Description of aspects which would
be difficult to implement
Noise
◦ Presence of non relevant material
SRS document
AnSRS document contains the
following:


◦ Functional Requirements
◦ Non – functional requirements
◦ Goals of Implementation
SRS – Functional
Requirements
It is desirable to consider every
system:
◦ Performing a set of functions {fi}.
◦ Each function fi considered as:
Transforming a set of input data to
corresponding output data.


Input Data Output Data

fi
Contd..
F1:Search Book


◦ Input:
an author’s name:
◦ Output:
details of the author’s books and
the locations of these books in the
library.

Author Name Book Details
F1
Contd..
Functional requirements describe:
◦ A set of high-level requirements
◦ Each high-level requirement:
 takes in some data from the user
outputs some data to the user
◦ Each high-level requirement:
might consist of a set of identifiable
functions
For each high-level requirement:
◦ Every function is described in terms
of:
Input data set
Output data set
Contd..
A high-level function is one:
◦ Using which the user can get some
useful piece of work done.


Can the receipt printing work

during withdrawal of money
from an ATM be called a useful
piece of work?
SRS – High Level Functions
A high-level function:
◦ Usually involves a series of
interactions between the
system and one or more users.
Even for the same high-level
function,
◦ There can be different interaction
sequences (or scenarios)
◦ Due to users selecting different
options or entering different
data items.
SRS – Nonfunctional
requirement
Characteristicsof the system
which can not be expressed as
functions


◦ Reliability issues
◦ Performance issues
◦ Human-computer interface issues,
◦ Interface with other external
systems,
◦ Security, maintainability, etc.

SRS - Goals of
Implementation
Goals describe things that are
desirable of the system:
◦ But, would not be checked for
compliance or is one of the
acceptance criteria.
◦ For example,
 Reusability issues
Functionalities to be developed
in future

Example: Functional
Requirement
Requirement 1
◦ In a Library Management System, one
of the functionality of the application
is to allow the users to search for a
book specific to a particular author,
or the book name. Depending upon
the search, the system should output
the title, author name, publisher
name, year of publication and the
catalog number of all the books
which matches the search criteria.
The system should also display the
location of the book in the library
Requirement 1 in SRS
R.1.1: Query Book
◦ Input: “search” option,
◦ Output: user prompted to enter the key
words.
R1.2: Display book details
◦ Input: key words
◦ Output: Details of all books whose title
or author name matches any of the key
words.
 Details include: Title, Author Name,
Publisher name, Year of Publication,
Catalog Number, Location in the Library.
◦ Description: Search the book list for the
keywords entered by the user
Example: Functional
Requirement
Requirement 2
◦ A valid member of the Library
Management System can also
renew the books borrowed by him.
In order to do this the user needs
to select the ‘renew’ option. On
successful verification of the
membership number and
password, he can see the list of all
the books borrowed under him. By
selecting any number of renew
boxes the user can renew one or
Requirement 2 in SRS
R2.1: Renew Book
◦ Input: “renew” option selected,
◦ Output: user prompted to enter his
membership number and password.


R2.2: Validate User

◦ Input: membership number and password
◦ Output:
list of the books borrowed by user are
displayed. User prompted to enter books
to be renewed or
user informed about bad password
/membership no.
◦ Processing: Password validation, search
books issued to the user from borrower
list and display.

Contd..
R2.3: Renewal Confirmation


◦ Input: user choice for renewal of the

books issued to him through mouse
clicks in the corresponding renew box.
◦ Output: Confirmation of the books
renewed
◦ Processing: Renew the books selected by
the in the borrower list.

Decision Tree
Complex processing logic can be
represented using a decision tree
Decision trees:
◦ Edges of a decision tree represent
conditions
◦ Leaf nodes represent actions to be
performed.
A decision tree gives a graphic view
of:
◦ Logic involved in decision making
◦ Corresponding actions taken.
Example : Case Study
A Library Membership
automation Software (LMS)
should support the following
three options:
◦ New member,
◦ Renewal,
◦ Cancel membership.

 N ew Renew a C a n ce lla tio
M em ber l n
e d , thIfethsoe ftw
re naerew a lsks
o p ti
d oenta
Ifiith
slsch
ea ca
boosenuce
nt ,th
l me em me bm ebrsh
e r:ipn ao mp ti
eo, na disd se
re ss
le cte
, p hdo anne dn th
u me bnearm,
LM S a sks th e m e m bTehr'es mn aemm eb earsh n d ihpisismca e mn ce
b ellrsh
e d ,ip n u m b e r
ch e cks w h e th e r h e Aisch a eva
q ulide mfo er mthbeebr.a la n ce a m o u n t d u e to th e m e m b e r is
If th e n a m e re p re se nT ts h e am vae mlidb emrshe mipb erer,co rd is d e le te d .
th e m e m b e rsh ip exp iry d a te is u p d a te d a n d th e a n n u a lm e m b e rsh ip b illis p
o th e rw ise a n e rro r m e ssa g e is d isp la ye d .

is e n te re d ,
d fo r th e m e m b e r is cre a te d
e a n n u a lm e m b e rsh ip ch a rg e p lu s th e se cu rity d e p o sit p a ya b le .
Representation using a decision
tree
Get
Details
Create
Records

Actions to be performed
Print

em ber Receipt

w M
Ne Get
Details
al Update
Renew Records
Print
U se r Canc
Receipt

In p u t e l
Get
Details
Inv Print
Opt ali Cheque
ion d Delete
Record

Print Error
Message

conditions
Decision Tables
Decision tables specify:
◦ Which variables are to be tested
◦ What actions are to be taken if the
conditions are true,
◦ The order in which decision making is
performed.
A decision table shows in a
tabular form:
◦ Processing logic and corresponding
actions

Contd..
Upper rows of the table specify:
◦ The variables or conditions to be
evaluated
Lower rows specify:
◦ The actions to be taken when the
corresponding conditions are
satisfied.
In technical terminology,
◦ a column of the table is called a
rule:
◦ A rule implies-
 if a condition is true, then execute
Example Decision Table
Conditions
Valid selection No Yes Yes Yes

New Member - Yes No No

Renewal - No Yes No

Cancellation - No No Yes

Actions
Display Error Message X
Ask Members Details X
Create Membership Record X
Generate Receipt X X
Ask Membership details X X
Update Membership Record X
Print Cheque X
Delete Record X