Outline

Lecture 6 Requirements analysis and negotiation

Zheying Zhang
Department of Computer Sciences
University of Tampere

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Requirements Engineering

Requirements analysis and negotiation processes

and techniques

Basic concepts
The process model
Techniques: checklists, matrices
Requirements analyst

Prototyping
Requirements prioritization

Characteristics of good
requirements
Valid (or correct)

Complete
Specifies all the things the system
must do and all the things it must
not do!
Conceptual Completeness

E.g. responses to all classes of input

Doesnt contradict

Necessary
Doesnt contain anything that isnt
required

Technical notations should only be used

as backup (e.g. in an appendix)

Modifiable
Can be changed without difficulty

I.e. is satisfiable

Uses all terms consistently

Understandable (Clear)
E.g. by non-computer specialists

E.g. no TBDs!!!

Consistent

E.g. in a glossary

Verifiable
A process exists to test satisfaction
of each requirement

Structural Completeness

Unambiguous
Every statement can be read in
exactly one way
Clearly defines confusing terms

Expresses only the real needs of

the stakeholders

Good structure and cross-referencing

It must be kept up to date!

Feasible, Prioritized, Traceable,

Precise

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Requirements analysis
The goal of analysis is to discover problems,
incompleteness and inconsistencies in the elicited
requirements
Input - A draft system requirements document
Output identification a set of problematic requirements
Analysis is interlaced with elicitation

Requirements analysis and

negotiation

Requirements negotiation

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Disagreements about requirements are inevitable

Requirements negotiation stage involves the different stakeholders
to solve the conflicts and overlaps and agree on a set of
requirements
Input a set of conflicting or overlapped requirements
Output a compromise set of requirements
Negotiation is interlaced with elicitation and analysis
Leave enough time for negotiation - finding an acceptable
compromise can be time-consuming

Requirements analysis
Necessity
checking

Unnecessary
requirements

Requirements
discussion

Consistency and
completeness
checking
Conflicting and
incomplete
requirements

Requirements
prioritisation

Feasibility
checking

Infeasible
requirements

Requirements
agreement

Requirements negotiation
6

Analysis checklist items for an

individual requirement

Analysis checklists
University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

A checklist is a list of questions which the analyst may

used to assess each requirement
Analysis checklists can be implemented as a
spreadsheet
Row - requirements identifiers
Column - checklist items
Cell comments about potential problems of certain
requirements

Checklist should not normally include more than 10

items (in general)

Premature design
Combined requirements
Unnecessary requirements
Use of non-standard hardware
Conformance with business goals
Requirements ambiguity
Requirements realism
Requirements testability

Requirements interactions

A very important objective of requirements analysis is

to discover the interactions between requirements and
to highlight requirements conflicts and overlaps
A requirements interaction matrix shows how
requirements interact with each other.
In the requirement interaction matrix, requirements are
listed along the rows and columns of the matrix

For requirements which conflict, fill in a 1

For requirements which overlap, fill in a 1000
For requirements which are independent, fill in a 0

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Example of an interaction matrix

Requi rement
R1
R2
R3
R4
R5
R6

R1
0
0
1000
0
1
1

R2
0
0
0
0
0
0

R3
1000
0
0
1000
0
1000

R4
0
0
1000
0
1
1

R5
1
0
0
1
0
0

R6
1
0
1000
1
0
0

10

Three stages of the negotiation

meeting

Negotiation meetings

Analysts who have discovered requirement overlaps, omissions

and conflicts
Stakeholders who can help resolve the discovered problems

An independent chairman

11

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Meetings are the most effective way to negotiate

requirements and resolve requirements conflicts
All conflict requirements should be discussed
individually
Participants

Information stage

Discussion stage

Nature of the problems associated with a requirement is explained

Stakeholders are involved discuss how these problems might be
resolved
All stakeholders with an interest in the requirement should be given
the opportunity to comment. Priorities may be assigned to
requirements at this stage

Resolution stage

Actions concerning the requirement are agreed

Delete the requirement
Suggest specific modifications
Elicit further information about the requirement

12

Requirements analyst

Project Sponser

University of Tampere, Department of Computer Sciences

Requirements analyst has the primary responsibility to

gather, analyze, document, and validate the needs of
the project stakeholders
The analyst plays a central role in collecting and
disseminating product information

Project Management
Business Reqs.

User Reqs.

User Representatives

Size and complexity info..

Requirements
Analyst

FRs & NFRs

Development

Bridges communication between customer and development

stakeholders
Expectations &
Constraints

A project role

FRs & NFRs

Other Stakeholders

Testing

13

The analysts tasks

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Essential analyst skills

Define business requirements

Identify project stakeholders and user classes
Elicit requirements
Analyze requirements
Write requirements specification
Model the requirements
Lead requirements validation
Facilitate requirements prioritization
Manage requirements

Listening
Interviewing and questioning
Analytical skills
Facilitation skills
Observational skills
Writing
Organizational skills
Modeling skills
Interpersonal skills
Creativity

15

16

Essential analyst knowledge

Outline

17

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Knowledge of tool kits and techniques

Knowledge of requirements development and
management activity through the entire product life span
Knowledge of application domain

Requirements analysis and negotiation processes and

techniques

Basic concepts
The process model
Techniques: checklists, matrices
Requirements analyst

Prototyping
Requirements prioritization

18

Prototype

A prototype is an initial version of a system which may

be used for experimentation
Prototypes are valuable for requirements development
because users can experiment with the system and
point out its strengths and weaknesses. They have
something concrete to criticize
Rapid development of prototypes is essential so that
they are available early in the elicitation process

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Types of prototyping

Throw-away

Intended to help elicit and develop the system requirements.

The requirements which should be prototyped are those
which cause most difficulties to customers and which are the
hardest to understand.

Evolutionary

Intended to deliver a workable system quickly to the

customer.
Therefore, the requirements which should be supported by
the initial versions of this prototype are those which are wellunderstood and which can deliver useful end-user
functionality. It is only after extensive use that poorly
understood requirements should be implemented.

19

20

Benefits of prototyping

Challenges of prototyping
University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Help to establish the overall feasibility and usefulness of

the system before high development costs are incurred
Be the only effective way of developing system user
interface
Help to develop system tests
Reveal requirements inconsistencies and
incompleteness

Training costs

Development costs

Depend on the type of system being prototyped and methods

being used

Extended development schedules

Prototype development may require the use of special

purpose tools

Developing a prototype may extend the schedule although

the prototyping time may be recovered because rework is
avoided

Incompleteness

Mislead users

21

22

Approaches to prototyping
Paper prototyping

Wizard of Oz prototyping

a paper mock-up of the system is developed and used for

system experiments
a person simulates the responses of the system in response
to some user inputs

Executable prototyping

a fourth generation language or other rapid development

environment is used to develop an executable prototype

23

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Prototyping guidelines
Include prototyping tasks in your project plan
Create throw-away prototypes as quickly and cheaply
as possible
Do not prototype requirements you already understand
Resist the temptation or the pressure from users to keep
adding more functionality
Use plausible dummy data in prototype screen displays
and reports
Do not expect a prototype to replace written
requirements

24

Outline

Why prioritize requirements?

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Requirements analysis and negotiation processes and

techniques

Basic concepts
The process model
Techniques: checklists, matrices
Requirements analyst

Prototyping
Requirements prioritization

Limited
resources
Schedule

Customer
expectations
are high

Budget
Effort

Too many Reqs

Resources

Changing Reqs
Requirements

Conflicting
Reqs

25

26

Prioritization

Challenges of prioritization
University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Prioritize means listing or rating in order of priority

Requirements prioritization means balancing the
business benefit of each requirement against its cost
and any implications it has for the architectural
foundation and future evolution of the product
Requirements prioritization takes place when
requirements are negotiated

Different stakeholders have usually different opinions

about requirements importance and urgency.
People naturally have their own interest and they aren`t always
willing to compromise their needs for someone else`s benefit.

Many of the prioritization methods are either too

complicated and time consuming or insufficient
Customers may try to avoid prioritization, because
they suspect that low priority requirements will never be
implemented

Developers may try to avoid prioritization, because

they feel bad to admit, that they can`t implement all
requirements

27

28

Prioritization techniques

Prioritization scales
University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Prioritization scales
Prioritization model based on value, cost, and risk
Other techniques, QFD, TQM

29

Grouping requirements into three categories is a

common approach
Three-level scales are subjective and imprecise
All stakeholders must agree on what each level means
Use more definitive labels like committed, time permitting, and
future release
Or provide descriptions beside each label

30

Requirements prioritization scales

Summary of prioritization scales

A mission-critical requirement, required for next release

e.g. Contractual or legal obligations

Medium priority (I but not U)

Supports necessary system operations; required eventually but could
wait until a later release if necessary

Low priority (not (I & U))

A functional or quality enhancement; would be nice to have someday if
resources permit

The fourth (not I but U)

They do not add sufficient value to the product Dont waste your time

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Two dimensions: Importance & Urgency

High priority (I & U)

Pros
Cheap and easy to use
Suitable for a small project

Cons
The results are in many cases just a rough estimate
Participant dependent method
Customers estimate 85% of requirements at high priority, 15%
at medium and 5% at low priority
No desired flexibility for the project

In the real world low priority requirements have frequently been

abandoned

31

32

Prioritization model
University of Tampere, Department of Computer Sciences

Estimating the relative value and relative cost of each requirement

The highest priority requirements are those that provide the largest
fraction of the total product value at the smallest fraction of the total
cost
The prioritization model prioritizes negotiable requirements based
on value, cost, and risk
Depend on both the benefit provided to the customer if a specific
product feature is present and the penalty paid if that feature is absent
A requirements attractiveness is directly proportional to the value it
provides and inversely proportional to its cost and the technical risk
associated with implementing it

33

Steps to use the prioritization model

(Cont.)

Steps to use the prioritization model

 All the items must be at the same level of abstraction

2. Estimate the relative benefit on a scale of 1 (negligible benefit ) to

9 (enormously valuable)
3. Estimate the relative penalty the customer or business would
suffer on a scale of 1 (essentially no penalty) to 9 (a very serious
downside)
4. Calculate the total value (benefit *weight + penalty * weight) and
the percentage of the total value (total value / 6(total value))
5. Estimate the relative cost of implementing each requirement on a
scale of 1 (low) to 9 (high)

35

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

1. List all requirements (features or use cases) needed to prioritize

6. Estimate the relative degree of technical or other risks associated

with each requirement on a scale of 1 (low) to 9 (high)
7. Calculate the priority value
value%
Priority = ----------------------------------------------------------(cost% * cost weight) + (risk% * risk weight)
8. Sort the list of requirements in descending order by calculate
priority. The features at the top of the list have the most favorable
balance of value, cost, and risk
Example and template
http://www.processimpact.com/process_assets/requirements_prior
itization_worksheet.xls

36

Summary of the prioritization model

The accuracy is limited by peoples ability to estimate the
benefit, penalty, cost and risk
Customer and development representatives should review the
completed spreadsheet to reach agreement on the ratings and
the resulting sorted priority sequence

Calibrate the model for your own use with a set of

completed requirements from a previous project
Adjust the weighting factors until the calculated priority
sequence correlates well with the after-the-fact evaluation

University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Use the calculated priority sequence only as a guideline

Other prioritization techniques

Quality function deployment (QFD)
A Japanese technique developed at the Kobe Shipyard
A comprehensive method for relating customer value to the
features for a proposed product
It can be used for large, complex projects in which diverse
stakeholders have very different viewpoints and are having
trouble agreeing

Total quality management (TQM)

It rates each requirement against several weighted project
success criteria and computes a score to rank the priority of the
requirements

37

38

Prioritization considerations
University of Tampere, Department of Computer Sciences

University of Tampere, Department of Computer Sciences

Key points

Must involve all stakeholders

All requirements cannot be essential
Try to get agreement on prioritization informally
As analysis and design evolving, review and adjust
priorities

39

Prototypes are effective for requirements elicitation because

stakeholders have something which they can experiment with to
find their real requirements
Checklists are particularly useful as a way of organizing the
requirements validation process. They remind analysts what to
look for when reading through the proposed requirements
Requirements negotiation is always necessary to resolve
requirements conflicts and remove requirements overlaps.
Negotiation involves information interchange, discussion and
resolution of disagreements
Requirements prioritization provides options to manage
requirement additions and risk, enables delivery of a useful
product in spite of changes in schedule and resource allocations,
and guides architecting and design tradeoffs
The analyst plays a central role in collecting and disseminating
product information. He bridges communication between customer
and development stakeholders
40

Group work Step 3

University of Tampere, Department of Computer Sciences

Can you identify any conflicts or unresolved issues? Are

there any ambiguous, duplicated or missing
requirements? Negotiate to resolve any disagreements.
Comment on how your requirements elicitation
techniques impacted on analysis?
Did you have all the information you needed? Was it
easy or difficult to retrace and resolve issues?

41