Copyright © Jerzy R. Nawrocki

Requirements ReviewRequirements Review

Jerzy.Nawrocki@put.poznan.plwww.cs.put.poznan.pl/jnawrocki/require

Requirements Engineering & Project Management

Lecture 5

J.Nawrocki, Requirements Review

Introduction

Cost of Error Correction

0

20

40

60

80

100

120

Req. Design Code Dev.Tst Sys.Tst Field Op.

Development Phase

Re

lati

ve

Co

st

Roger S. Pressman

13-6

times

10 times

15-40 times

30-70 times

40-1000 times

J.Nawrocki, Requirements Review

Quality-supporting activities

Refacto

ring

Testin

g

Co

nfig

uratio

n m

anag

.

Review

s

Software Quality

J.Nawrocki, Requirements Review

Quality-supporting activities

Refacto

ring

Testin

g

Co

nfig

uratio

n m

anag

.

Review

s

Software Quality

J.Nawrocki, Requirements Review

Agenda

•Requirements Analysis & Negotiation•Requirements Validation

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Requirements Review

Requirements Analysis and Negotiation

The requirements document

Requirements elicitation

Reqs analysis & negotiation

Describing requirements

System modelling

Requirements validation

Requirements management

RE for critical systems

Basic Interm Adv

8

6

54

3

4

4

2

36

-

6

21

3

3

3

3

21

-

1

1-

-

1

2

4

9

J.Nawrocki, Requirements Review

Basic guidelines

Analysis and negotiation

Define system boundaries

SystemSystem

Person 1

Person 2

Institution

Device

• Process requirements• System requirements• Software requirements

J.Nawrocki, Requirements Review

Basic guidelines

Analysis and negotiation

Define system boundariesUse checklists for requirements analysis

J.Nawrocki, Requirements Review

A Checklist Example

• Does a requirement imply the need for some decision-making based on incomplete or unreliable information?

• Will the implementation of a requirement need information which is outside the defined database for the system?

• Is a requirement concerned with the core functionality of the system?

• Is a requirement concerned with the functionality or performance of equipment which is external to the system?

Analysing system’s boundaries

J.Nawrocki, Requirements Review

Another Checklist Example

a) Correct;b) Unambiguous;c) Complete;d) Consistent;e) Ranked for importance and/or stability;f) Verifiable;g) Modifiable;h) Traceable.

IEEE Std 830-1998

J.Nawrocki, Requirements Review

A Checklist for Use Cases

Is there a shared clear vision?Are there visible boundaries?Is there clear cast of characters describing end-users?Are all user-level use-cases user-valued transactions?Does each use case have a complete single goal?Is its naming clear and depicting the goal?Are the alternatives an exhaustive set?Are use cases describing just behaviour?Are adornments properly used?Are the conditions detectable?

J.Nawrocki, Requirements Review

Basic guidelines

Analysis and negotiation

Define system boundariesUse checklists for requirements analysis

Provide software to support negotiationsProvide software to support negotiations

Plan for conflicts and conflict resolution

Prioritise requirements

J.Nawrocki, Requirements Review

Intermediate guidelines

Analysis and negotiation

Classify requirements using a multidimensional approach

System, User interface, Database, Communications, Security

J.Nawrocki, Requirements Review

Intermediate guidelines

Analysis and negotiation

Classify requirements using a multidimensional approach

Use interaction matrices to find conflicts and overlaps

System, User interface, Database, Communications, Security

J.Nawrocki, Requirements Review

Advanced guidelines

Analysis and negotiation

Assess requirements risks

J.Nawrocki, Requirements Review

Agenda

•Requirements Analysis & Negotiation•Requirements Validation

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Requirements Review

Requirements Validation

The requirements document

Requirements elicitation

Reqs analysis & negotiation

Describing requirements

System modelling

Requirements validation

Requirements management

RE for critical systems

Basic Interm Adv

8

6

54

3

4

4

2

36

-

6

21

3

3

3

3

21

-

1

1-

-

1

2

4

9

J.Nawrocki, Requirements Review

Basic guidelines

Requirements validation

Check that the requirements document meets your standardOrganise formal requirements inspections

J.Nawrocki, Requirements Review

Artefact

Reviews and Inspection

Review = Analysis of an artefact (e.g. code, document) done by 1 or more people.

Goals of review:Quality assuranceKnowledge dissemination

Review

J.Nawrocki, Requirements Review

FTR Procedure

Casting

Producer (author)Project ManagerFacilitatorReviewer(s)Recorder

FTR = Formal Technical Review

J.Nawrocki, Requirements Review

FTR Meeting

Decision

Acceptance. No modifications are necessary.

Conditional acceptance. There are some defects but additional inspection is not necessary (the Project Manager will check the final version).

Rejection. There are serious defects and an additional inspection is necessary.

J.Nawrocki, Requirements Review

Basic guidelines

Requirements validation

Check that the requirements document meets your standardOrganise formal requirements inspections

Use multidisciplinary teams to review requirements

Define validation checklists

J.Nawrocki, Requirements Review

Intermediate guidelines

Requirements validation

Use prototyping to animate requirementsWrite a draft user manualPropose requirements test cases

J.Nawrocki, Requirements Review

Advanced guidelines

Requirements validation

Paraphrase system models

J.Nawrocki, Requirements Review

Summary

Requirements analysis: ChecklistsRequirements negotiationRequirements validation: Reviews & FTR (1028)

J.Nawrocki, Requirements Review

Questions?