Chapter 6

Requirements Engineering Process

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 1

Requirements Engineering Processes

Processes used to discover, analyze and validate system requirements

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 2

Objectives

To describe the principal requirements engineering activities To introduce techniques for requirements elicitation and analysis To describe requirements validation To discuss requirements management

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 3

Requirements engineering process

Feasibility study Requirements elicitation and analysis Requir ements specification Requirements validation System models User and system requirements Requirements document

Feasibility report

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 4

Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 5

Feasibility studies

A feasibility study decides whether or not the proposed system is worthwhile. The study 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 that are used

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 6

Feasibility study implementation

Based on information collection, information assessment 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 skills? What facilities must be supported by the proposed system?
Software Engineering, 6th edition. Chapter 6 Slide 7

Ian Sommerville 2000

Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 8

Requirement elicitation and analysis

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

Involves many stakeholders, such as end-users, managers, engineers, domain experts, trade unions, etc.

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 9

Problems of requirements analysis

Stakeholders dont 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, because new stakeholders may emerge and the business environment may change
Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 10

The requirements analysis process

Requirements validation Domain understanding Requir ements definition and specification

Prioritization

Process entry

Requirements collection

Conflict resolution

Classification

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 11

Techniques for requirements elicitation and analysis

Viewpoint-oriented elicitation

Scenarios
Ethnography

State models
Prototyping

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 12

Banking ATM system An example

Services include cash and check deposit, cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 13

ATM viewpoint resources

Bank customers Representatives of other banks Hardware and software maintenance engineers Marketing department Bank managers and counter staff Database administrators and security staff Communications engineers Personnel department
Software Engineering, 6th edition. Chapter 6 Slide 14

Ian Sommerville 2000

Viewpoint-oriented elicitation

Stakeholders represent different ways of looking at a problem or problem viewpoints This multi-perspective analysis is important as there is no single correct way to analyze system requirements

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 15

Types of viewpoint

Receivers of services
Viewpoints are external to the system and receive services from the system. Most suited to interactive systems

Data sources or sinks

Viewpoints are responsible for producing or consuming data.

Representation frameworks
Viewpoints represent particular types of system model.

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 16

The VORD method

View Point-Oriented Requirement Definition

Viewpoint identification

Viewpoint structuring

Viewpoint documenta tion

Viewpoint system ma pping

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 17

VORD process model

Viewpoint identification
Discover viewpoints which receive system services and identify the services provided to each viewpoint Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy Refine the description of the identified viewpoints and services Transform the analysis to an object-oriented design

Viewpoint structuring

Viewpoint documentation

Viewpoint-system mapping

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 18

Viewpoint identification
Query balance Machine supplies User interface Account holder Remote diagnostics Get transactions Manager Account information System cost Stolen card Message log Foreign customer Customer database Card returning Software size Printe r Hardware maintenance Funds transfer Cash withdrawal Remote software upgrade Bank teller Security Message passing Card retention Card validation Transaction log Order cheques Invalid user

Order statement Update account

Reliability

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 19

Viewpoint service information

ACCOUNT HOLDER Service list Withdraw cash Query balance Or der cheques Send message Transaction list Or der statement Transfer funds FOREIGN CUSTOMER Service list Withdraw cash Query balance BANK TELLER Service list Run diagnostics Add cash Add paper Send message

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 20

Viewpoint data/control
ACCOUNT HOLDER Control input Start transaction Cancel transaction End transaction Select service Da ta input Card details PIN Am ount required Message

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 21

Viewpoint hierarchy
All VPs Services Query balance Withdraw cash Customer Bank staff

Services Order cheques Send message Transaction list Order statement Transfer funds

Account holder

Foreign customer

Teller

Manager

Engineer

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 22

Scenarios

Scenarios are descriptions of how a system is used in practice (the interaction) They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system Scenarios are particularly useful for adding detail to an outline requirements description
Software Engineering, 6th edition. Chapter 6 Slide 23

Ian Sommerville 2000

Scenario descriptions
Including

System state description at the beginning of the scenario

Normal flow of events in the scenario

What can go wrong and how this is handled

Other concurrent activities System state on completion of the scenario

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 24

Structured approach for scenarios

Event Scenarios

Use-cases

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 25

Event scenarios

An event is an occurrence of something important

Event scenarios are used to describe how a system responds to the occurrence of some particular event such as start transaction

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 26

Event scenario - start transaction

Card present Valid card Card Request PIN PIN Account number PIN Validate user Account number Select service User OK

Timeout Return card Invalid card Return card

Incorrect PIN Re-enter PIN

Incorrect PIN Stolen card Retain card

Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27

Return card

Use cases

Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself A set of use cases should describe all possible interactions with the system Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system
Software Engineering, 6th edition. Chapter 6 Slide 28

Ian Sommerville 2000

Lending use-case

Lending services

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 29

Library use-cases
Lending services Library User

User administration

Library Staff

Supplier
Ian Sommerville 2000

Catalog services
Software Engineering, 6th edition. Chapter 6 Slide 30

Catalogue management
Item: Library Item Bookshop: Supplier Acquire Catalog Item Dispose New Books: Catalog Cataloguer: Library Staff

Uncatalog Item

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 31

Ethnography

A social scientists spends a considerable time observing and analysing how people actually work People do not have to explain or articulate their work Social and organizational factors of importance may be observed Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models
Software Engineering, 6th edition. Chapter 6 Slide 32

Ian Sommerville 2000

Scope of ethnography

Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work Requirements that are derived from cooperation and awareness of other peoples activities

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 33

Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 34

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

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 35

Requirements checking

Validity. Does the system provide the functions which best support 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?
Software Engineering, 6th edition. Chapter 6 Slide 36

Ian Sommerville 2000

Requirements validation techniques

Requirements reviews
Systematic manual analysis of the requirements Using an executable model of the system to check requirements. Covered in Chapter 8 Developing tests for requirements to check testability Checking the consistency of a structured requirements description

Prototyping

Test-case generation

Automated consistency analysis

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 37

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
Software Engineering, 6th edition. Chapter 6 Slide 38

Ian Sommerville 2000

Automated consistency checking

Requirements in a formal language Requirements problem report

Requirements processor Requir ements database

Requirements analyser

Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 6

Slide 39

Key points

The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management Requirements analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation Systems have multiple stakeholders with different requirements
Software Engineering, 6th edition. Chapter 6 Slide 40

Ian Sommerville 2000

Key points

Social and organisation factors influence system requirements Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability Business changes inevitably lead to changing requirements Requirements management includes planning and change management
Software Engineering, 6th edition. Chapter 6 Slide 41

Ian Sommerville 2000