How to Gather Requirements?

• Observe existing (manual) systems, needs

• Study existing procedures, Gathering

Analysis

• Discuss with customer and end-users, Specification

• Input and Output analysis Review

SRS

• Analyze what needs to be done Document

 Requirements Gathering Activities
• 1. Study existing documentation

• 2. Interview

• 3. Task analysis

• 4. Scenario analysis

• 5. Form analysis
 Requirements Gathering (CONT.)

• 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.
 Requirements Gathering (CONT.)

• Some desirable attributes of a good requirements

analyst:

– Good interaction skills,

– Imagination and creativity,

– Experience…
 Case Study: Automation of Office Work at CSE Dept.
• The academic, inventory, and financial information at the
CSE department:
– At present carried though manual processing by two office
clerks, a store keeper, and two attendants.

• Considering the low budget he had at his disposal:

– The HoD entrusted the work to a team of student volunteers.
 Case Study: Automation of Office Work at CSE Dept.
• The team was first briefed by the HoD:
– Concerning the specific activities to be automated.
• The analysts first discussed with the two office clerks:
– Regarding their specific responsibilities (tasks) that were to be
automated. Interview

• The analyst also interviewed student and faculty

representatives who would also use the software.
 Case Study: Automation of Office Work at CSE Dept.

• For each task that a user needs the software to perform,

they asked: Task and Scenario Analysis

– The steps through which these are to be performed.

– The various scenarios that might arise for each task.

• Also collected the different types of forms that were being used.
Form Analysis
 Case Study: Automation of Office Work at CSE Dept.
• The analysts understood the requirements for the system from
various user groups: Requirements Analysis
– Identified inconsistencies, ambiguities, incompleteness.
• Resolved the requirements problems through discussions with
users:
– Resolved a few issues which the users were unable to resolve
through discussion with the HoD. Requirements Specification

• Documented the requirements in the form of an SRS document.

 Analysis of Gathered Requirements
needs
• Main purpose of req. analysis: Gathering

Analysis

• Clearly understand user requirements, Specification

Review
• Detect inconsistencies, ambiguities, and incompleteness.
SRS Document

• Incompleteness and inconsistencies:

– Resolved through further discussions with the end-users
and the customers.
 Ambiguity
“All customers must have the same control field.”
Do you notice any problems?
Multiple interpretations possible

1. All control fields have the same format.

2. One control field is issued for all customers.

 Inconsistent Requirement
• Some part of the requirement:
– contradicts some other requirement.
• Example:
– One customer says turn off heater and open water shower when
temperature > 100°C
– Another customer says turn off heater and turn ON cooler when
temperature > 100°C
• Some requirements not included:
– Possibly due to oversight. Incomplete
Requirement
• Example:
– The analyst has not recorded that when temperature falls below
90°C :

• heater should be turned ON

• water shower turned OFF.

 Analysis of the Gathered Requirements
• Requirements analysis involves:
– Obtaining a clear, in-depth understanding of the software to
be developed

– Remove all ambiguities and inconsistencies from the initial

customer perception of the problem.
 Analysis of the Gathered Requirements (CONT.)

• It is quite difficult to obtain:

– A clear, in-depth understanding of the problem:

• Especially if there is no working model of the problem.

 Analysis of the Gathered Requirements (CONT.)

• Experienced analysts take considerable time:

– Clearly understand the exact requirements the customer

has in his mind.
 Analysis of the Gathered Requirements (CONT.)

• Experienced systems analysts know - often as a result of

painful experiences ---
– “Without a clear understanding of the problem, it is
impossible to develop a satisfactory system.”
 Analysis of the Gathered Requirements
• Several things about the project should be clearly
understood:

– What is the problem?

– What are the possible solutions to the problem?

– What complexities might arise while solving the problem?

 Analysis of the Gathered Requirements
• Some anomalies and inconsistencies can be very
subtle:
– Escape even most experienced eyes.

– If a formal specification of the system is constructed,

• Many of the subtle anomalies and inconsistencies get detected.
 Analysis of the Gathered Requirements (CONT.)

• After collecting all data regarding the system to be

developed,
– Remove all inconsistencies and anomalies from the
requirements,

– Systematically organize requirements into a Software

Requirements Specification (SRS) document.
 Software Requirements Specification
needs
• Main aim:
Gathering

– Systematically organize the requirements Analysis

Specification
arrived during requirements analysis.
Review

– Document requirements properly. SRS Document

 SRS Document
• As already pointed out--- useful in various contexts:

– Statement of user needs

– Contract document

– Reference document

– Definition for implementation

 SRS Document (CONT.)

• SRS document is known as black-box specification:

– The system is considered as a black box whose internal details are

S
not known. Input Output
Data Data

– Only its visible external (i.e. input/output) behavior is

documented.
 SRS Document (CONT.)

• SRS document concentrates on:

– What needs to be done in terms of input-output behaviour

– Carefully avoids the solution (“how to do”) aspects.

 SRS Document (CONT.)

• The requirements at this stage:

– Written using end-user terminology.

• If necessary:
– Later a formal requirement specification may be developed
from it.
• 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. Properties of a Good SRS
• Easy to change., Document

– i.e. it should be well-structured.

• It should be consistent.
• It should be complete.
 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
• Project development plans
SRS should not include...
– E.g. cost, staffing, schedules, methods, tools, etc
• Lifetime of SRS is until the software is made obsolete
• Lifetime of development plans is much shorter

• Product assurance plans

– Configuration Management, Verification & Validation, test plans,
Quality Assurance, etc
• Different audiences
• Different lifetimes

• Designs
– Requirements and designs have different audiences
– Analysis and design are different areas of expertise
 SRS Document (CONT.)

• Four important parts:

– Functional requirements,

– External Interfaces

– Non-functional requirements,

– Constraints
 Functional Requirements
• Specifies all the functionality that the system should support
– Heart of the SRS document:

– Forms the bulk of the Document

• Outputs for the given inputs and the relationship between them

• Must specify behavior for invalid inputs too!

 Functional Requirement Documentation
• Overview
– describe purpose of the function and the approaches and
techniques employed
• Inputs and Outputs
– sources of inputs and destination of outputs
– quantities, units of measure, ranges of valid inputs and outputs
– timing
 Functional Requirement Documentation
• Processing
– validation of input data
– exact sequence of operations
– responses to abnormal situations
– any methods (eg. equations, algorithms) to be used to
transform inputs to outputs
 Nonfunctional Requirements
• Characteristics of the system which can not be expressed as
functions:
• Maintainability,
• Portability,
• Usability,
• Security,
• Safety, etc.
 Nonfunctional Requirements
• Reliability issues
• Performance issues:
– Example: How fast can the system produce results?
• At a rate that does not overload another system to which it
supplies data, etc.
• Response time should be less than 1sec 90% of the time
• Needs to be measurable (verifiability)
 Constraints
• Hardware to be used,
• Operating system
– or DBMS to be used

• Capabilities of I/O devices

• Standards compliance
• Data representations by the interfaced system
• User interfaces
• Hardware interfaces External Interface
Requirements
• Software interfaces
• Communications interfaces with
other systems
• File export formats
 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
 IEEE 830-1998 Standard for SRS
• Title
• Table of Contents •Describe purpose of the system
•Describe intended audience
• 1. Introduction
– 1.1 Purpose •What the system will and will not do

– 1.2 Scope
•Define the vocabulary of the SRS (may also be
– 1.3 Definitions. Acronyms, and Abbreviations in appendix)
– 1.4 References
•List all referenced documents and their sources SRS (may also be in appendix)
– 1.5 Overview
• 2. Overall Description
•Describe how the SRS is organized
• 3. Specific Requirements
• Appendices
• Index
• Title IEEE 830-1998 Standard – Section 2 of SRS
• Table of Contents •Present the business case and operational concept of the system
•Describe external interfaces: system, user, hardware, software, communication
• 1. Introduction •Describe constraints: memory, operational, site adaptation

• 2. Overall Description
– 2.1 Product Perspective •Summarize the major functional capabilities
– 2.2 Product Functions
– 2.3 User Characteristics •Describe technical skills of each user class
– 2.4 Constraints
– 2.5 Assumptions and Dependencies •Describe other constraints that will limit
developer’s options; e.g., regulatory policies; target
• 3. Specific Requirements platform, database, network, development
standards requirements
• 4. Appendices
• 5. Index
• … IEEE 830-1998 Standard – Section 3 of SRS (1)
• 1. Introduction Specify software requirements in sufficient
detail so that designers can design the system and
• 2. Overall Description testers can verify whether requirements met.
• 3. Specific Requirements
– 3.1 External Interfaces State requirements that are externally perceivable by
users, operators, or externally connected systems
– 3.2 Functions
– 3.3 Performance Requirements Requirements should include, at the least, a description
– 3.4 Logical Database Requirementsof every input (stimulus) into the system, every output
(response) from the system, and all functions performed
– 3.5 Design Constraints by the system in response to an input
– 3.6 Software System Quality Attributes
– 3.7 Object Oriented Models
• 4. Appendices
• 5. Index
• …
• 1. Introduction IEEE 830-1998 Standard – Section 3 of SRS (2)
• 2. Overall Description •Detail all inputs and outputs
(complement, not duplicate, information presented in section 2)
• 3. Specific Requirements •Examples: GUI screens, file formats
– 3.1 External Interfaces
•Include detailed specifications of each use case, including
– 3.2 Functions collaboration and other diagrams useful for this purpose

– 3.3 Performance Requirements

Types of Data entities and their relationships
– 3.4 Logical Database Requirements
– 3.5 Design Constraints Standards compliance and specific software/hardware to be used

– 3.6 Software System Quality Attributes

– 3.7 Object Oriented Models •Class Diagram, State and Collaboration Diagram, Activity Diagrams etc.

• 4. Appendices
• 5. Index
 IEEE 830-1998 Standard – Templates
• Section 3 (Specific Requirements)can be organized in
several different ways based on
– Modes
– User classes
– Concepts (object/class)
– Features
– Stimuli
• SPECIFIC REQUIREMENTS Example Section 3 of SRS of
3.1 Functional Requirements Academic Administration Software
3.1.1 Subject Registration
– The subject registration requirements are concerned with functions regarding subject
registration which includes students selecting, adding, dropping, and changing a subject.
• F-001:
– The system shall allow a student to register a subject.
• F-002:
– It shall allow a student to drop a course.
• F-003:
– It shall support checking how many students have already registered for a course.
 Design Constraints (3.2)
• 3.2 Design Constraints
• C-001:
– AAS shall provide user interface through standard web browsers.
• C-002:
– AAS shall use an open source RDBMS such as Postgres SQL.
• C-003:
– AAS shall be developed using the JAVA programming language

43
 Non-functional requirements
• 3.3 Non-Functional Requirements
• N-001:
– AAS shall respond to query in less than 5 seconds.
• N-002:
– AAS shall operate with zero down time.
• N-003:
– AAS shall allow upto 100 users to remotely connect to the system.
• N-004:
– The system will be accompanied by a well-written user manual.
 Functional Requirements
• It is desirable to consider every system as:
– Performing a set of functions {fi}.
• Each function fi considered as:
– Transforming a set of input data to corresponding
output data. Input Data
fi
Output Data
 Example: Functional Requirement
• F1: Search Book
Author Book Details
– Input: Name f1
• an author’s name:
– Output:
• details of the author’s books and the locations of these books
in the library.
• Functional requirements describe:
Functional
– A set of high-level requirements 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 sub-functions
• For each high-level requirement: Functional
Requirements
– A function is described in terms of:
•Input data set
•Output data set
•Processing required to obtain the output data set from
the input data set.
• A high-level function is one: Is it a Functional Requirement?
– 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 functional requirement?
• 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.
• A use case is a term in UML: Use Cases
– Represents a high level functional requirement.
• Use case representation is more well-defined and has
agreed documentation:
– Compared to a high-level functional requirement and its
documentation
– Therefore many organizations document the functional requirements in
terms of use cases