1

UNIT-3
REQUIREMENT ANALYSIS & SPECIFICATIONS
3.0 UNDERSTAND THE CONCEPTS IN REQUIREMENT ANALYSIS & SPECIFICATIONS

REQUIREMENT ANALYSIS AND SPECIFICATION:

 The requirement analysis and specification phase starts after the feasibility study phase is complete
and the project has been found to be technically feasible.
 The goal of the requirement analysis and specification phase is to clearly understand the customer
requirements and to systematically organize the requirements into a specification document.
 The requirement analysis and specification phase ends with the production and validation of the
requirement specification document that is usually called Software Requirement Specification (SRS).
 The engineers who gather and analyse customer requirements and then write the requirement
specification document are known as system analyst.
 The SRS document is the final outcome of the requirements analysis and specification phase.
 The main activities carried out during requirements analysis and specification phase are of two types :-
 Requirements gathering and analysis
 Requirements specification
REQUIREMENTS GATHERING AND ANALYSIS
We can broadly divide the requirements gathering and analysis activity into two separate tasks as
a. Requirements gathering
b. Requirements analysis
(a) REQUIREMENT GATHERING
The goal of the requirements gathering is to collect all relevant information regarding the product to
be developed from customer with a view to clearly understand the customer requirements.
(b) REQUIREMENTS ANALYSIS:
The goal of the requirement analysis is to viewed out the incompleteness and inconsistency in the
requirements.
REQUIREMENTS SPECIFICATION:
The customer requirements identified during the requirements gathering and analysis activity are
organized into a software requirements (SRS) document.
1. The SRS document contains three contents like
a. Functional requirements
b. Non-functional requirements
c. Goals of implementation
2. The SRS document is written using end user terminology.
3. SRS is understandable by customer.
4. SRS is reviewed and approved by customer.

3.1 REQUIREMENTS GATHERING AND ANALYSIS

We can broadly divide the requirements gathering and analysis activity into two separate tasks as
requirements gathering and requirements analysis.
a) Requirements gathering.
b) Requirements analysis.
(a) REQUIREMENTS GATHERING:
 Requirements gathering are also popularly known as requirements elicitation.
 The analyst starts requirements gathering activity by collecting all information that could be
useful to develop the system.
The important ways in which the analyst gather requirements
 STUDYING THE EXISTING DOCUMENTS:
 The analyst usually studies all existing documents regarding the system to be developed.
Before visiting the customer site.
 2
 These documents is used to know the purpose, context, the share holders etc..
 INTERVIEW:
 There are many different categories of users of software.
 Different categories of users typically require different features from the software.
EXAMPLE:
 For the library automation software, one category of users may be the library members who would
like to query, issue, return books etc…
 Another category of users is the librarian who would like to count the overdue book, create and
delete accounts etc.
 All the different categories of users are interviewed to gather the different functionalities required
by them.
EXAMPLE:
To perform requirement gathering of library automation software, the analyst might interview the library
automation software, the analyst might interview the library members, the librarian, and the accountant.
 TASK ANALYSIS:
 The user usually views software as a block box that provides a set of services.
 A service is also called task.
 For each task the analyst tries to formulate different steps necessary to realise the service in
consulation with the users.
 For issue book service the steps may be
a) Authenticate users
b) Check the number of books.
c) Check whether the book has been reserved.
d) Print book issue slip.
 SCENARIO ANALYSIS
 A task may have many scenarios (situations) of operation.
 The different scenarios of a task con occur when the task is invoked under different situations .they are
a) Book issue is performed and issue slip is printed.
b) The book is reversed and cannot be issued.
c) The maximum of books issued is exceeded and cannot be issued.
 FORM ANALYSIS
 The different forms are analysed to determine the data input to the data that input to the system and the
data that are output from the system.
 For different input how these are used by the system to produce the corresponding output data are
determined from the users.
(b) REQUIREMENTS ANALYSIS.
 After requirements gathering is complete, the analyst the gathered requirements to clearly understand
the exact customer requirements and to find out any problems in the gathered requirements.
 The main goal is to viewed incompleteness and inconsistencies in the requirements.
 The following basic questions pertaining to the project should be clearly understood by the analyst in
order to obtain a good grasp of the problem
(a)What is the problem?
(b)Why it is important to solve the problem?
(c)What exactly the input and output of the system?
(d)What are possible procedures to solve the problem?
(e)What are complexities to solve the problem?
 There are three main types of problems in the requirements that the analyst needs to identify and resolve
1. Ambiguity.
2. Inconsistency.
3. Incompleteness.

1. Ambiguity:
 3
 An anomaly is an ambiguity in the requirement.
 When a requirement is ambiguous, several interpretations of those requirements are possible.
 Ambiguity in the requirements can be lead to develop of incorrect system.
 Example: When the becomes high, the heater should be switched off. The word high may be interpreted.
2. Inconsistency:
 Two requirements are said to be inconsistent, if one of the requirements contradicts the other.
 The two end users of the system give inconsistent description of the requirements.
3. Incompleteness:
 An incomplete set of requirements is one in which some requirements have overlooked.
 The lack of these features would be realized by the customer much later, possible while using the
product.

3.2 SOFTWARE REQUIREMENT SPECIFICATIONS (SRS)

 The customer requirements identified during the requirements gathering and analysis activity are
organised into a software requirements specification (SRS) document.
 The SRS document usually contains all the user requirements in structured through informal form.
 Some of the important categories of users of the SRS document and their needs are as follows.
1) Users, customers and marketing personnel:
The goal of this set of audience in referring to the SRS document is to ensure that the system as
describe will meet their needs.
2) Software Developers:
The software developers refer to the SRS document to make sure that they are developing exactly
what is required by the customer.
3) Test Engineers:
Their goal is to ensure that the requirements are understandable from a functionality point of view, so
that they can test the software and validate its working.
4) User Documentation Writers:
Their goal is reading the SRS document is to ensure that they understand the features of the product
well enough to be able to write the user’s manuals.
5) Project Managers:
They want to ensure that they can estimate the cost of the project easily by referring to the SRS
document and that it contains all the information required planning the project.
6) Maintenance Engineers:
The SRS document helps the maintenance engineers to understand the functionalities of the system.
A clear knowledge of the functionalities can help them to understand the design and code.

3.2.1 CONTENTS OF THE SRS DOCUMENT

Categorize (Or) Aspects (Or) Contents of SRS document:
An SRS document should clearly document the following three aspects (or) categories:
 FUNCTIONAL REQUIREMENTS
 NON-FUNCTIONAL REQUIREMENTS
 GOALS OF IMPLEMENTATION

Functional Requirements:
 The functional requirements discuss the functionalities required by the users from the system.
 It is useful to consider a system as performing a set of functions{fi}
 These functions can be considered similar to a mathematical function f:i->0.it means that a function
transforms an element(ii)in the input domain(I) to output(o)
 Each function (fi) of system can reading data (ii) and transformed to output data (oi).
 The functional requirements of the system should clearly describe the each function which system would
support the input and output dataset.

Non-Functional Requirements:
 4
 The non-functional requirements deal with the characteristics of a system that cannot be expressed as
functions.
 Non-functional requirements deal with the characteristics of a system that cannot be expressed as
functions.
 Non-functional requirements address aspects contain maintainability, portability, usability, no-of users
timing and throughput etc.
 It may also include reliability issues, HCI issues implementation.
 IEE 870 standard lists four types of non-functional requirements
o External interface requirements.
o Performance requirements.
o Constraints.
o Software system attributes.

Goals of Implementation:
 The goals of implementation part of the SRS document offers some general suggestions regarding
development.
 The developers may take these suggestions in to account if possible.
 A goal is not checked by the customer at the time of acceptance testing.
 The goals of implementation section might document issues such as revisions to the system functionalities
that may be required in the future.

3.2.2 FUNCTIONAL REQUIREMENTS

 In order to document the functional requirement of a system it is necessary to first learn to identify the
high-level functionalities of system.
 The high level functions would be split into smaller sub requirements.
 Each high level function corresponds to an instance of use of system by the user in some way.
 A high level function is one using which can user can get some useful piece of work done.
 Each high level requirement typically involves accepting some data from the user, transforming it to the
required output to user.
 In fact 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 due to users selecting
different options or entering different data items.
 Each high level requirement might consist of several sub requirements.
 5

FIG: Interactions Between the users and the system in the withdraw-cash high-level functional requirement.
3.2.3 HOW TO IDENTIFY THE FUNCTIONAL REQUIREMENTS
 The high-level functional requirements often need to be identify either from an informal problem
description document or from a conceptual understanding of the problem.
 Remember that there can be many types of users of a system and their requirements from the system may
be very different.
 So it is often useful to first identify the different types of users who might use the system and then try to
identify the different services expected from the software by different types of users.
 Example: Consider the issue invokes-book function in a library automation system. Suppose when a user
invokes the issue-book function, the system would required the user to enter the details of each book to be
issued. Should the entry of the book details be considered as a high-level function?

3.2.4 HOW TO DOCUMENT THE FUNCTIONAL REQUIREMENTS, TRACEABILITY

 HOW TO DOCUMENT THE FUNCTIONAL REQUIREMENTS:
 Once all the high level functional requirements have been identified , they can be documented.
 A function can be documented by identifying the state at which the data is to be input to the system
and type of processing to be carried on the input data to obtain the output data.
 Example: Withdraw cash from ATM.
R.1: WITHDRAW CASH:
DESCRIPTION:
1. The withdraw cash functions first determines the type of account that the user has and the account number
from which the user wishes to withdraw cash.
2. It checks the balance to determine whether the requested amount.
3. If enough balance is available, it outputs the required cash, otherwise it generates an error message.
R.1.1: SELECT WITHDRAW AMOUNT OPTION:
INPUT :”withdraw amount” option.
OUTPUT :user prompted to enter the account type.
R.1.2:SELECT ACCOUNT TYPE:
INPUT : user option from any on the following: savings/checking/deposit
OUTPUT : prompt to enter amount
R.1.3: GET REQUIRED AMOUNT:
INPUT : Amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100.
OUTPUT : The requested cash and printed transaction statement.
PROCESSING: The amount is debited from the user’s account if sufficient balance is available, otherwise an
error message is displayed.
 6

TRACEABILITY:
1. Traceability means that it would be possible to tell which design component to which design component, and
which test case corresponds to which requirement etc.
2. Thus, a given code component can be traced to the corresponding design component, and a design
component can be traced to a specific requirement that it implements and vice versa.
3. Traceability analysis makes it easy to identify which parts of the design and code would be affected.
4. It can also used to study the impact of a bug on various requirements
5. To achieve traceability it is necessary that each functional requirement should be numbered uniquely and
consistently.
6. Proper numbering of the requirements makes it possible for different documents to uniquely refer to
specific requirements.

3.2.5 CHARACTERISTICS OF A GOOD SRS DOCUMENT

 The skill of writing a good SRS document usually comes from the experience gained from writing SRS
documents for many problems.
 Some of the identified desirable quantities of the SRS documents are
CONCISE:
 The SRS document should be concise and at the same time unambiguous, consistent and complete.
 Words and irrelevant description reduce readability and also increase error possibilities.
STRUCTURED:
 It should be well-structured. A well-structured document is easy to understand and modify.
 In order to make the modifications to the SRS document easy, it is important to make the document well-
structured.
BLACK BOX VIEW
 It should be only specify what the system should do and refrain from stating how to do these.
 This means that the SRS document should specify the external behaviour of the system and not discuss
the implementation issues.
 The SRS document should view the system to be developed as a black box, and should specify the
external visible behaviour of the system.
TRACEABLE:
 It should be possible to trace a requirement to the design elements that implement is and vice versa.
 It should be possible to trace a requirement to the code segments that implement it and the test these
requirements & vice versa.
RESPONSE TO UNDESIRED EVENTS:
 It should characterize acceptable responses to undesired events.
 These are called system response to exceptional conditions.
VERIFIABLE:
 All the requirements of the system as document in the SRS document.
 This means that it should be possible to determine whether or not requirements have been met in an
implementation.
 Any requirements such as the system should be user-friendly s are not verified.
 Any requirements that are not verifiable should be listed separately in the goals of implementation.

3.2.6 EXAMPLES OF BAD SRS DOCUMENT

 The most important problems that one needs to watch out for are incompleteness, ambiguity and
contradictions.
 There are many other problems that a specification document might suffer from.
 Some of the important categories of problems that many SRS documents suffer from are as follows.
Over Specification:
 Over specification occurs when you try to address the how to aspects in the SRS documents.
 For example, in the library automation problem, you should not specify the library membership records
need to be stored sorted on the member’s first name in a descending order arrangement.
 Over specification restricts the freedom of the designer in arriving at a good design solution.
 7
Forward References:
 You should not refer to aspects that are discussed much later in the SRS document.
 Forward referencing reduces the readability of the specifications.
Wishful Thinking:
 In this type problems concern description of aspects which would be difficult to implement.
Noise:
 The term nose refers to presence of material not directly relevant to the software development.
 For example, in the register customer function suppose we write that customer registration department
is managed by clerks who report for work between 8am and 5pm in 7days a week.
3.2.7 ORGANIZATION OF THE SRS DOCUMENT
 Organization of the SRS document depends to a large extent on the system analyst himself, often guided
by the policies and standards of the company
 Irrespective of the company principles and product type the three basics issues that any SRS document
should discuss are
 functional requirements
 non-functional requirements
 goals of implementation
Organization:
1. Introduction
I. Purpose
II. Overview
III. Environmental characteristics
a) hardware
b) peripherals
c) people
2. Goals Of Implementation
3. Functional Requirements
1. User class1
a) Functional Requirements1.1
b) Functional Requirements1.2
2. User class2
a) Functional Requirements2.1
b) Functional Requirements2.2
4. Non- Functional Requirements
a) External interfaces
b) User interfaces
5. Behavioural Description
a) System states
b) Events and actions
 The above organization of SRS document as prescribed by the IEEE 830 standards
 IEEE 830 serves only as guidelines for SRS document
 Depending on the specific problem being specified, some sections can be omitted, introduced or
interchanged
 The introduction section describes the context in which the system is being developed
 The environment characteristics subsection describes the properties of the environment with which
the system will interact
 Specification of the behaviour may not be necessary for all systems
 It is necessary for system transits among a set of states depending on some condition