Organization of this Requirements Analysis and

Requirements Analysis and Lecture Specification

Specification Many projects fail:
Introduction because they start implementing the system:
Requirements analysis without determining whether they are building
Requirements specification what the customer really wants.
SRS document
It is important to learn:
Decision table
requirements analysis and specification techniques
Decision tree thoroughly.
Summary

1 2 3

Requirements Analysis and Requirements Analysis and Specification

Requirements ? Specification The person who undertakes requirements analysis and
Goals of requirements analysis and specification specification:
phase: known as systems analyst:
Being asked what you
fully understand the user requirements collects data pertaining to the product
want out of a system
is like being asked remove inconsistencies, anomalies, etc. from analyzes collected data:
requirements to understand what exactly needs to be done.
what you want out of
document requirements properly in an SRS writes the Software Requirements Specification (SRS)
life ! document.
document
Where do you start ! Consists of two distinct activities:
Final output of this phase:
What are the Requirements Gathering and Analysis Software Requirements Specification (SRS) Document.
parameters ! Specification
The SRS document is reviewed by the customer.
reviewed SRS document forms the basis of all future
development activities.
5 6
Requirements Analysis Requirements Gathering Requirements Gathering
(CONT.)
Requirements analysis consists of two main If the project is to automate some existing procedures
activities: e.g., automating existing manual accounting activities,
the task of the system analyst is a little easier Some desirable
Requirements gathering
analyst can immediately obtain: attributes of a good
Analysis of the gathered requirements system analyst:
input and output formats
accurate details of the operational procedures Good interaction
Analyst gathers requirements through: skills,
observation of existing systems, In the absence of a working system, imagination and
lot of imagination and creativity are required. creativity,
studying existing procedures,
discussion with the customer and end-users, experience.
Interacting with the customer to gather relevant data:
analysis of what needs to be done, etc. requires a lot of experience.
7 8 9

Requirement Gathering Analysis of the Gathered

techniques
Inconsistent requirement
Requirements
Interviews : Most common method
Some part of the requirement:
Questionnaires : collect information from a target population which After gathering all the requirements:
is very large and in remote locations contradicts with some other part.
Observations: Take notes while user is doing a process. analyze it:
Facilitated Workshops: bring a larger group on a common Clearly understand the user requirements, Example:
platform to discuss and reach agreements. They help to define cross-
functional requirements for a product Detect inconsistencies, ambiguities, and One customer says turn off heater
JAD :JAD (Joint Application Development) is a methodology that incompleteness. and open water shower when
involves the client or end user in the design and development of an
application, through a succession of collaborative workshops called Incompleteness and inconsistencies: temperature > 100 C
JAD sessions.
Brainstorming : It involves self-generated contribution of ideas by resolved through further discussions Another customer says turn off
the group members around a specific issue, problem or requirement.
with the end-users and the customers. heater and turn ON cooler when
Prototyping
Existing system/Documentation analysis
temperature > 100 C
11 12
 Analysis of the Gathered Requirements (CONT.)
Analysis of the Gathered Requirements(CONT.)
Incomplete requirement Requirements analysis involves:
obtaining a clear, in-depth understanding of the product to Several things about the project should be clearly
understood by the analyst:
Some requirements have been be developed,
What is the problem?
remove all ambiguities and inconsistencies from the initial
omitted: customer perception of the problem. Why is it important to solve the problem?
due to oversight. It is quite difficult to obtain: What are the possible solutions to the problem?
a clear, in-depth understanding of the problem: What complexities might arise while solving the
Example: especially if there is no working model of the problem. problem?
The analyst has not recorded: Experienced analysts take considerable time:
when temperature falls below 90 C to understand the exact requirements the customer has in his Some anomalies and inconsistencies can be very subtle:
mind.
heater should be turned ON escape even most experienced eyes.
Experienced systems analysts know - often as a result of painful
water shower turned OFF. experiences ---
If a formal model of the system is constructed,
many of the subtle anomalies and inconsistencies
without a clear understanding of the problem, it is impossible
13 to develop a satisfactory system. 14 get detected. 15

Software Requirements Software Requirements Specification: A Contract

SRS Document (CONT.)
Document
Specification The SRS document is known as black-box specification:
Requirements document is a reference document.
Main aim of requirements specification: the system is considered as a black box whose internal
SRS document is a contract between the development team details are not known.
systematically organize the requirements arrived and the customer.
during requirements analysis only its visible external (i.e. input/output) behavior is
Once the SRS document is approved by the customer, documented.
document requirements properly. any subsequent controversies are settled by referring
the SRS document. Input Data Output Data

The SRS document is useful in various contexts:

statement of user needs Once customer agrees to the SRS document: SRS document concentrates on:
contract document development team starts to develop the product according what needs to be done
reference document
to the requirements recorded in the SRS document. S
carefully avoids the solution (“how to do”) aspects.
The final product will be acceptable to the customer:
definition for implementation The SRS document serves as a contract
as long as it satisfies all the requirements recorded in the
between development team and the customer.
SRS document.
16 17 Should be carefully written 18
Properties of a good SRS document
SRS Document (CONT.) SRS Document (CONT.)
It should be concise
and at the same time should not be ambiguous.
It should specify what the system must do SRS document, normally It is desirable to consider every
and not say how to do it.
contains three important parts: system:
Easy to change.,
i.e. it should be well-structured.
functional requirements, performing a set of functions {fi}.
It should be consistent.
It should be complete. nonfunctional requirements, Each function fi considered as:
It should be traceable
transforming a set of input data to
you should be able to trace which part of the constraints on the system.
specification corresponds to which part of the design corresponding output data.
and code, etc and vice versa.
Input Data Output Data
It should be verifiable fi
e.g. “system should be user friendly” is not verifiable
19 20 21

Example: Functional Functional Requirements

Requirement Functional requirements describe:
A set of high-level requirements
F1: Search Book Each high-level requirement:
takes in some data from the user
Input: outputs some data to the user
an author’s name: Each high-level requirement:
might consist of a set of identifiable functions
Output:
details of the author’s books and the For each high-level requirement:
locations of these books in the library. every function is described in terms of
Author Name Book Details input data set
f1 output data set
processing required to obtain the output data set from
the input data set
22 24
Nonfunctional Nonfunctional
Requirements Requirements
Characteristics of the system Nonfunctional requirements include:
which can not be expressed as reliability issues,
functions: performance issues,
maintainability, human-computer interface issues,
portability, Interface with other external systems,
usability, etc. security, maintainability, etc.

25 26

Non functional requirements

Execution qualities - such as safety,

security and usability, which are
observable during operation (at run time).
Evolution qualities, such as testability,
maintainability, extensibility and
scalability, which are embodied in the
static structure of the system.
Constraints Examples of constraints Organization of the SRS
Document
Hardware to be used,
Constraints describe things that the Operating system Introduction.
system should or should not do. or DBMS to be used
Functional Requirements
Capabilities of I/O devices
For example,
Standards compliance Nonfunctional Requirements
standards compliance Data representations
how fast the system can produce results by the interfaced system External interface requirements
• so that it does not overload another Performance requirements
system to which it supplies data, etc.
Constraints

31 32 33

Example Functional
Example Functional Requirements Req. 1:
Requirements
List all functional requirements Req. 2: R.1.1:
with proper numbering. Input: “search” option,
When the “renew” option is selected, Output: user prompted to enter the key words.
Req. 1: the user is asked to enter his
Once the user selects the “search” R1.2:
option, membership number and password. Input: key words
he is asked to enter the key words. After password validation, Output: Details of all books whose title or author
The system should output details of all name matches any of the key words.
the list of the books borrowed by him are Details include: Title, Author Name, Publisher name, Year
books displayed. of Publication, ISBN Number, Catalog Number, Location in
whose title or author name matches any of the Library.
the key words entered. The user can renew any of the books: Processing: Search the book list for the keywords
Details include: Title, Author Name, by clicking in the corresponding renew
Publisher name, Year of Publication, ISBN
Number, Catalog Number, Location in the box.
Library. 34 35 36
 Examples of Bad SRS Documents
Req. 2: Req. 2:
Unstructured Specifications:
R2.1: Narrative essay --- one of the worst types of
Input: “renew” option selected, specification document:
Output: user prompted to enter his R2.3: Difficult to change,
membership number and password. Input: user choice for renewal of the
R2.2: difficult to be precise,
Input: membership number and password books issued to him through mouse difficult to be unambiguous,
Output: clicks in the corresponding renew box. scope for contradictions, etc.
list of the books borrowed by user are displayed.
User prompted to enter books to be renewed or Output: Confirmation of the books Noise:
user informed about bad password Presence of text containing information irrelevant to
Processing: Password validation, search renewed
books issued to the user from borrower list the problem.
and display. Processing: Renew the books selected Silence:
by the in the borrower list. aspects important to proper solution of the problem
37 38 are omitted. 39

Examples of Bad SRS Documents Representation of complex

Overspecification: processing logic: What is a Decision tree
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. Decision trees A decision tree is a graph that uses a
Contradictions: branching method to illustrate every
Contradictions might arise
if the same thing described at several places in different ways.
Decision tables possible outcome of a decision
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 40 41
for which realistic solutions will be hard to find.
Decision Trees Example: LMS Example(cont.)
Decision trees:
When the new member option is selected,
edges of a decision tree represent conditions
the software asks details about the member: If the renewal option is chosen,
leaf nodes represent actions to be performed. name, LMS asks the member's name and his
A decision tree gives a graphic view of: address, membership number
logic involved in decision making phone number, etc. checks whether he is a valid member.
corresponding actions taken.
Example: LMS If the name represents a valid member,
If proper information is entered,
A Library Membership automation Software (LMS) should the membership expiry date is updated and
a membership record for the member is created
support the following three options: the annual membership bill is printed,
a bill is printed for the annual membership charge
new member, plus the security deposit payable. otherwise an error message is displayed.
renewal,
cancel membership. 43 44 45

Example(cont.) Decision Tree Student Information

Management System

If the cancel membership option User input

is selected and the name of a Invalid

New member Renewal Cancel option
valid member is entered,
- Get Details
the membership is cancelled, -Get details
-Print bills - Print Cheque
- Print error message

-Create record
a cheque for the balance amount - Delete record

due to the member is printed

Update record Print bills
the membership record is deleted. Get Details

46 47
Decision Tree as we understand Decision table
Decision tables are a concise visual
representation for specifying which actions to
perform depending on given conditions.
They are algorithms whose output is a set of
actions.
The information expressed in decision tables
could also be represented as decision trees or in
a programming language as a series of if-then-
else and switch-case statements.

Decision Table Decision Table Algorithm for Bonus Payment

A decision table shows in a tabular form:

Decision tables specify: processing logic and corresponding actions
which variables are to be tested Upper rows of the table specify:
what actions are to be taken if the the variables or conditions to be evaluated

conditions are true, Lower rows specify:

the actions to be taken when the corresponding
the order in which decision making is conditions are satisfied.
performed. In technical terminology,
a column of the table is called a rule:
Upper rows - conditions
A rule implies: Lower rows - Actions
Column - Rule
if a condition is true, then execute the
52 corresponding action. 53
Table to Tree ?

Example: Comparison
Conditions
Valid selection NO YES YES YES Both decision tables and decision trees
New member -- YES NO NO can represent complex program logic.
Renewal -- NO YES NO
Cancellation -- NO NO YES Decision trees are easier to read and
Actions understand
Display error message -- -- --
when the number of conditions are small.
Ask member's name etc.
Build customer record -- -- -- Decision tables help to look at every
Generate bill -- -- possible combination of conditions.
Ask membership details --
Update expiry date -- -- --
Print cheque -- -- --
Delete record -- -- -- 59 60
Formal Specification Formal Specification
A formal software specification is a statement
A formal specification technique expressed in a language whose vocabulary,
syntax, and semantics are formally defined.
is a mathematical method to:
accurately specify a system The need for a formal semantic definition means
verify that implementation that the specification languages cannot be
based on natural language;
satisfies specification
prove properties of the It must be based on mathematics.
specification

61 62

Acceptance of formal methods Use of formal methods

Formal methods have not become mainstream Their principal benefits are in reducing the number
software development techniques as was once of errors in systems so their main area of applicability is
predicted critical systems:
Air traffic control information systems,
Other software engineering techniques have been successful at Railway signalling systems
increasing system quality. Hence the need for formal methods has Spacecraft systems
been reduced Medical control systems

Market changes have made time-to-market rather than software with

a low error count the key factor. Formal methods do not reduce time In this area, the use of formal methods is most likely
to market to be cost-effective

The scope of formal methods is limited. They are not well-suited to Formal methods have limited practical applicability
specifying and analysing user interfaces and user interaction

Formal methods are hard to scale up to large systems

 Formal Specification Formal Specification
Advantages:
Well-defined semantics, no scope for ambiguity Mathematical techniques used
Automated tools can check properties of include:
specifications
Logic-based
Executable specification
set theoretic
Disadvantages of formal specification techniques: algebraic specification
Difficult to learn and use finite state machines, etc.
Not able to handle complex systems

68 69

Executable Specification Executable Specification

Semiformal Specification
Language Language

Structured specification languages If specification is expressed in formal Executable specifications only test
SADT (Structured Analysis and Design functional requirements:
Technique)
language:
it becomes possible to execute the If non-functional requirements are
PSL/PSA (Problem Statement
specification to provide a system important for some product,
Language/Problem Statement Analyzer)
PSL is a semi-formal specification language prototype. the utility of an executable
PSA can analyze the specifications However, executable specifications specification prototype is limited.
expressed in PSL are usually slow and inefficient.
70 71 72
4GLs 4GLs Summary
Requirements analysis and specification
4GLs (Fourth Generation Languages) are 4GLs rely on software reuse
examples of an important phase of software development:
where common abstractions have been
identified and parameterized. any error in this phase would affect all
executable specification languages. subsequent phases of development.
Eg. SQL, Mathematica
Rewriting 4GL programs in higher level
languages: Consists of two different activities:
4GLs are successful Requirements gathering and analysis
result in upto 50% lower memory
because there is a lot of commonality requirements Requirements specification
across data processing applications. also the programs run upto 10 times faster.

73 74 75

Summary Summary Summary

The aims of requirements analysis: Main components of SRS document: Formal requirements
Gather all user requirements functional requirements
Clearly understand exact user requirements specifications have several
nonfunctional requirements
Remove inconsistencies and advantages.
incompleteness. constraints
Techniques to express complex
But the major shortcoming is
The goal of specification: logic: that these are hard to use.
systematically organize requirements Decision tree
document the requirements in an SRS Decision table
document.
76 77 78
 SRS template
Activity 2 - write SRS Functional requirements

Functional Requirements should include:

Descriptions of data to be entered into the system

Descriptions of operations performed by each screen
Descriptions of work-flows performed by the system
Descriptions of system reports or other outputs
Who can enter the data into the system
How the system meets applicable regulatory
requirements

Non Functional requirements

Example

Performance – for example Response Time, Throughput,

Section/ Utilization, Static Volumetric.
Requirement ID Requirement Definition Scalability.
FR1.0. The system shall [parent requirement group 1]. Capacity.
FR1.1 The system shall [child/parent requirement].
Availability.
FR1.1.1 The system shall [child requirement].
Reliability.
FR1.1.2 The system shall [child requirement].
Recoverability.
Maintainability.
And also write constraints