Ch 7 Requirements Engineering Processes

8/2/2019 Ch 7 Requirements Engineering Processes

1/54

1

Chapter 7

Requirements Engineering Processes

Haya Sammaneh


2/54


3/54

3

Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validationRequirements management


4/54

4

Requirements Engineering processes

The processes used for RE vary widely depending

on the application domain, the people involvedand the organization developing the requirements

However, there are a number ofgeneric activitiescommon to all processes

Feasibility study

Requirements elicitation and analysis

requirements specification and systemmodeling.

Requirements validation

Requirements management


5/54

5

The requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and system

requirements

Requirements

document


6/54

6

The Spiral model of requirementsengineering Process

Requirements

specification

Requirements

validation

Requirementselicitation

System requirements

specification andmodeling

System

requirementselicitation

User requirementsspecification

Userrequirements

elicitation

Business requirementsspecification

Prototyping

Feasibility

study

Reviews

System requirementsdocument


7/54

7

7.1Feasibility studies

A feasibility study decides whether or not the proposedsystem is worthwhile

A short focused study that checks If the system contributes to organizational objectives

If the system can be engineered using current technology

and within budget

If the system can be integrated with other systems thatare used


8/54

8

Feasibility study implementation

Based on information assessment , informationcollection and report writing

Questions for people in the organization

What if the system wasnt implemented?

What are current process problems?

How will the proposed system help?

What will be the integration problems? Is new technology needed?

What facilities must be supported by the proposedsystem?


9/54

9

7.2Requirements Elicitation (discovery)

and analysis

Involvestechnical staff working with customers,the services that the system should provide and

the systems operational constraints

May involveend-users, managers, engineers

These are called stakeholders


10/54

10

Problems of requirements analysis

Stakeholders dont know what they really want

Stakeholders express requirements in theirown terms

Different stakeholders may have conflicting requirements

Organizational and politicalfactors may influence the

system requirements

The requirements change during the analysis process. Newstakeholders may emerge and the business environment

change


11/54

11

The requirements analysis process

Requirementsvalidation

Domain

understandingPrioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry


12/54

12

The requirements Analysis Spiral

Requirementsclassification and

organisation

Requirementsprioritization and

negotiation

RequirementsdocumentationRequirementsdiscovery


13/54

13

requirements analysis Process(activities

Requirements collection, interact with stakeholders, domainrequirements (understanding.

Classification and organization, organize requirement in a

structure one (coherent cluster.

Conflict resolution, resolving the conflict.

Prioritization, prioritize requirements.

Requirements checking and documentation, checking forcompletion, consistency, and in accordance with whatstakeholder really wants, then documented for the next

phase.


14/54

14

7.2.1Requirements discovery(Viewpoints, interview , scenario, use case

The process ofgathering informationabout the proposed and existing systemsand eliciting the user and system

requirements from this information.

Sources of information include

documentation, system stakeholders andthe specifications of similar systems.


15/54

15

a. Viewpoint-oriented approach

Stakeholdersrepresent different ways oflooking at a problem

Viewpoints are a way ofstructuring therequirements to represent the perspectives ofdifferent stakeholders..

This multi-perspective analysisis important asthere is no single correct way to analyzesystem requirements.


16/54

16

Example - Banking (auto-teller system ATMsystem

The example used here is an auto-teller systemwhich provides some automated banking services

we use a very simplified system which offers someservices to customers of the bank who own thesystem and a narrowerrange of services to othercustomers

Services include cash withdrawal, messagepassing (send a message to request a service,ordering a statement and transferring funds


17/54

17

Auto-tellerviewpoints

Bank customers

Representatives of other banks: allow otherATM to be used

Hardware and software maintenance engineers Marketing department

Bank managers and staff

Database administrators and security staff

Communications engineers Personnel department

Stakeholder+ domain + system can be represented as systemviewpoints


18/54

18

Types (Models of viewpoint Interactor viewpoints

People orother systems that interact directly with thesystem.

In an ATM, the customers and the account databaseare interactor VPs.

Indirect viewpoints

Stakeholders who do not use the system themselvesbut who influence the requirements.

In an ATM, managementand security staff are indirectviewpoints.

Domain viewpoints

Domain characteristics and constraints that influencethe requirements.

In an ATM, the standards for inter-bankcommunications.


19/54

19

LIBSYS viewpoint hierarchy

Article

providersFinance

Library

m anager

Library

staffU sers

InteractorIndirect

All VPs

Classificationsystem

UI

standards

Dom ain

ExternalStaffStudents CataloguersSystem

m anagers


20/54

20

Viewpoint process model

Viewpoint identification: discover viewpoints whichreceive system services and identify the servicesprovided to each viewpoint using:

Providers and receivers of system services; Systems that interact directly with the system being specified; Regulations and standards; Engineers who have to develop and maintain the system; Marketing and otherbusiness viewpoints.


21/54

21

Viewpoint process model, cont

Viewpoint structuring, group related viewpointsinto a hierarchy. Common services are providedat higher-levels in the hierarchy

Viewpoint documentation, refine the descriptionof the identified viewpoints and services

Viewpoint-system mapping, transform theanalysis to an object-oriented design


22/54

22

Viewpoint identification

Querybalance

Gettransactions

Cashwithdrawal

Transactionlog

Machinesupplies

Cardreturning

Remotesoftwareupgrade

Ordercheques

Userinterface

Accountinformation

Messagelog

Softwaresize Invalid

userSystem cost Printe

r Security

Cardretention

Stolen

card

Order

statement

Remotediagnostics

ReliabilityUpdateaccount

Fundstransfer

Messagepassing

Cardvalidation

Customerdatabase

Manager

Accountholder

Foreigncustomer

Hardwaremaintenance

Bankteller


23/54

23

b. Interviewing

In formal orinformal interviewing, the REteam puts questions to stakeholdersabout the system.

There are two types of interview Closed interviews where a pre-defined set of

questions are answered.

Open interviews where there is no pre-definedagenda and a range of issues are exploredwith stakeholders.


24/54

24

Interviews in practice

Normally a mix of closed and open-endedinterviewing.

Interviews are good for getting an overallunderstanding ofwhat stakeholders do and howthey interact with the system.


25/54

25

Effective interviewers

Interviewers should be open-minded, willing to

listen to stakeholders and should not have pre-

ideas about the requirements.

They should prompt the interviewee with a

question or a proposal and should not simply

expect them to respond to a question such aswhat do you want.


26/54

26

c. Scenarios

Scenarios are descriptions ofhow a system isused in practice, a real-life examples of how asystem can be used.

Scenarios are particularly useful for adding detailto an outline requirements description


27/54

27

Scenario include:

description of the system state at thebeginning of the scenario

Normal flow of events in the scenario

What can go wrong and how this is handled

Otherconcurrent activities

description of the System state on completionof the scenario


28/54

28

Event scenarios

Event scenarios may be used to describe how a systemresponds to the occurrence of some particular eventsuch as start transaction


29/54

29

Event scenarios, cont

The diagrammatic notations used in eventscenarios are: Data provided and delivered from/to a

viewpoint is shown in ellipses. Control information, enter and leave at the

top of each box. Exception processing, shown at the

bottom of the box. Name of the next expected event is shown

in a shaded box


30/54

30

Event scenario - start transaction

Validate user

Request PIN

Selectservice

Timeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Account

numberPIN

Account

number

Valid card

User OK


31/54

31

Exception description

In the previous example, exceptions are: Timeout, customer fails to enter a PIN within the

allowed time limit Invalid card, the card is not recognized and is

returned Stolen card, the card has been registered as

stolen and is retained by the machine


32/54

32

c. Use cases Use-cases are a scenario based technique for

requirement elicitation in the UML notations thatused in object-oriented system model (UnifiedModelling Language which identify the actors in

an interaction and which describe the interactionitself

A set of use cases should describe all possibleinteractions with the system

Sequence diagrams may be used to add detail touse-cases by showing the sequence of event in

the system


33/54

33

Use cases, cont..

The sequence diagram (ch 6) is used to add

information to use-case.

The sequence diagram shows the:

1- actors used in the interaction

2- objects that the actors interact with.3- operation associated with these objects.


34/54

34

Library system , example.

Interaction fordownloading and printing

article.

Objects used in this interaction are:

1. Article

2. Form

3. workspace4. printer


35/54

35

Lending use-case

Lending services


36/54

36

use-cases for Library system

Lending services

User administration

Supplier Catalog services

Library

User

Library

Staff


37/54

37

Example ofsequence diagram of Printing article.

User

item:Article

copyrightForm:Form

request

complete

myWorkspace:Workspace

myPrinter:Printer

request

return

copyright OK

deliver

article OK

printsend

confirminform

delete


38/54

38

7.3Requirements validation

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

Requirements error costs are high so validation is veryimportant

Fixing a requirements errorafter deliverymay cost up to100 times the cost of fixing an implementation error

Change requirement error means change system designand implementation


39/54

39

Requirements checking(types of checksshould be carried out on requirements)

Validity. Does the system provide the functions which bestsupport the customers 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

Verifiability. Can the requirements be checked? In order to

reduce potential dispute between customers.Should be write a set of test that can be demonstrate thatthe delivered system meet each specified requirements.


40/54

40

Requirements validationtechniques

Requirements reviews, systematic manual analysis of therequirements

Prototyping, using an executable model of the system to

check requirements.

Test-case generation, developing tests for requirements tocheck testability of requirement.

Automated consistency analysis , checking theconsistency of a structured requirements description, if therequirements are expressed in structured or formal notation,

then CASE tool may be used to check the consistency.


41/54

41

6.3.1Requirementsreviews

Regular reviews should be held while the requirementsdefinition is being formulated

Both client and contractorstaff should be involved inreviews

Reviews may be formal (with completed documents or

informal.

Good communications between developers, customers canresolve problems at an early stage


42/54

42

Review checks:

Verifiability. Is the requirement realisticallytestable?

Comprehensibility. Is the requirement properlyunderstood?

Trace-ability. Is the source of the requirementclearly stated?

Adaptability. Can the requirement be changed

without a large impact on other requirements?


43/54

43

7.4Requirements management

Requirements management is the process of managingchanging requirementsduring the requirementsengineering process andsystem development

Requirements are inevitably incomplete and inconsistentbecause:

New requirements emerge during the process becausebusiness needs change and a better understanding of

the system is developed

Different viewpoints have different requirements andthese are often contradictory


44/54

44

Requirements change because of:

Thepriority of requirements from different viewpointschanges during the development process

System customers may specify requirements from abusiness perspective that conflict with end-userrequirements.

(customers-people who pay for the system- and end-user-people who use the system- usually different

The business and technical environment of the systemchanges during its development


45/54

45

7.4.1Enduring and volatile requirements

Enduring requirements.Stable requirements derived fromthe core activity of the customer organization. E.g. ahospital will always have doctors, nurses, etc.

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


46/54

Classification of Volatile requirements

Mutable requirements, requirements thatchange due to the changing ofsystemsenvironment

Emergent requirements, requirements thatemerge as understanding of the systemdevelops during the system development.


47/54

47

Classification of Volatile requirements

Consequential requirements,requirements that result from theintroduction of the computersystem that

result to new process which may generatenew requirements.

Compatibility requirements, requirements

that depend on other systems


48/54

48

7.4.2Requirements management planning

During the requirements engineering process, you haveto plan on:

Requirements identification, howrequirements are individually identified

A change management process, the processfollowed when analyzing a requirementschange (the impact and cost of change


49/54

49

Requirements management planning,cont..

Traceability policies, the amount ofinformation about requirements relationshipsare recorded and how it should be maintained

CASE toolsupport which required to helpmanage requirements change, using

spreadsheets and databases.


50/54

Traceability Traceability is concerned with the relationships between

requirements, their sources andrelationships betweenrequirements and the system design

There are three types of traceability:

Source traceability, links from requirements tostakeholders who proposed these requirements

Requirements traceability, links between dependentrequirements

Design traceability, links from the requirements to thedesign,

A traceability matrix


51/54

51

A traceability matrixR- weak relationship

U- row use facility of column, shows dependency between reqs

Req. in the row depends on the Req. in the column

7 4 3Requirements change management


52/54

52

7.4.3Requirements change managementprocess

Should be applied to all proposedchanges to therequirements. The advantage of using a formal process forchange management is that all change proposals are treatedconsistently.

Principal stages to a change management process:

Problem analysis. Discuss requirements problem andpropose change

Change analysis and costing. Assess effects of changeon other requirements

Change implementation. Modify requirements documentand other documents to reflect change


53/54

53

Key points

The requirements engineering process includes a feasibilitystudy, requirements elicitation and analysis, requirementsspecification and requirements management

Requirements analysis is iterative involving domainunderstanding, requirements collection, classification,structuring, prioritization and validation

Systems have multiple stakeholders with differentrequirements


54/54

54

Key points

Social and organisation factors influence systemrequirements

Requirements validation is concerned with checks forvalidity, consistency, completeness, realism andverifiability

Business changes inevitably lead to changingrequirements

Requirements management includes planning and

Ch 7 Requirements Engineering Processes

Documents

Transcript of Ch 7 Requirements Engineering Processes