requirement engg process

8/20/2019 Requirement engg process

1/52

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 1

Requirements Engineering

Processes


2/52


Objectives

To describe the principal requirementsengineering activities and their relationships

To introduce techniques for requirements

elicitation and analysis To describe requirements validation and the

role of requirements reviews To discuss the role of requirements

management in support of otherrequirements engineering processes


3/52


Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation

Requirements management


4/52


Requirements engineering processes

The processes used for RE vary widelydepending on the application domain, thepeople involved and the organisation

developing the requirements !owever, there are a number of generic

activities common to all processes" Requirements elicitation#

" Requirements analysis#" Requirements validation#

" Requirements management


5/52


The requirements engineering process

repo

SystmoUr

e


6/52


Requirements engineering

Requielicita

SysterequielicitsespeUsereq

eliciBusispePrFeastR

S semdoc


7/52©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 7

Feasibility studies

$ feasibility study decides whether or not the

proposed system is worthwhile

$ short focused study that chec%s

" &f the system contributes to organisational

objectives#

" &f the system can be engineered using current

technology and within budget#

" &f the system can be integrated with other

systems that are used


8/52



Elicitation and analysis

.ometimes called requirements elicitation or

requirements discovery

&nvolves technical staff wor%ing with customers to

find out about the application domain, the servicesthat the system should provide and the systems

operational constraints

/ay involve end0users, managers, engineers

involved in maintenance, domain e1perts, trade

unions, etc These are called stakeholders.



Problems of requirements analysis

.ta%eholders dont %now what they really want

.ta%eholders e1press requirements in their own

terms

2ifferent sta%eholders may have conflictingrequirements

Organisational and political factors may influence the

system requirements

The requirements change during the analysisprocess 3ew sta%eholders may emerge and the

business environment change



The requirements spiral

ReqclasorgaRpnRd

Reqdisc



Process activities

Requirements discovery" &nteracting with sta%eholders to discover their requirements

2omain requirements are also discovered at this stage

Requirements classification and organisation

" 4roups related requirements and organises them intocoherent clusters

Prioritisation and negotiation" Prioritising requirements and resolving requirements

conflicts

Requirements documentation" Requirements are documented and input into the ne1t

round of the spiral



Requirements discovery

The process of gathering information about

the proposed and e1isting systems and

distilling the user and system requirements

from this information .ources of information include

documentation, system sta%eholders and the

specifications of similar systems



$T/ sta%eholders

'an% customers Representatives of other ban%s 'an% managers

5ounter staff 2atabase administrators .ecurity managers /ar%eting department

!ardware and software maintenance engineers 'an%ing regulators



6iewpoints

6iewpoints are a way of structuring the

requirements to represent the perspectives

of different sta%eholders .ta%eholders may

be classified under different viewpoints This multi0perspective analysis is important

as there is no single correct way to analyse

system requirements



Types of viewpoint

&nteractor viewpoints" People or other systems that interact directly with the

system &n an $T/, the customers and the accountdatabase are interactor 6Ps

&ndirect viewpoints" .ta%eholders who do not use the system themselves but

who influence the requirements &n an $T/, managementand security staff are indirect viewpoints

2omain viewpoints

" 2omain characteristics and constraints that influence therequirements &n an $T/, an e1ample would be standardsfor inter0ban% communications



6iewpoint identification

&dentify viewpoints using" Providers and receivers of system services#

" .ystems that interact directly with the system

being specified#" Regulations and standards#

" .ources of business and non0functionalrequirements

"Engineers who have to develop and maintainthe system#

" /ar%eting and other business viewpoints


18/52


7&'.8. viewpoint hierarchy

ArticleproviFinanLibrarmanagLibstUse U!st

%&tSta Stude#Ssm


19/52


&nterviewing

&n formal or informal interviewing, the REteam puts questions to sta%eholders aboutthe system that they use and the system to

be developed There are two types of interview

" 5losed interviews where a pre0defined set ofquestions are answered

" Open interviews where there is no pre0definedagenda and a range of issues are e1plored withsta%eholders


20/52


&nterviews in practice

3ormally a mi1 of closed and open0endedinterviewing

&nterviews are good for getting an overallunderstanding of what sta%eholders do and how

they might interact with the system &nterviews are not good for understanding domain

requirements" Requirements engineers cannot understand specific

domain terminology#

" .ome domain %nowledge is so familiar that people find ithard to articulate or thin% that it isnt worth articulating


21/52


Effective interviewers

&nterviewers should be open0minded, willing

to listen to sta%eholders and should not have

pre0conceived ideas about the requirements

They should prompt the interviewee with aquestion or a proposal and should not simply

e1pect them to respond to a question such

as 9what do you want


22/52


.cenarios

.cenarios are real0life e1amples of how a

system can be used

They should include

" $ description of the starting situation#

" $ description of the normal flow of events#

" $ description of what can go wrong#

" &nformation about other concurrent activities#" $ description of the state when the scenario

finishes


23/52


7&'.8. scenario (:)

Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing

the copy of the article.

Normal: The user selects the article to be copied. He or she is then prompted by the system to ei ther

provide subscriber information for the journal or to indicate ho they ill pay for the article. !lternative

payment methods are by credit card or by "uoting an organisational account number.

The user is then as#ed to fill in a copyright form that maintains details of the transaction and they then

submit this to the LIBSYS system.

The copyright form is c hec#ed and$ if %&$ the '() version of the article is donloaded to the LIBSYS

or#ing area on the user*s computer and the user is informed that it is available. The user is as#ed to select

a printer and a copy of the article is printed. If the article has been flagged as +print,only* it is deleted from

the user*s system once the user has confirmed that printing is complete.


24/52


7&'.8. scenario (;)

What can go wrong: The user may fail to fill in the copyright form correctly. In this case$ the form should

be re,presented to the user for correction. If the resubmitted form is s till incorrect then the user*s re"uest

for the article is rejected.

The payment may be rejected by the system. The user*s re"uest for the article is rejected.

The article donload may fail. -etry until successful or the user terminates the session.

It may not be possible to print the article. If the article is not flagged as +print,only* then it is held in the

LIBSYS or#space. %therise$ the article is deleted and the user*s account credited ith the cost of the

article.

Other activities: Simultaneous donloads of other articles.

System state on completion: ser is logged on. The donloaded article has been deleted from LIBSYS

or#space if it has been flagged as print,only.


25/52



26/52


$rticle printing use0case


27/52


7&'.8. use cases

tUSu#LUs


28/52


$rticle printing

requcoreqreturcopdeliarticprinscin-odelet


29/52


Print article sequence

requcoreqreturcopdeliarticprinscin-odelet


30/52


.ocial and organisational factors

.oftware systems are used in a social and

organisational conte1t This can influence or

even dominate the system requirements

.ocial and organisational factors are not asingle viewpoint but are influences on all

viewpoints

4ood analysts must be sensitive to thesefactors but currently no systematic way to

tac%le their analysis


31/52


Ethnography

$ social scientists spends a considerable time

observing and analysing how people actually wor%

People do not have to e1plain or articulate their

wor% .ocial and organisational factors of importance may

be observed

Ethnographic studies have shown that wor% is

usually richer and more comple1 than suggested bysimple system models


32/52


Focused ethnography

2eveloped in a project studying the air trafficcontrol process

5ombines ethnography with prototyping

Prototype development results in unansweredquestions which focus the ethnographicanalysis

The problem with ethnography is that it studies

e1isting practices which may have somehistorical basis which is no longer relevant


33/52


Ethnography and prototyping


34/52


.cope of ethnography

Requirements that are derived from the way

that people actually wor% rather than the way

& which process definitions suggest that they

ought to wor% Requirements that are derived from

cooperation and awareness of other peoples

activities


35/52


Requirements validation

5oncerned with demonstrating that the

requirements define the system that the

customer really wants

Requirements error costs are high sovalidation is very important

" Fi1ing a requirements error after delivery may

cost up to :== times the cost of fi1ing an

implementation error


36/52


Requirements chec%ing

6alidity 2oes the system provide the functions

which best support the customers needs-

5onsistency $re there any requirements conflicts-

5ompleteness $re all functions required by thecustomer included-

Realism 5an the requirements be implemented

given available budget and technology

6erifiability 5an the requirements be chec%ed-


37/52


Requirements validation techniques

Requirements reviews" .ystematic manual analysis of the

requirements

Prototyping"

Test0case generation

" 2eveloping tests for requirements to chec%testability


38/52


Requirements reviews

Regular reviews should be held while the

requirements definition is being formulated

'oth client and contractor staff should be

involved in reviews Reviews may be formal (with completed

documents) or informal 4ood

communications between developers,customers and users can resolve problems

at an early stage


39/52


Review chec%s

6erifiability &s the requirement realisticallytestable-

5omprehensibility &s the requirement

properly understood- Traceability &s the origin of the requirement

clearly stated- $daptability 5an the requirement be

changed without a large impact on otherrequirements-


40/52


Requirements management

Requirements management is the process of

managing changing requirements during the

requirements engineering process and system

development

Requirements are inevitably incomplete and

inconsistent

" 3ew requirements emerge during the process as

business needs change and a better understanding of the

system is developed#" 2ifferent viewpoints have different requirements and

these are often contradictory


41/52


Requirements change

The priority of requirements from different

viewpoints changes during the development

process

.ystem customers may specify requirementsfrom a business perspective that conflict with

end0user requirements

The business and technical environment ofthe system changes during its development


42/52


Requirements evolution

rreqe


43/52


Enduring and volatile requirements

Enduring requirements .table requirements

derived from the core activity of the customer

organisation Eg a hospital will always have

doctors, nurses, etc /ay be derived fromdomain models

6olatile requirements Requirements which

change during development or when the

system is in use &n a hospital, requirements

derived from health0care policy


44/52


45/52


Requirements management planning

2uring the requirements engineering process, youhave to plan?" Requirements identification

" !ow requirements are individually identified#

" $ change management process" The process followed when analysing a requirements

change#

" Traceability policies" The amount of information about requirements relationships

that is maintained#

" 5$.E tool support" The tool support required to help manage requirements

change#


46/52


Traceability

Traceability is concerned with the relationships

between requirements, their sources and the system

design

.ource traceability

" 7in%s from requirements to sta%eholders who proposed

these requirements#

Requirements traceability

" 7in%s between dependent requirements#

2esign traceability

" 7in%s from the requirements to the design#


47/52


48/52


5$.E tool support

Requirements storage

" Requirements should be managed in a secure, managed

data store

5hange management

" The process of change management is a wor%flow

process whose stages can be defined and information

flow between these stages partially automated

Traceability management

" $utomated retrieval of the lin%s between requirements


49/52


Requirements change management

.hould apply to all proposed changes to therequirements

Principal stages

" Problem analysis 2iscuss requirementsproblem and propose change#

" 5hange analysis and costing $ssess effects ofchange on other requirements#

" 5hange implementation /odify requirementsdocument and other documents to reflectchange


50/52


5hange management


51/52


@ey points

The requirements engineering processincludes a feasibility study, requirementselicitation and analysis, requirementsspecification and requirements management

Requirements elicitation and analysis isiterative involving domain understanding,requirements collection, classification,structuring, prioritisation and validation

.ystems have multiple sta%eholders withdifferent requirements


52/52

@ey points

.ocial and organisation factors influencesystem requirements

Requirements validation is concerned with

chec%s for validity, consistency,completeness, realism and verifiability 'usiness changes inevitably lead to

changing requirements

Requirements management includesplanning and change management

requirement engg process

Documents