Software Requirements

Specification
●
Main aim of requirements
specification:
– Systematically organize the
requirements arrived during
requirements analysis.
– Document requirements properly.

1
 Software Requirements
Specification
●
The SRS document is useful in
various contexts:
– Statement of user needs
– Contract document
– Reference document
– Definition for implementation

2
 Software Requirements
Specification: A Contract
Document
●
Requirements document is a
reference document.
●
SRS document is a contract
between the development team
and the customer.
– Once the SRS document is approved
by the customer,
●
Any subsequent controversies are settled
by referring the SRS document.

3
 Software Requirements
Specification: A Contract
Document
●
Once customer agrees to the SRS
document:
– Development team starts to develop the
product according to the requirements
recorded in the SRS document.
●
The final product will be acceptable
to the customer:
– As long as it satisfies all the
requirements recorded in the SRS
document.
4
 SRS Document (CONT.)

●
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) behavior is documented.

Output Data
Input Data S

5
 SRS Document (CONT.)

●
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

6
 SRS Document (CONT.)

●
The requirements at this
stage:
– Writtenusing end-user
terminology.
●
If necessary:
– Latera formal requirement
specification may be
developed from it.
7
 Properties of a Good
SRS Document
●
It should be concise
– and at the same time should not be
ambiguous.
●
It should specify what the system must
do
– and not say how to do it.
●
Easy to change.,
– i.e. it should be well-structured.
●
It should be consistent.
●
It should be complete.

8
 Properties of a Good
SRS Document (cont...)
●
It should be traceable
– You should be able to trace
which part of the specification
corresponds to which part of
the design, code, etc and vice
versa.
●
It should be verifiable
– e.g. “system should be user
friendly” is not verifiable
9
 SRS Document (CONT.)

●
SRS document, normally
contains three important
parts:
– Functional requirements,
– Non-functional requirements,
– Goals of Implementation.

10
 SRS Document (CONT.)

●
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

11
 Example: Functional
Requirement
●
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

12
 Functional
Requirements
●
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

13
 Functional
Requirements
●
For each high-level
requirement:
– Everyfunction is described in
terms of:
●
Input data set
●
Output data set
●
Processing required to obtain the
output data set from the input data
set.
14
 Nonfunctional
Requirements
●
Characteristics of the
system which can not be
expressed as functions:
●
Maintainability,
●
Portability,
●
Usability, etc.

15
 Nonfunctional
Requirements
●
Nonfunctional requirements include:
– Reliability issues,
– Performance issues:
●
Example: How fast the system can produce
results
– so that it does not overload another
system to which it supplies data, etc.
– Human-computer interface issues,
– Interface with other external systems,
– Security, maintainability, etc.

16
 Non-Functional
Requirements
●
Hardware to be used,
●
Operating system
– or DBMS to be used
●
Capabilities of I/O devices
●
Standards compliance
●
Data representations
– by the interfaced system

17
 Goals of Implementation
●
Goals describe things that are
desirable of the system:
– But, would not be checked for
compliance.
– For example,
●
Reusability issues
●
Functionalities to be developed in future

18
Organization of the SRS
Document
●
Introduction.
●
Functional Requirements
●
Nonfunctional Requirements
– External interface requirements
– Performance requirements
●
Goals of implementation

19
 Functional
Requirements
●
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?
●
A high-level requirement typically
involves:
– Accepting some data from the user,
– Transforming it to the required response,
and then
– Outputting the system response to the user.
20
 High-Level Function
●
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.
21
 Example Functional
Requirements
●
List all functional requirements
– with proper numbering.
●
Req. 1:
– Once the user selects the “search”
option,
●
he is asked to enter the key words.
– The system should output details of all
books
●
whose title or author name matches any of
the key words entered.
●
Details include: Title, Author Name,
Publisher name, Year of Publication, ISBN
Number, Catalog Number, Location in the
Library.
22
 Example Functional
Requirements
●
Req. 2:
– When the “renew” option is selected,
●
The user is asked to enter his
membership number and password.
– After password validation,
●
The list of the books borrowed by him
are displayed.
– The user can renew any of the books:
●
By clicking in the corresponding renew
box.

23
 Req. 1:
●
R.1.1:
– Input: “search” option,
– Output: user prompted to enter the key
words.
●
R1.2:
– 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, ISBN Number, Catalog
Number, Location in the Library.
– Processing: Search the book list for the
keywords
24
 Req. 2:
●
R2.1:
– Input: “renew” option selected,
– Output: user prompted to enter his
membership number and password.
●
R2.2:
– 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
– Processing: Password validation, search
books issued to the user from borrower list
and display.

25
 Req. 2:
●
R2.3:
– 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.

26
 Examples of Bad SRS
Documents
●
Unstructured Specifications:
– Narrative essay --- one of the
worst types of specification
document:
●
Difficult to change,
●
Difficult to be precise,
●
Difficult to be unambiguous,
●
Scope for contradictions, etc.

27
 Examples of Bad SRS
Documents
●
Noise:
– Presence of text containing
information irrelevant to the problem.
●
Silence:
– aspects important to proper solution
of the problem are omitted.

28
 Examples of Bad SRS
Documents
●
Overspecification:
– Addressing “how to” aspects
– For example, “Library member names should
be stored in a sorted descending order”
– Overspecification restricts the solution space
for the designer.
●
Contradictions:
– Contradictions might arise
●
if the same thing described at several places in
different ways.

29
 Examples of Bad SRS
Documents
●
Ambiguity:
– Literary expressions
– Unquantifiable aspects, e.g. “good user
interface”
●
Forward References:
– References to aspects of problem
●
defined only later on in the text.
●
Wishful Thinking:
– Descriptions of aspects
●
for which realistic solutions will be hard to find.

30
 Representation of complex
processing logic:
●
Decision trees
●
Decision tables

31
 Decision Trees
●
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.

32
 Example: LMS
●
A Library Membership
automation Software (LMS)
should support the following
three options:
– New member,
– Renewal,
– Cancel membership.

33
 Example: LMS
●
When the new member option
is selected,
– The software asks details about
the member:
●
name,
●
address,
●
phone number, etc.

34
 Example(cont.)
●
If proper information is entered,
– A membership record for the
member is created
– A bill is printed for the annual
membership charge plus the
security deposit payable.

35
 Example(cont.)
●
If the renewal option is chosen,
– LMS asks the member's name and his
membership number
●
checks whether he is a valid member.
– If the name represents a valid member,
●
the membership expiry date is updated
and the annual membership bill is printed,
●
otherwise an error message is displayed.

36
 Example(cont.)
●
If the cancel membership option
is selected and the name of a
valid member is entered,
– The membership is cancelled,
– A cheque for the balance amount
due to the member is printed
– The membership record is deleted.

37
 Decision Tree
- Get details
- Create record
- Print bills
New member
- Get Details
User Renewal - Update record
- Print bills
input
Cancel - Get Details
- Print Cheque
- Delete record
Invalid
option
- Print error message

38
 Decision Table
●
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.

39
 Decision Table
●
A decision table shows in a tabular
form:
– Processing logic and corresponding actions
●
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.

40
 Decision Table
●
In technical terminology,
–a column of the table is called
a rule:
–A rule implies:
●
if a condition is true, then
execute the corresponding
action.

41
 Example:
●
Conditions
Valid selection NO YES YES YES
New member -- YES NO NO
Renewal -- NO YES NO
Cancellation -- NO NO YES
●
Actions
Display error message -- -- --

Ask member's name etc.

Build customer record -- -- --
Generate bill -- --
Ask membership details --
Update expiry date -- -- --
Print cheque -- -- --
Delete record -- -- --
42
 Comparison
●
Both decision tables and decision trees
– Can represent complex program logic.
●
Decision trees are easier to read and
understand
– When the number of conditions are small.
●
Decision tables help to look at every
possible combination of conditions.

43
 Formal Specification
●
A formal specification
technique is a mathematical
method to:
– Accurately specify a system.
– Verifythat implementation
satisfies specification.
– Prove properties of the
specification.

44
 Formal Specification
●
Advantages:
– Well-defined
semantics, no
scope for ambiguity
– Automated tools can check
properties of specifications
– Executable specification

45
 Formal Specification
●
Disadvantages of
formal specification
techniques:
– Difficult to learn and use
– Not
able to handle
complex systems
46
 Formal Specification
●
Mathematical techniques
used include:
– Logic-based

– set theoretic
– algebraic specification
– finite state machines, etc.

47
 Semiformal Specification

●
Structured specification languages
– SADT (Structured Analysis and Design
Technique)
– PSL/PSA (Problem Statement
Language/Problem Statement Analyzer)
●
PSL is a semi-formal specification
language
●
PSA can analyze the specifications
expressed in PSL

48
 Executable Specification
Language
●
If specification is expressed
in formal language:
– it
becomes possible to
execute the specification to
provide a system prototype.
●
However, executable
specifications are usually
slow and inefficient.
49
 Executable Specification
Language
●
Executable specifications
only test functional
requirements:
– Ifnon-functional
requirements are important
for some product,
●
The utility of an executable
specification prototype is
limited.
50
 4GLs
●
4GLs (Fourth Generation
Languages) are examples of
– executable specification
languages.
●
4GLs are successful
– becausethere is a lot of
commonality across data
processing applications.
51
 4GLs
●
4GLs rely on software reuse
– Where common abstractions have
been identified and parameterized.
●
Rewriting 4GL programs in
higher level languages:
– Result in upto 50% lower memory
requirements
– Also the programs run upto 10
times faster.
52