A.3 Design description languages

This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.

A.4 Graphical notations

Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.

A.5 Mathematical specifications

These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document,

Page 25 of 91

most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

3.4

Requirements engineering processes

A.1 The processes used for RE vary widely depending on the application domain,

the people involved and the organisation developing the requirements

A.2 However, there are a number of generic activities common to all processes

1. 2. 3. 4.

Feasibility studies

Requirements elicitation and analysis Requirements validation Requirements management

A.3 In practice, RE is an iterative activity in which these processes are interleaved.

B.1

A spiral view of the requirements engineering process

3.4.2 Feasibility studies

B.1 B.2

A feasibility study decides whether or not the proposed system is worthwhile A short focused study that checks

Page 26 of 91

? If the system contributes to organisational 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

3.4.3 Elicitation and analysis A.1 Introduction

? 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

A.2 Problems of requirements analysis

1. 2. 3. 4. 5.

Stakeholders don’t know what they really want.

Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements.

Organisational and political factors may influence the system requirements.

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

A.3 Process activities

Requirements discovery

Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.

Requirements classification and organisation

Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation

Prioritising requirements and resolving requirements conflicts. Requirements documentation

Requirements are documented.

B.1

B.2 B.3 B.4

3.4.4 techniches of Requirements discovery A.1 Interviewing

B.1

Formal or informal interviews with stakeholders are part of most RE processes.

B.2 Types of interview

1. Closed interviews based on pre-determined list of questions

2. Open interviews where various issues are explored with stakeholders.

B.3 Normally a mix of closed and open-ended interviewing.

Page 27 of 91

B.4

Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.

A.2 Scenarios

B.1 B.2

? ? ? ? ?

Scenarios are real-life examples of how a system can be used. They should include

A description of the starting situation;

A description of the normal flow of events; A description of what can go wrong;

Information about other concurrent activities;

A description of the state when the scenario finishes

A.3 Use cases

B.1

Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself

B.2 A set of use cases should describe all possible interactions with the system

Lending use-case

Library use-cases

B.3

High-level graphical model supplemented by more detailed tabular description (see Chapter 5).

B.4 Sequence diagrams may be used to add detail to use-cases by showing the

sequence of event processing in the system

Catalogue management(Sequence diagram)

Page 28 of 91