Requirement Analysis

© G. Antoniol 1998 Requirement Analysis 1

Requirement Analysis

... what the customer requires from a software system ...


Contents

Provide a justification. Specify requirements desired properties. Discuss:

problems

solutions


Requirements

It is very difficult to formulate a complete and consistent requirements specification

A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader

The requirements document is a description for customers and developers


Requirements Errors

Requirements errors are usually very expensive to correct after system delivery

Reviews involving client and contractor staff are used to validate the system requirements

Stable requirements are related to core activities of the customer for the software

Volatile requirements are dependent on the context of use of the system


A Requirement ... ?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification

This is inevitable as requirements may serve a dual function• May be the basis for a bid for a contract - therefore must be open

to interpretation

• May be the basis for the contract itself - therefore must be defined in detail

• Both these statements may be called requirements


IEEE a Requirement Definition

A condition of capability needed by the user to solve a problem or achieve an objective

A condition or capability that must be meet or possessed by a system ... to satisfy a contract, standard, specification, or other formally imposed document


Requirement Analysis

For large system is the most difficult and intractable activity

It is an error prone activity It is probably the software engineering weakest

and critical area Requirements analysis produce among others the

Software Requirements Specification (SRS)


Requirement Engineering

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed

Requirements may be functional or non-functional • Functional requirements describe system services or functions

• Non-functional requirements is a constraint on the system or on the development process


Requirements analysis

Sometimes called requirements elicitation or requirements discovery

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints

May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders


Why so Difficult?

A project is initiated by clients needs ! There is no formal document describing the

clients needs ! The document describing clients need is the result

of the analysis !

requirement analyst has to identify the

requirements by talking to people !


Large Systems

Most large software systems address difficult problems

Problems which are so complex that they can never be fully understood and where understanding develops during the system development

Therefore, requirements are normally both incomplete and inconsistent


Why Inconsistency ?

Large software systems must improve the current situation. It is hard to anticipate the effects that the new system will have on the organization

Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements

System end-users and organizations who pay for the system have different requirements

Prototyping is often required to clarify requirements


Requirement Analysis Problems

Stakeholders don’t know what they really want Stakeholders express requirements in their own

terms Different stakeholders may have conflicting

requirements Organizational and political factors may influence

the system requirements The requirements change during the analysis

process. New stakeholders may emerge


Requirement Analysis Problems

Clients usually do not understand software or software development processes

Developers do not understand clients’ problem or application area

SRS is a medium through which users and clients needs are specified

A good SRS should satisfy ALL the PARTIES ... which is very hard to achieve ...


Activity

Requirements analysis aims to specify what some people have in their minds

The input to this activity is

incomplete

informal

imprecise

and may also inconsistent


Product

The output of the requirement analysis is a set of requirements, hopefully: complete unambiguous consistent

Requirements analysis produce the Software Requirements Specification (SRS)


SRS

The objective of SRS is to specify what is needed from the system not howthe system will provide it!

... unfortunately, how at one level my be what at lower level ...

SRS must give enough detail to allow developers to actually build andtest the system


SRS Properties

An SRS establishes the basis for agreement between the client and the supplier on what the software product will do.

An SRS provide reference for validation of final product.

A high-quality SRS is a prerequisite to high quality software.

A high-quality SRS reduce development costs.


Errors Cost

It had been discovered that in some project 54 % of the errors were detected afterunit testing and that 45 % of this errors were actually originated during earlystages i.e., 25 % of the error occurs during requirement and early design stages

Phase Cost(person-hours)

Requirements 2

Design 5

Coding 15

Acceptance Test 50

Operation/Maint. 150


Definition/Specification

Requirements definition• A statement in natural language plus diagrams of the services the

system provides and its operational constraints. Written for customers

Requirements specification• A structured document setting out detailed descriptions of the

system services. Written as a contract between client and contractor

Software specification• A detailed software description which can serve as a basis for a

design or implementation. Written for developers


Definition/Specification

Requirements definition• Customer-Oriented descriptions of the system’s functions and

constraints on its operation

Requirements specification• Precise and detailed descriptions of the system’s functionality and

constraints. Intended to communicate what is required to system developers and serve as the basis of a contract for the system development


Requirement Reader

RequirementsDefinition

Client managersSystem end-usersClient engineerContractor managersSystem architect

RequirementsSpecification

System end-usersClient engineersSystem architectSoftware developers


Definition

Definition

The software must provide a means of representing and accessing external files created by other tools.


Specification

Specification

1.1 The user should be provided with facility to define the type of external files.1.2 Each external files type may have an associated tool which may be applied to the file1.3 Each external files type may be represented as a specific icon on the user’s display.1.4 Facilities should be provided for the icon representing an external file type to be defined by the user1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the external file type to the file represented by the selected icon.


Requirement Engineering Process

Feasibility study• Find out if the current user needs be satisfied given the available

technology and budget?

Requirements analysis• Find out what system stakeholders require from the system

Requirements definition• Define the requirements in a form understandable to the customer

Requirements specification• Define the requirements in detail


Requirement Process

Classification

RequirementCollection

DomainUnderstanding

RequirementValidation

ProcessEntry

Prioritization

ConflictResolution

Requirementsdefinition andspecification


Process Activities

Domain understanding Requirements collection Classification Conflict resolution Prioritization Requirements validation


Analysis Issues

Obtain the needed information ...

may be you are not really welcome ... after

all knowledge is power ...

Organize the obtained information ...

a huge amount of unstructured information

barely ever let you to check consistency ...


Analysis Issues

Resolving contradictions ...

you probably must mediate between

conflicting requirements or user needs or ... Focus on what and avoid to mix requirement and

design


Analysis Partition

Divide et impera: divide the problem into sub problems

Partition with respect to:

objects

functions


Objects/Functions

Objects: entities in the real world with clear, defined

boundaries and independent existence (sensors, bill, managers).

Functions: a task, service, process or activity that is

now performed in the real world and it has to be performed by the system.


Analysis Approaches

Informal:

a series of meetings between users/clients

and analysts serve to prepare SRS.

Structured:

function or object based decompositions are

used while modeling the problem.


Requirement Specification

DFD, OO models, use cases focus on problem structure

User interface are not modeled Error situation, log messages are not modeled Performance, design and recovery constraints are

not specified


Methodology

Data Flow Diagram (DFD)

Object Oriented Modeling (OO)

Use cases

There are many other methodology e.g., Entity-Relationship (ER)or Structured Analysis and Design Technique (SADT)


DFD

DFD is a graph showing how data flow through the system.

A data from an input undergoes, possibly, many transformations before reaching an output.

DFDs capture, represent data transformations. DFD constituents:

data, processes, input sources, output sinks

and arrows to represent the flow


DFD Notation

Process

Sink or source

External files

And operator

Or operator

Notice each edge must have a label !!!!

MyFile

*

+

Worker

PayInvoice

A transformer, an activity

An external entity

A repository

A A data item or a collectionof data item, arrow representsflow direction


Teller Machine

Customer

GetAccount

Customers Accounts

PIN

Balance

Positive Balance

Withdrawalamount

*

Check

Amount

Amountdue

Update

Account

New balance

Receipt

Amount

IssueMoney

Money


DFD Drawing Strategy

Identify major inputs and outputs (ignore errors first!)

Start from input and work towards output identifying major transformations

Or viceversa start from output and ... Start from high level DFD with few

transformation and go into more detailed DFD Try more than one DFD before settling one


Data Dictionary

It is the repository of various data flows Notation is similar to regular expressions:

+ sequence or composition

| selection, or

* one or more occurrences


Data Dictionary Example

Balance = user name + user account + user id + current balance

Withdrawal amount = [50000|100000|150000|200000|250000]+user id

New balance = user name + user account + user id + [current balance]*

PIN = digit + digit + digit + digit + digit


DFD Common Errors

Unlabeled data flow Missing data flow: information required by a

process is not available Extraneous data flow: some information is not

being used in the process Consistency not maintained during refinement Missing processes Contain some control information


DFD Structured Methodology

Each system is characterized as a transformation function operating with the environment transforming environment inputs into environment output.

Track the flow of data through the system


Methodology Steps

Study the “physical environment”, draw a DFD of the current (may be partially automated) system

Draw the logical equivalents of the DFD for the physical system i.e., change John_office_pay into issue_check

Draw a logical model and DFD for the new system with no separation between processes automated and not

Establish a man machine boundary i.e., specify what will be automated


Requirements Document

The requirements document is the official statement of what is required of the system developers

Should include both a definition and a specification of requirements

It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it


Requirements Rationale

It is important to provide rationale with requirements

This helps the developer understand the application domain and why the requirement is stated in its current form

Particularly important when requirements have to be changed. The availability of rationale reduces the chances that change will have unexpected effects


Requirement Traceability

Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source

Traceability is a property of a requirements specification which reflects the ease of finding related requirements

Notice that we must be able to trace requirements into design elements, into code, into test cases ...


Traceability Type

Requirements-sources traceability: links the requirement and the people, documents which specified the requirement (e.g., customer, incident report, quality standard, international regulations)

Requirements-rationale traceability: why the requirement has been specified

Requirements-requirements traceability: links a requirement with other requirements, which are in some way dependent on them.


Traceability Type Continue

Requirements-architecture traceability: links requirements with sub-systems where these requirements are implemented i.e., who is going to develop what.

Requirements-design traceability: links requirements with specific components in the system which are used to implement them

Requirements-interface traceability: links requirements with interfaces of external systems which are used in the provision of the requirements.


Traceability Technique

Assign a unique number to all requirements Cross-reference related requirements using this

unique number Produce a cross-reference matrix for each

requirements document showing related requirements. Several matrices may be necessary for different types of relationship


Requirements Document Requirements

Specify external system behavior Specify implementation constraints Easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the

system i.e. predict changes Characterize responses to unexpected events


Writing Requirements

Natural language, supplemented by diagrams and tables is the normal way of writing requirements definitions

This is universally understandable but three types of problem can arise• Lack of clarity. Precision is difficult without making the

document difficult to read• Requirements confusion. Functional and non-functional

requirements tend to be mixed-up• Requirements amalgamation. Several different requirements may

be expressed together


SRS Components

Functionality Performance Design constraints External Interface


Requirement Document

Introduction Glossary System Models Functional Requirements Definition Non Functional Requirements System Evolution Requirements Specification

Sommerville


Requirements Document Structure

Introduction• Describe need for the system and how it fits with business

objectives

Glossary• Define technical terms used

System models• Define models showing system components and relationships

Functional requirements definition• Describe the services to be provided

Sommerville


Requirements Document Structure

Non-functional requirements definition• Define constraints on the system and the development process

System evolution• Define fundamental assumptions on which the system is based and

anticipated changes

Requirements specification• Detailed specification of functional requirements

Appendices• System hardware platform description• Database requirements (as an ER model perhaps)

IndexSommerville


IEEE/ANSI 830-1993

1 Introduction 2 General Description 3 Specific Requirements 4 Appendices Index

IEEE/ANSI 830-1993


IEEE/ANSI - Introduction

1 Introduction

1.1 Purpose of the requirement document

1.2 Scope of the product

1.3 Definitions, acronyms, abbreviations

1.4 References

1.5 Overview of the remainder of the

document IEEE/ANSI 830-1993


IEEE/ANSI - General Description

2 General Description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

2.5 Assumptions and dependenciesIEEE/ANSI 830-1993


Section 2 Note

2.1Perspective relationship of the product to other products,

whether or not it is part of a larger system, principal product interfaces with the external world

2.2 Product functions a general abstract description of performed

functions 2.3 User characteristics

typical characteristics of the eventual end user


IEEE/ANSI - Specific Requirements

3 Specific requirements

3.X Functional Requirements

3.Y Non functional requirements

3.Z Interface requirements

» External interface, logical database requirements,

hardware interface, user interface, etc.


Key Question

How should be actually organized Section 3 ?

Is there a way that simplify

writing/reading the document ?

Section 3 is the central part of the document


An Organization

External interfaces

Functional requirements

Performance Requirements

Design constraints

System Attributes


Specific Requirement Organization

3.1 External Interface Requirements

3.1.1 User Interface

3.1.2 Hardware Interface

3.1.3 Software Interface

3.1.4 Communication Interface


Specific Requirement Organization

3.2 Functional Requirements 3.2.1 Mode 1

» 3.2.1.1 Functional Requirement 1.1» .....» 3.2.1.n Functional Requirement 1.n

3.2.m Mode m» 3.2.m.1 Functional Requirement m.1» .....» 3.2.m.n Functional Requirement m.p


Functional Requirements - Note

For each Functional Requirement specify: required inputs

» sources, unit of measures, valid ranges, accuracy, etc.

desired outputs» destination of outputs, units of measure, range of

valid outputs, error messages, etc processing requirements

» validity checks on inputs, sequence of operations, response to abnormal situations, etc.



You must also specify:

acceptance criteria» otherwise, how can we demonstrate that the

requirement has been satisfied

This a key point: during acceptance test the user will judge your product based on acceptance criteria. During system and integration test to assess requirement coverage you must be able to measure requirements satisfaction. You must justify the absence of the acceptance criteria



You must also specify:

the list of related requirements and related

expectations

» this also helps in managing requirement changes

a list of keywords

» this also helps in managing requirement changes

a status bar ...


Status Bar

priority Required/Optional/Deleted

status Obsolete/Suspended/Draft/Final

stability Stable/Unstable/Unknown

Understanding level Understood/Obscure/Unclear


Remaining of Section 3

3.3 Performance requirements 3.4 Design constraints 3.5 Attributes 3.6 Other requirements


IEEE/ANSI - Appendices

4 Appendices

Conventions, form compilation rules


Non Functional Requirements

Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

• Product requirements• Process requirements• Organizational requirements• External requirements



Define system properties and constraints

reliability, response time and storage requirements. Constraints are I/O device capability, system

representations, etc. Process requirements:

may also be specified mandating a particular CASE system, programming language or development method.


Non Functional Classification

Product requirements• Requirements which specify that the delivered product must

behave in a particular way e.g. execution speed, reliability, etc.

Organizational requirements• Requirements which are a consequence of organizational policies

and procedures e.g. process standards used, implementation requirements, etc.

External requirements• Requirements which arise from factors which are external to the

system and its development process e.g. interoperability requirements, legislative requirements, etc.



Performancerequirements

Spacerequirements

Usabilityrequirements

Ef ficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


Example

Product requirement• all necessary communication between processes and the user must

be bases on the Extended Bytecodes character set.

Organizational requirement• deliverable documents shall conform to the process and

deliverables defined in ISO 9001 standard

External requirement• The system must be capable to connect with the EU exchange

information network by mean of a dedicated circuit.


Verifiability

Requirements should be written so that they can be objectively verified

The problem with this requirement is its use of vague terms such as ‘errors shall be minimized”

e.g. The error rate should be been quantified» Experienced waiters should be able to use all the system

functions after a total of four hours training. After this training, the average number of errors made by experienced users should not exceed five per day.


MeasuresProperty MeasureSpeed Processed transactions/second

User/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems


Measures

Property Measure

Speed Processed transactions per secUser/event rensponse timeScreen refresh time

Size Executable KbyteProcess size/Required memoryNumber of RAM chips

Ease of use Training timeNumber of help screens/frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of event causing failureProbability of data corruption onfailure

Portability Number of target systemPercentage of target dependentstatement


Requirements Separation

Functional and non-functional requirements should, in principle, be distinguished

However, this is difficult as requirements may be expressed as whole system requirements rather than constraints on individual functions

It is sometimes difficult to decide if a requirement is functional or a non-functional• e.g., requirements for safety are concerned with non-functional

properties but may require functions to be added to the system


System Requirements

Some requirements place constraints on the system as a whole rather than specific system functions

Example the time required for training a system operator to be proficient in the use of the system must not exceed 2 working days.

These may be requirements which cannot be derived from any single sub-set of the already stated requirements; a change in system requirements may be extremely expensive.


Requirements Evolution

May be user needs changed a large system to be developed requires years and the organization's objectives/needs change

Requirements always evolve as a better understanding of user needs is developed or incorrect interpretation are clarified

It is essential to plan for change in the requirements as the system is being developed and used


Requirements Evolution

Client

Needs

Initial understandingof the problem

Initialrequirements

Changed understandingof the problem

Revisedrequirements


Requirement Classes

Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy


A Classification

Mutable requirements• Requirements that change due to the system’s environment

Emergent requirements• Requirements that emerge as understanding of the system

develops

Consequential requirements• Requirements that result from the introduction of the computer

system

Compatibility requirements• Requirements that depend on other systems or organizational

processes


Requirements Changes

The requirements document should be organized so that requirements changes can be made without extensive rewriting

External references should be minimized and the document sections should be as modular as possible

Changes are easiest when the document is electronic. Lack of standards for electronic documents make this difficult


SRS characteristics

SRS should be correct complete unambiguous verifiable consistent ranked for importance or stability modifiable traceable


Correct Complete ...

Correct: every requirement represent something required in the final system

Complete: if everything it is supposed the system to do and the responses of the software to all classes of input data are specified in SRS.

Unambiguous: every requirement has exactly only one interpretation

Verifiable: if for each requirement there exist a cost effective process that can check whether or not the final software meets that requirement


Consistent ...

Consistent: if there is no requirement that conflicts with another.

Ranked: some requirement are considered more critical than others.

Modifiable:if changes to a requirement can be made easily preserving completeness and consistency.

Traceable:if the origin of the requirement is clear and can be traced to design and code.


Requirements Validation

Concerned with demonstrating that the requirements define the system that the customer really wants

Requirements error costs are high so validation is very important• Fixing a requirements error after delivery may cost up to 100

times the cost of fixing an implementation error

Prototyping is an important technique of requirements validation


Requirements Verification

Validity. Does the system provide the functions which best support the customer’s needs?

Consistency. Are there any requirements conflicts?

Completeness. Are all functions required by the customer included?

Realism. Can the requirements be implemented given available budget and technology


Requirements Reviews

Regular reviews should be held while the requirements definition is being formulated

Both client and contractor staff should be involved in reviews

Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage


Requirements Inspections

A group of people with different skills and responsibilities (4-5): an end-user a customer representative one or more domain experts one or more responsible for system design

and implementation one or more requirements engineers


Organization

Requirements are assigned to people one or more week in advance (up to 100 requirements)

People analyze/inspect requirements (up to 40 requirements per hour)

During formal meeting requirement are discussed validated and decisions/discussions/clarifications are recorded (Meeting up to 4 hours)

Checklist are exploited during meeting.


Reviews Check

Verifiability. Is the requirement realistically testable?

Comprehensibility. Is the requirement properly understood?

Traceability. Is the origin of the requirement clearly stated?

Adaptability. Can the requirement be changed without a large impact on other requirements?


Actions

Requirements clarification: badly expressed requirement or omitted information; requirement author’s rewrite the text.

Missing information: information is missing from the requirement document; requirement engineer is responsible to gather extra information.

Requirements conflict: a negotiate with the customer will remove the conflict.

Unrealistic requirement: the customer should be consulted, requirements deleted, modified i.e., make more realistic


Checklist

It should be expressed in a fairly general way

It should be understandable by end users

It should not have more than 10 items


Checklist Example

Are the requirements complete i.e., does the checker know of any missing requirements or any information missing from individual requirement descriptions?

Are the requirement consistent i.e., do the descriptions of different requirements include contradictions?

Are the requirements comprehensible i.e., can readers of the document understand what the requirement means?

Are the requirement ambiguous i.e., are there possible different interpretations of the requirements?


Checklist Example - Continue

Is the requirement document structured i.e., would an alternative structure be easier to understand? Are related requirements grouped?

Are requirements traceable i.e., are requirements unambiguously identified, do they include links to related requirements and to the reason why these requirements have been included?

Does the document in the whole and do individual requirement conform to defined standard?


Checklist Example - 1

Are all hardware resources defined? Have the response time of functions been specified? Have all the hardware, external software and data interface

been specified? Have all functions required by the client been specified? Is each requirement testable? Are all the responses to exceptional condition specified? Is the initial state of the system defined? Are possible future modification specified?


Collect Measures

Number of detected errors: omission: a user requirement was not included inconsistency: contradictions among

requirements, incompatibility with the actual customer requirements, incompatibility with the environment

incorrect fact: erroneous assumptions or incorrect requirement

ambiguity: multiple meanings


Quality Indicator

If during reviews were interpreted in the same manner and are the total number of requirements:

Qn

nuur

r

nur

nr

Requirement Analysis

Documents

Transcript of Requirement Analysis