LECTURE 4

REQUIREMENTS ENGINEERING PROCESSES

CSE 2142 Software Engineering

Objectives

To describe the principal requirements engineering

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 other requirements engineering

processes

2

Challenges faced by Software Engineers3

Need for Requirements Engineering

Understanding the requirements of a problem is among

the most difficult tasks faced by a software engineer.

Just imagine a customer walking in your office and

saying “I know you think you understand what I said, but

what you don’t understand is what I said is not what I

mean”

Unfortunately these nightmares are very common in the

software industry and prove to be very costly as well.

Requirements Engineering provides a solid approach

for addressing these challenges

4

Requirements Engineering

Requirements Engineering is a process that involves all the activities required to create and maintain a system requirements document.

RE provides the appropriate mechanism for

understanding what the customer wants,

analyzing need,

assessing feasibility,

negotiating a reasonable solution,

specifying the solution unambiguously,

validating the specification,

managing the requirements as they are transformed into an operational system.

5

Requirements Engineering Activities

Feasibility

studies

Requirements

elicitation and

analysis

Requirements

validation

Requirements

management

Requirements

specificat io n

Requirements

validat ion

Requirementselicitat ion

System requirements

specificat io n an dmo deling

System

requirementselicitat ion

User requirementsspecificat io n

Userrequirements

elicitat ion

Busin ess requirementsspecificat io n

Prototyping

Feasibility

study

Reviews

System requirements

do cument

Spiral model of requirements engineering processes

6

Feasibility Study (1)

A feasibility study is a short, focused study which

aims to answer the following questions

Does the system contribute to the overall objectives of the

organisation?

Can the system be implemented using current technology

and within given cost and schedule constraints?

Can the system be integrated with other systems which

are already in place?

7

Feasibility Study (2)

Carrying out a feasibility study involves

information assessment phase identifies the information

which is required to answer the three questions set out

above

Information collection: users, managers, experts are

interviewed to obtain relevant information.

The input to the feasibility study is an outline description

of the system and how it will be used within an

organisation and the output should be a report which

recommends whether or not it is worth carrying on.

8

Requirements Elicitation and Analysis (1)

Concerned with learning and understanding the needs

of users and project sponsors with the ultimate aim of

communicating these needs to the system developers

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.

9

Requirements Elicitation and Analysis (2)

Stakeholders

Any person or group who will be affected by the

system, directly or indirectly

End-users

Managers

Engineers involved in development or maintenance

Domain experts

Trade union reps

10

Requirements Elicitation and Analysis

Process (1)

Requirements

discovery

Requirements

classification

and

organisation

Requirements

prioritisation

and

negotiation

Requirements

documentation

Requirementsclassificat ion and

organisat ion

Requirementspriorit izat ion and

nego tiat ion

Requirements

documentat ion

Requirements

discovery

11

Requirements Elicitation and Analysis

Process (2)

Requirements Discovery

The process of interacting with stakeholders in the

system to collect their requirements.

Domain requirements from stakeholders and

documentation are also discovered during this activity

Requirements Classification and organisation

This activity takes the unstructured collection of

requirements, groups related requirements and

organises them into coherent clusters

12

Requirements Elicitation and Analysis

Process (3)

Requirements Prioritisation and Negotiation

When it comes to selecting between different choices, it

becomes important to prioritize between the alternatives

Prioritization helps to identify the most valuable

requirements from this set by distinguishing the critical few

from the trivial many

Requirements Documentation

The requirements are documented and input into the next

round of the spiral.

Formal or informal requirements documents may be

produced

13

Question 1

Suggest who might be stakeholders in a university

student records system? Explain why it is almost

inevitable that the requirements of the different

stakeholders will conflict in some way

14

Question 2

Eliciting and understanding stakeholder

requirements is difficult for several reasons. Identify

the reasons underlying the difficulty.

15

Problems of Elicitation

Problems of scope boundary of system is ill-defined

unnecessary design information may be given

Problems of articulation users are aware of their needs but are unable to articulate them or afraid to articulate it

users may not be aware of their needs

Communication barriers user and analyst speak different languages

limitations of the communication language

Cognitive limitations

analysts have poor knowledge of problem domain

users have poor understanding of computer capabilities and limitations

Technical issues

requirements evolve over time

rapid software & hardware technology changes

16

Techniques for Requirements Elicitation

and Analysis (1)

Viewpoints A way of structuring the requirements to represent the perspectives of

different stakeholders

Interactor viewpoints People or other systems that interact directly with the system

Indirect viewpoints Stakeholders who do not use the system themselves but who influence the

requirements

Domain viewpoints Domain characteristics and constraints that influence the requirements

Interviewing The RE team puts questions to stakeholders about the system that they

use and the system to be developed

Closed interviews A pre-defined set of questions are answered

Open interviews No pre-defined agenda and a range of issues are explored with

stakeholders

17

Techniques for requirements elicitation

and analysis (2)

Scenarios

Real-life examples of how a system can be used

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

Use-cases

Scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself

Ethnography

Observation of the day-to-day work and notes made of the actual task in which participants are involved

18

Viewpoint-Oriented Analysis

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 analyse system requirements

However, their perspectives are not completely

independent but usually overlap so that they have

common requirements.

The VORD (Viewpoint- Oriented Requirements Definition)

method designed in 1996-1998 by Sommerville &

Kotonya as a service oriented framework for

requirements elicitation & analysis

19

Types of viewpoint

Data sources or sinks

Viewpoints are responsible for producing or consuming data.

Analysis involves checking what data is produced and consumed and

validate assumptions.

Representation frameworks

Viewpoints represent particular types of system model. Each model

discovers different requirements.

Receivers of services

Viewpoints are external to the system and receive services from it.

Most suited to interactive systems

Viewpoints as data source/sinks & representation are

particularly valuable for discovering requirements conflict.

20

The VORD method

Viewpointidentification

Viewpointstructuring

Viewpointdocumenta tion

Viewpointsystem mapping

Viewpoint identification: Discover viewpoints which receive

system services and identify the services provided to each

viewpoint

Viewpoint structuring: Group related viewpoints into a

hierarchy.

Viewpoint documentation: Refine the description of the

identified viewpoints and services

Viewpoint-system mapping: Transform the analysis to an

object-oriented design

21

Autoteller viewpoints

The example used here is an auto-teller system which

provides some automated banking services which include

cash withdrawal, message passing ,ordering a statement

and transferring funds

The viewpoints are

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

22

Viewpoint identification

Querybalance

Gettransactions

Cashwithdrawal

Transactionlog

Machinesupplies

Cardreturning

Remotesoftwareupgrade

Ordercheques

Userinterface

Accountinformation

Messagelog

Softwaresize Invalid

userSystem cost Printe

r Security

Cardretention

Stolencard

Orderstatement

Remotediagnostics

ReliabilityUpdateaccount

Fundstransfer

Messagepassing

Cardvalidation

Customerdatabase

Manager

Accountholder

Foreigncustomer

Hardwaremaintenance

Bankteller

23

Viewpoint Structuring

EngineerManagerTellerForeign

customerAccountholder

Services

Order chequesSend messageTransaction listOrder statement

Transfer funds

Customer Bank staff

All VPs

Services

Query balanceWithdraw cash

24

Viewpoint Documentation

Customer

Account numberPINStart transactionSelect serviceCanceltransactionEnd transaction

Cash withdrawalBalance enquiry

Account holderForeigncustomer

Reference:

Attributes:

Events:

Services:

Sub-VPs:

Cash withdrawal

To improve customer serviceand reduce paperwork

Users choose this service bypressing the cash withdrawalbutton. They then enter theamount required. This isconfirmed and, if funds allow,the balance is delivered.

Customer

Deliver cash within 1 minuteof amount being confirmed

Filled in later

Reference:

Rationale:

Specification:

VPs:

Non-funct.requirements:

Provider:

25

Viewpoint Standard Forms

Viewpoint template Service template

Reference: T he viewpoint name. Reference: T he service name.Attributes: Attributes providing

viewpoint information.Rationale: Reason why the service is

provided.Events: A reference to a set of event

scenarios describing howthe system reacts toviewpoint events.

Specification: Reference to a list of servicespecifications. These maybe expressed in differentnotations.

Services A reference to a set ofservice descriptions.

Viewpoints: List of viewpoint namesreceiving the service.

Sub-VPs: T he names of sub-viewpoints.

Non-functionalrequirements:

Reference to a set of non -functional requirementswhich constrain the service.

Provider: Reference to a list of systemobjects which provide theservice.

26

Question 3

A software system is to be developed to managethe records of patients who enter a clinic fortreatment. The records include records of the allregular patient monitoring (temperature, bloodpressure, etc) treatments given, patient reactionsand so on. After treatment, the records of their stayare sent to the patient’s doctor who maintains theircomplete medical record. Identify the principalviewpoints which might be taken into account in thespecification of this system and organize these usinga viewpoint hierarchy diagram.

27

Question 4

For the “Library manager”, “Users” and “Systemmanagers” viewpoints identified in the library system,LIBSYS (Diagram in next slide), suggest three requirementsthat could be suggested by the stakeholders associatedwith that viewpoint.

The LIBSYS system has to include support forcataloguing new documents where the system catalogmay be distributed across several machines. Whatare likely to be the most important types of non-functional requirements associated with thecataloguing facilities?

28

Question 4 (cont’d)

Article

providersFinance

Library

manager

Library

staffUsers

InteractorIndirect

All VPs

Classificat ionsystem

UI

standards

Domain

ExternalStaffStudents CataloguersSystem

managers

Viewpoints in LIBSYS

29

30

Software Requirements Validation

Requirements validation is concerned with showing that the requirements actually define the system which the customer wants.

Validity checks : Does the requirement meet the objectives of the system.

Consistency checks : Requirements in the document should not conflict.

Completeness checks : The requirements document should includerequirements which define all functions and constraints intended by thesystem user.

Realism checks : Using knowledge of existing technology, the requirements

should be checked to ensure that they can actually be implemented.

Verifiability : requirements should be written such that a set of checks can

be designed to demonstrate that the delivered system meets that

requirement.

Requirements Validation Techniques

Reviews

Systematic manual analysis of the requirements

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?

Prototyping

Using an executable model of the system to check requirements

Test-case generation

Developing tests for requirements to check testability

31

32

Requirements Management

Requirements management is the process of understanding and controlling changes to system requirements.

Different users have different requirements and priorities. It is oftendiscovered that priorities given to different users needs to bechanged.

System customers impose requirements because of organisationaland budgetary constraints. These may conflict with end-userrequirements.

The business and technical environment of the system changes andthese must be reflected in the system itself.

New hardware may be introduced,

business priorities may change with consequent changes in the system supportwhich is needed

new legislation and regulations may be introduced which must be implemented bythe system.

33

Requirements Classification

From an evolution perspective, requirements fall into two classes:

Enduring requirements - These are relatively stable requirements which derive from the core activity of the organisation and which relate directly to the domain of the system.

Volatile requirements - These are requirements which are likely to change during the system development or after the system has been put into operation.

Mutable Requirements - Requirements which change because of changes to the environment in which the organisation is operating.

Emergent - Requirements which emerge as the customer’s understanding of the system develops.

Consequential- Requirements which result from the introduction of the computer system.

Compatibility- Requirements which depend on the particular systems or business processes within an organisation.

34

Requirements Management Planning

Planning stage establishes the level of requirements management detail which is required. During the requirements management stage, you have to decide on:

Requirements identification: Each requirement must be uniquely identifiedthat it can be cross-referenced by other requirements and so that it may beus in traceability assessments.

A change management process: This is the set of activities which assessimpact and cost of changes.

Traceability policies: These policies define the relationships between requirements and between the requirements and the system design that should be recorded and how these records should be maintained. (Source, Requirements & Design traceability)

CASE tool support: Tools which may be used range from specialist requirements management system to spreadsheets and simple database systems.

35

Requirements Change Management

Requirements change management should be applied to all proposed changes to the requirements. There are three principal stages to a change management process:

Problem analysis and change specification

The process starts with an identified requirements problem . The problem is analysed to check that it is valid.

Change analysis and costing

The effect of the proposed change is using traceability information and general knowledge of the system The cost of making the change is estimated both in terms of the requirements document and, if appropriate, to the system design

Change implementation

The requirements document and, where necessary, the system design and implementation is modified.