Requirement Analysis

Requirements Analysis & Specification

Objective: determine what the system must do to solve the

problem (without describing how)

Done by Analyst (also called Requirements Analyst)

Produce Software Requirements Specifications (SRS)

document

Incorrect, incomplete, inconsistent, ambiguous SRS often

cause for project failures and disputes

Challenges of Requirement Analysis Lack of stakeholder involvement

Stakeholders may not know exactly what is needed

Users change their mind over time

Different stakeholders may have conflicting requirements

Stakeholders may not be able to differentiate between

what is possible and cost-effective against what is

impractical

Analyst has no or limited domain knowledge

Often client is different from the users

Cost of Delay in Fixing

Requirements Errors

0

50

100

150

200

Cost to fix

Reqts. definition

Design

Coding

Unit testing

Post-delivery

Data: Boehm & Papaccio (1988)

IEEE Trans. Software Eng.

Nominal

unit cost20-fold increase

during devt.

200-fold increase

after delivery

What is a requirement

IEEE defines a requirement as

[1] “A condition or capability needed by a user to

solve a problem to achieve an objective.”

[2] A condition or a capability that must be met or

possessed by a system, to satisfy a contract,

standard , specification or other formally

composed document.”

Types of Requirements

Functional Requirements

Nonfunctional Requirements

Functional Requirements

IEEE defines functional requirements as function

that a system or a component must be able to

perform

Example

The system should allow the students to check their

marks.

The system should allow the user to sort the list of

available books by title.

Non-functional Requirements

Non-functional requirements define the overall qualities

or attributes of the resulting system.

These are constraints on the services or functions

offered by the system

Example

The response time of the home page must not exceed

five seconds

Types of non-functional requirements

Performance (recovery time, resource usage, throughput,

response time)

All webpage must download within three seconds during an

average load and five seconds during a peak load

Usability (human factors ,aesthetics, consistency in the user

interface , online and context-sensitive help , wizards ,user

documentation, training materials )

The end user shall be able to place an order within thirty

seconds.

Types of non-functional requirements

(cont..)

Reliability (frequency and severity of failure, recoverability ,

accuracy, mean time between failure, availability)

The mean time to failure shall be at least four months

Security (access permission , integrity)

The access permissions for system data may only be changed by the

system’s data administrator

Supportability (adaptability, maintainability, configurability,

serviceability, portability)

The system shall allow users to create new workflows without the need

for additional programming.

Types of non-functional requirements

(cont..)

Technical requirements (related to environment, hardware

or software)

The system shall work on a system with 256MB memory.

Classification of non functional requirements

Product Requirements

Process Requirements

External Requirements

Classification of non functional requirements Non-functional

requirements

Process

requirements

Product requirements External

requirements

Delivery

requirements

implementation

requirements

standards

requirements

Usability requirements

Reliability requirements

Safety requirements

Efficiency requirements

Performance requirements

Capacity requirements

Legal

constraints

Economic

constraints

Interoperability

requirements

Example (cont..)

Standard Requirement

The Software requirements specification should follow

IEEE format.

Legal constraints

Pirated software should not be sold

Requirement Engineering

Requirements engineering is a systematic approach to elicit,

organize and document the requirements in a form and manner

that forms the basis for design and development of the software.

Requirements engineering involves all lifecycle activities devoted

to identification of user requirements, analysis of the

requirements to derive additional requirements, documentation of

the requirements as a specification and validation of the

documented requirements against user needs, as well as

processes that support these activities

RE process activities

Requirements elicitation

Requirements analysis

Requirements specification

Requirements Validation

Requirements management

Requirements Elicitation

Requirements Elicitation is the process of discovering the

requirements for a system through consultation with

stakeholders.

Prepare for Requirements Gathering

Gain common agreement on the problem definition.

Identify users and other stakeholders

Understand the domain

Identify the solution boundaries

Identify the constraints to be imposed on the solution

Tools for eliciting requirements

Interviews

Questionnaires

Focus Groups

Observations

Studying Documents

Scenarios

Prototypes

Scenario-Example Scenario: A successful withdrawal attempt at an automated teller

machine (ATM). John Smith presses the “Withdraw Funds” button The ATM displays the preset withdrawal amounts ($20, $40, …) John chooses the option to specify the amount of the withdrawal The ATM displays an input field for the withdrawal amount John indicates that he wishes to withdraw $50 dollars The ATM displays a list of John’s accounts, a checking and two

savings accounts John chooses his checking account The ATM verifies that the amount may be withdrawn from his

account The ATM verifies that there is at least $50 available to be disbursed

from the machine The ATM debits John’s account by $50 The ATM disburses $50 in cash The ATM displays the “Do you wish to print a receipt” options John indicates “Yes” The ATM prints the receipt

Requirements Analysis

Analysis is refinement of stakeholder needs into formal

product specification.

The goal of analysis is to discover problems,

incompleteness and inconsistencies in the elicited

requirements.

Requirements analysis involves refining, analyzing and

scrutinizing the gathered requirements to make sure all

stakeholders understand what they mean and to find

errors, omissions or other deficiencies.

Analysis Checks

Necessity Checking

Does the requirement contribute to the the problem

addressed

Consistency checking

Does the requirements contradict?

Completeness checking

Does any services or constraints which are needed are missed

out?

Feasibility Checking

Is it feasible in the context of the budget and schedule?

Requirements Analysis (contd..)

Issues identified are communicated back to the

relevant stakeholders and resolved through

negotiation

Models may be created during analysis to better

understand the problem to be solved

Requirements are prioritized in consultation with

the stakeholders

Modelling

Models are created to gain a better understanding of the

actual entity or object to be built

During requirements analysis models of the system are

built. These models focus on what the system must do, not

on how it does it

Data Flow Diagram

Very popular tool for describing the functions of a system in

terms of processes and data used by them

Structured Analysis

Focuses on functions/processes and data flowing between them

Uses top-down decomposition approach

Initially see the application as a single process and identify inputs, outputs, users and data sources

Decompose the process into sub processes, show data flows for them

Function Decomposition and Data Flow Diagrams (FDD, DFD) very useful

2.1

Billchecksform

2.1

Validatesalesorder

AZ104 formchecked AZ104 form

sales order

valid sales order

Master File

Sales orders

Physical to Logical DFDs

Structured Methodology

Study existing system: What is done and how

Prepare physical current DFD

Convert this DFD to logical DFD

Remove physical implementation-specific details

Define boundary for automation (scope)

Prepare DFD for proposed system - requires innovation, experience, vision

Incorporate new needs

Improve work flows (BPR: business process re-engg)

Introduce efficiency/effectiveness

Requirements Specification

Software Requirements Specification is produced

at the culmination of the analysis task.

Software Requirements Specification

A document that clearly and precisely describes each of

the essential requirements (functions, performance,

design, constraints , and quality attributes) of the

software and the external interfaces. Each requirement

is defined in such a way that its achievement can be

objectively verified by a prescribed method , for

example, inspection, demonstration, analysis or test.’

[IEEE]

Benefits of SRS

SRS document is a contract between the

development team and the customer

Reduce the development effort

Provide a basis for estimating costs and schedules

Provide a baseline for validation and verification.

A high-quality SRS is a prerequisite for high quality

software

Serve as a basis for enhancement

Characteristics of SRS

Correct

Unambiguous

Complete

Consistent

Ranked for Importance /stability

Verifiable

Modifiable

Traceable

Correct

An SRS is correct if and only if every requirement

stated therein is the one that the software shall

meet.

Unambiguous

An SRS is unambiguous if and only if every

requirement stated therein has only one

interpretation

Example of an ambiguous requirement

All customers have the same control field .

a) All customers have the same value in their control fields.

b) All customers’ control field have the same format.

c) One control field is issued for all customers.

Complete

All significant requirements are included.

Definition of responses of the SW to all realizable

classes of input data in all situations.

Conformity to a standard.

Full labeling and referencing of all figures, tables etc.

and definition of all terms and units of measure

No sections are marked “To Be Determined ”(TBD)

Consistent

No two requirements are in conflict

Conflicting terms

Example

Prompt is used in one requirement while cue is used by another

requirement to denote a message a user input data

Conflicting characteristics

Example

One requirement might state the format on the output report as

tabular , but another as textual

Temporal or logical inconsistency

Example

One requirement may state that A will occur before B and another

requirement may state that A will occur 15 seconds after the start of

system B.

Ranked for Importance /stability

Each requirements in the SRS should be

identified to make their differences clear and

explicit

Verifiable

A requirement is verifiable if and only if there

exists some finite cost effective process with

which a person or machine can check that the

SW meets the requirement

Example

The product should work well ---non-verifiable

The output of the program shall usually be given within10

seconds--- verifiable

Modifiable

Structure and style of SRS is such that changes

to requirements can be made easily, completely

and consistently.

SRS organization -- table of contents, index,

explicit cross-referencing

no redundancy

Traceable

An SRS is traceable if the origin of each

requirement is clear and it facilitates the

referencing of each requirement in future.

Backward traceability

Forward traceability

Problems with an Unstructured Specification

It would be very difficult to understand that

document.

It would be very difficult to modify that document.

Conceptual integrity in that document would not be

shown.

The SRS document might be ambiguous and

inconsistent.

Requirement Specification Format

(Based on IEEE Recommendation)

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms and Abbreviations

1.4 References

1.5 Overview

1.1 Purpose

Describe the purpose of the particular SRS and

its intended audience

1.2 Scope

Identify the software product(s) to be produced

by name.

Explain what the software product(s) will , and if

necessary, will not do.

Describe the application of the software being

specified including relevant benefits, objectives

and goals.

1.3 Definitions, Acronyms and Abbreviations

Provide the definitions of all terms , acronyms

and abbreviations required to properly interpret

the SRS

1.4 References

Provide a complete list of documents referenced

elsewhere in the SRS

1.5 Overview

Describe what the rest of the SRS contains

Explain how the SRS is organized

2. General Description

2.1 Product Perspective

2.2 Product Functions Overview:

2.3 User Characteristics:

2.4 General Constraints:

2.5 Assumptions and Dependencies

2.1 Product Perspective

Put the product into perspective with other

related products, defining if the product is

independent or is a part of a larger product.

Describes the relationship with other products

and principle interfaces

2.2 Product Functions

General overview of tasks; including data flow

diagrams

2.3 User Characteristics

Describe the general characteristics of the

intended users of the product including

educational level, experience and technical

expertise

2.4 General Constraints

About schedule, resources, cost, etc.

2.5 Assumptions and Dependencies

List any factors that affect the

requirements stated in the SRS

3. Specific Requirements

3.1 External Interface Requirements

3.2 Functional Requirements

3.3 Performance Requirements

3.4 Design Constraints

3.5 Software Requirement Attributes

3.6 Other Requirements

3.1 External Interface Requirements

User Interfaces

Hardware Interfaces

Software Interfaces

Communication Interfaces

3.2FUNCTIONAL REQUIREMENT

3.2.1 Introduction

3.2.2 Inputs

3.2.3 Processing

3.2.4 Outputs

3.2….. (Repeat Similarly For Each Function)

3.3 Performance Requirements

Capacity requirements (no of users, no of files),

response time, through-put (in measurable

terms)

3.4 Design Constraints

Standards Compliance

Hardware Limitations

3.5 Software Requirement Attributes

Reliability

Availability

Security

Maintainability

Portability

3.6 Other Requirements

Possible future extensions

Appendix

Glossary

Analysis Models

Note:

All sections are not required for all projects.

Requirements Validation

Checks the requirements to certify that the requirements document is an acceptable description of the system to be implemented.

Requirements Validation

Requirements review is the most common

method of validation.

Requirements review process A group of people read and analyise the requirements, look for problems ,

meet and discuss the problems and agree on actions to address these problems

Plan review The review team is selected and a time and place for the review meeting is

chosen

Distribute documents The requirements document is distributed to the review team members

Prepare for review Individual reviewers read the requirements to find conflict , omissions,

inconsistencies, deviations from standards and other problems.

Hold review meeting Individual comments and problems are discussed and a set of actions to address

the problem is agreed.

Follow-up actions The chair of the review checks that the agreed actions have been carried out.

Revise document The requirements document is revised to reflect the agreed actions. At this stage

it may be accepted or it may be re-reviewd.

Requirements review checklist

Understand ability- Can readers of the document understand what the requirements mean

Redundancy- Is information unnecessarily repeated in the requirements document

Completeness –is there any information missing from individual requirements description

Ambiguity –are the requirements expressed using terms which are clearly defined

Organization – Is the document structured in a sensible way

Consistency –Do the description of different requirements include contradictions

Conformance to standards-

Traceability

Requirements review – problem actions

Requirements clarification The requirements may be badly expressed

May have accidentally omitted information

Missing information Some information is missing from the requirements document

Must be provided by system stakeholders

Requirements conflict The stakeholders involved must negotiate to resolve the

conflict

Unrealistic requirements The requirements does not appear to be implemen able with

the technology available or given other constraints on the system

Stakeholders must be consulted to decide how to make the requirements more realistic.

Analysis vs Validation

Analysis works with raw requirements as elicited from the system stakeholders.

Usually incomplete and expressed in an informal and unstructured way

Incorporation of stakeholder is important

“Have we got the right requirements”

Validation works with a final draft of the requirements document , i.e. with negotiated and agreed requirements.

All known incompleteness and inconsistency are removed

Validation process is more concerned with the way the in which the requirements are described

Stakeholders are not necessarily important

“Have we got the requirements right”