Software Requirement

Engineering

Requirement Negotiation

Ameer Hamza

1
Requirements Negotiation

 Possible conflicts to be resolved among stakeholders

 Between supplier and customers about costs, benefits, risks
 Conflicts with other projects about resources
 Conflicting goals, features, requirements

 Conflict resolution involves negotiation

 Negotiating a coherent set of requirements is not easy
 But it is one task of the requirements analyst
 Difficult to satisfy everyone, to achieve all goals, make good
decisions!
 Involves a lot of (group) discussions

3
Requirements Negotiation (2)

 First, detect when requirements are

inconsistent

 Then, convince all stakeholders to understand

the essential point of view of each other

 Finally, reach an agreement on a coherent set

of requirements that meets the needs of as
many stakeholders as possible

4
 Let Schedule Drive Requirements (Not the
Reverse)

“Okay, Here Are Our

Requirements By When “It Will
Can You Build Them?” Take Us 9
Months”

“Sorry, They
Must Be
Completed in Typical Scenario
6 Months”

NOW WHAT?

Source: Davis, A.: “Just Enough Requirements Management”, Dorset House, 2005; “The art of requirements triage”, IEEE Computer, 03/2003
5
 Let Schedule Drive Requirements
(Better Scenario)
“Let’s see.
“Okay, we’re going to If we build
build in a series of 3 reqts 1
month increments. Here through 9
are all the and 12,
requirements.” we’ll be
able to do
them in 3
“But we months”
really
need reqt “Okay. How
17 in that about if we
first add reqt 17
release.” and drop
reqt 12?”

Source: Davis, A.: “Just Enough Requirements Management”, Dorset House, 2005; “The art of requirements triage”, IEEE Computer, 03/2003
6
 Let Schedule Drive Requirements
(Better Scenario)

“Well if we
“Hmmm. I really liked
drop
reqt 12. Can we drop
requirements
reqt 3 instead?.”
3 and 4, we
could do
it.”

“Okay “Okay. How

” about if we
add reqt 17
and drop
reqt 12?”

Teamwork!!!
Source: Davis, A.: “Just Enough Requirements Management”, Dorset House, 2005; “The art of requirements triage”, IEEE Computer, 03/2003
7
Difficulties (1)

 There are too many requirements!

 From many different sources

 Resources are limited (budget, time…)

 Establishing priorities is important, but

 Which requirements are important, and to whom?
 How to prioritize them? On what basis? What to
minimize/maximize?
 In which iteration should the requirement be considered?

 Developers may not know the business value of some

requirements, and clients may not know the
implementation complexity of some requirements
8
Difficulties (2)

 Different stakeholders have different goals and

different priorities
 Some stakeholders’ decisions carry more
weight than others

 Companies often lack systematic data,

metrics, and technologies to support the
prioritization process
 Often done manually, informally, on an ad-hoc basis
 Difficult to establish and communicate

9
Requirements negotiation

 Requirements negotiation involves discussion

on the requirements conflict to have some
compromise that will satisfy the participating
stakeholders of a software project. The output
of a requirement negotiation is a set of
satisfied requirements of two or more parties
Benefits of RN
Some key benefits are:
 More complete requirements in the early stages
of a project
 Fewer requirements changes during
development
 Enabling a shared vision throughout the life
cycle
 Negotiation methods preserve/retain the
rationale of decision making
 Control of “Scope ”
Effective practices for requirements
negotiation
1. Get the right stakeholders
2. Establish a teamwork mentality
3. Plan team interaction
4. Use a Group Support System (GSS)
5. Establish a shared vocabulary
6. Maintain a list of requirements
7. Manage by probabilities of completion
rather than absolutes
8. Select an operational approach coupled
with risk assessment
continued
9. Plan more than one release at a time
10. Re-plan before every new release
11. Find a workable solution
12. Provide training in the negotiation process
Requirements Negotiation
Stages

 Requirements discussion
 Requirements prioritization
 Requirements agreement
Requirements Discussion

Requirements which have been highlighted as

problematic are discussed and the stakeholders
involved present their views about the
requirements
Requirements Prioritization

Disputed requirements are prioritized to identify

critical requirements and to help the decision
making process
1st Technique – Prioritization Scales

 Determine criteria, granularity, scale dimensions

 Frequently used:
 Urgency
 High (mission critical requirement; required for next release)
 Medium (supports necessary system operations; required
eventually but could wait until a later release if necessary)
 Low (a functional or quality enhancement; would be nice to
have someday if resources permit)
 Importance
 Essential (product unacceptable unless these requirements are
satisfied)
 Conditional (would enhance the product, but the product is
acceptable if absent)
 Optional (functions that may
or may not be worthwhile)
Prioritization Based on Cost and
Value

 Calculate return on investment by

 Assessing the value of each requirement
 Assessing the cost of each requirement
 Calculating the cost-value trade-offs

 Difficulties:
 Hard to calculate absolute value/cost
 Interdependent requirements difficult to treat
individually
 Inconsistencies or conflicts in priorities assigned by
individual stakeholders
2nd Technique – Wiegers’
Prioritization

 Semi-quantitative analytical approach to requirements

prioritization based on value, cost, and risk
 Relies on estimation of relative priorities of requirements
 Dimensions
 Relative benefit (for having requirement)
 Relative penalty to stakeholder (if requirement is not included)
 Relative cost (to implement requirement)
 Relative risk (technical and other risks)
 Each dimension is given a value on a given scale (e.g., 0..9)
 Dimensions have relative weights
 Formula used to derive overall priority
 priority = (value%) / ((cost% * cost weight) + (risk% * risk
weight))
 Still limited by ability to properly estimate
 Wiegers’ Prioritization Example
 Chemical tracking system

Source: Wiegers, Karl E., First Things First: Prioritizing Requirements, http://www.processimpact.com/articles/prioritizing.html
Volere Prioritization

 Volere Prioritization is a method for

prioritizing requirements based on their
importance to the stakeholders and the overall
project objectives. This method helps teams
determine which requirements should be
implemented first and which can be deferred,
based on a set of defined criteria.
 3rd Technique – Volere Prioritisation
Requireme
nt/Product Factor - Factor - Factor - Factor -
Numbe %Weight %Weight %Weight %Weight
Use score out score out score out score out
r applied applied applied applied
Case/Featur of 10 of 10 of 10 of 10
e
Minimise
Value to 40 % Ease of 30% =
Value to 20% = Impleme 10% = Priority
Custome Impleme
r =0.4 Business 0.2 ntation 0.1 ntation 0.3 Rating
Cost
Require
1 2 0.8 7 1.4 3 0.3 8 2.4 4.9
ment 1
Require
2 2 0.8 8 1.6 5 0.5 7 2.1 5
ment 2
Require
3 7 2.8 3 0.6 7 0.7 4 1.2 5.3
ment 3
Require
4 6 2.4 8 1.6 3 0.3 5 1.5 5.8
ment 4
Require
5 5 2 5 1 1 0.1 3 0.98 4
ment 5
Require
ment 6
6 9 3.6 6 1.2 6 0.6 5 1.5 6.9
Require
7 4 1.6 3 0.6 6 0.6 7 2.1 4.9
ment 7 Editable Excel document
Require
ment 6.9
Source: Volere Prioritisation Analysis, http://www.volere.co.uk/prioritisationdownload.htm
Basic Rating Procedure (BRP)

 The Basic Rating Procedure (BRP) is a

simple and widely used method for prioritizing
requirements in software development or
project management.
Basic Rating Procedure (1)

 Pairwise comparison rating scale

Values 2, 4, 6, or 8 represent preferences

halfway between the integers on either side
Basic Rating Procedure (2)

 Suppose two criteria, cost and quality, for product A & B

 The cost for A is $60 and the quality is above average.
 The cost for B is $15 and the quality is right at average.
 Which product do you choose?

 The matrix describes that the price of B is very strongly

preferred over A and A is only moderately preferred over B
Basic Rating Procedure (3)

 Suppose three products with the following

pairwise comparison (for one given criteria)
 Basic Rating Procedure (4)

 Normalize the matrix

 First add up all the
values in each
column

 Next the values in

each column are
divided by the
corresponding
column sums
 Note: the values
in each column
add up to 1
Basic Rating Procedure (5)

 Average the value of each row to get

corresponding rating
Requirements Agreement

Solutions to the requirements problems are

identified and a compromised set of
requirements are reached. Generally, this will
involve making changes to some of the
requirements