SQA Lesson 4 Monitoring and Controlling Requirements Engineering Processes

8/14/2019 SQA Lesson 4 Monitoring and Controlling Requirements Engineering Processes

1/24

1

Monitoring and Controlling

Lesson 4

SQA and Project Management


2/24

2

Requirements engineering processes

The processes used for RE vary widelydepending on the application domain, the peopleinvolved and the organisation developing therequirements.

However, there are a number of generic activitiescommon to all processes

Requirements elicitation; Requirements analysis;

Requirements validation;

Requirements management.


3/24

3

The requirements engineering process

Feasibility

study

Requirements

elicitation and

analysisRequirements

specification

Requirementsvalidation

Feasibilityreport

System

models

User and systemrequirements

Requirements

document


4/24

4

Requirements engineering

Requirements

specification

Requirements

validation

Requirementselicitation

System requirements

specification andmodeling

System

requirementselicitation

User requirementsspecification

Userrequirements

elicitation

Business requirementsspecification

Prototyping

Feasibility

study

Reviews

System requirementsdocument


5/24

5

Feasibility studies

A feasibility study decides whether or notthe proposed system is worthwhile.

A short focused study that checksIf the system contributes to organisational

objectives;

If the system can be engineered using currenttechnology and within budget;

If the system can be integrated with othersystems that are used.


6/24

6

Feasibility study implementation

Based on information assessment (what isrequired), information collection and reportwriting.

Questions for people in the organisation 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 proposedsystem?


7/24

7

Elicitation and analysis Sometimes called requirements elicitation or

requirements discovery.

Involves technical staff working with customersto find out about the application domain, the

services that the system should provide and the

systems operational constraints.

May involve end-users, managers, engineers

involved in maintenance, domain experts, trade

unions, etc. These are called stakeholders.


8/24

8

Problems of requirements analysis

Stakeholders dont know what they really want.

Stakeholders express requirements in their own

terms. Different stakeholders may have conflicting

requirements.

The requirements change during the analysisprocess. New stakeholders may emerge and the

business environment change.


9/24

9

ATM stakeholders Bank customers

Representatives of other banks

Bank managers

Counter staff

Database administrators

Security managers

Marketing department

Hardware and software maintenance engineers

Banking regulators


10/24

10

Viewpoints Viewpoints are a way of structuring the

requirements to represent the perspectives

of different stakeholders. Stakeholders maybe classified under different viewpoints.

This multi-perspective analysis is important

as there is no single correct way to analysesystem requirements.


11/24

11

Types of viewpoint Interactor viewpoints

People or other systems that interact directly withthe system. In an ATM, the customers and the

account database are interactor VPs.

Indirect viewpoints Stakeholders who do not use the system themselves

but who influence the requirements. In an ATM,

management and security staff are indirectviewpoints.

Domain viewpoints Domain characteristics and constraints that influence

the requirements. In an ATM, an example would bestandards for inter-bank communications.


12/24

12

Interviewing

In formal or informal interviewing, the RE team

puts questions to stakeholders about the system

that they use and the system to be developed. 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 explored with

stakeholders.


13/24

13

Interviews in practice

Normally a mix of closed and open-endedinterviewing.

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

Interviews are not good for understanding

domain requirements Requirements engineers cannot understand specificdomain terminology;

Some domain knowledge is so familiar that peoplefind it hard to articulate or think that it isnt worth

articulating.


14/24

14

Effective interviewers

Interviewers should be open-minded,

willing to listen to stakeholders and should

not have pre-conceived ideas about therequirements.

They should prompt the interviewee with a

question or a proposal and should notsimply expect them to respond to a question

such as what do you want.


15/24

15

Scenarios

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.


16/24

16

Requirements checking Validity. Does the system provide the functions

which best support the customers needs?

Consistency. Are there any requirementsconflicts?

Completeness. Are all functions required by thecustomer included?

Realism. Can the requirements be implementedgiven available budget and technology

Verifiability. Can the requirements be checked?


17/24

17

Requirements validation techniques

Requirements reviews Systematic manual analysis of the requirements.

Prototyping Using an executable model of the system to checkrequirements. Covered in Chapter 17.

Test-case generation

Developing tests for requirements to check testability.


18/24

18

Requirements reviews Regular reviews should be held while the

requirements definition is being formulated.

Both client and contractor staff should be involvedin reviews.

Reviews may be formal (with completed

documents) or informal. Good communications

between developers, customers and users can

resolve problems at an early stage.


19/24

19

Review checks Verifiability. Is the requirement realistically

testable?

Comprehensibility. Is the requirement properlyunderstood?

Traceability. Is the origin of the requirement

clearly stated?

Adaptability. Can the requirement be changed

without a large impact on other requirements?


20/24

20

Requirements management

Requirements management is the process ofmanaging changing requirements during therequirements engineering process and systemdevelopment.

Requirements are inevitably incomplete andinconsistent New requirements emerge during the process as

business needs change and a better understanding ofthe system is developed;

Different viewpoints have different requirements andthese are often contradictory.


21/24

21

Requirements change

The priority of requirements from differentviewpoints changes during the development

process. System customers may specify

requirements from a business perspectivethat conflict with end-user requirements.

The business and technical environment ofthe system changes during its development.


22/24

22

Requirements classification

Requirement

Type

Description

Mutable

requirements

Requirements that change because of changes to the environment in which the

organisation is operating. For example, in hospital systems, the funding of patient

care may change and thus require different treatment information to be collected.

Emergent

requirements

Requirements that emerge as the customer's understanding of the system develops

during the system development. The design process may reveal new emergent

requirements.

Consequential

requirements

Requirements that result from the introduction of the computer system. Introducing

the computer system may change the organisations processes and open up new ways

of working which generate new system requirementsCompatibility

requirements

Requirements that depend on the particular systems or business processes within an

organisation. As these change, the compatibility requirements on the commissioned

or delivered system may also have to evolve.


23/24

23

Change management

Change

implementation

Change analysis

and costing

Problem analysis and

change specification

Identified

problem

Revised

requirements


24/24

24

The End

Zainudin Johari

B Sc. (Hons) Computer Science, UPM

M Sc. Computer Science (Information Systems) UPM

Documents

SQA Lesson 4 Monitoring and Controlling Requirements Engineering Processes