Transcript Requirements analysis and negotiation

Requirements Engineering
Chapter 3
Requirements Analysis,
Negotiation and Modeling
Part 2
Dr. Eman Al-Maghary
Analysis and Negotiation
 Analysis – the process of evaluating value/cost of different
requirements, identifying dependencies between requirements, etc.
 Negotiation – the process of resolving conflicts between
requirements, deciding which to accept, setting priorities.
2
Requirements Analysis
 The goal of analysis is to discover problems,
incompleteness and inconsistencies in the elicited
requirements
 Input - A draft system requirements document
 Output –A set of problematic requirements
 A problem checklist may be used to support analysis
3
Analysis checklists
 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 include more than 10 items (in
general)
4
An example Checklist for Individual
Requirements
 Premature design: Does the requirement include
premature design or implementation information
 Combined requirements: Does the requirement
description describes a single requirement or can be divided
into several different requirements.
 Unnecessary requirements: Is the requirement a
cosmatic addition, which is not really needed by the system
 Use of non-standard hardware: Does the requirement
mean that non standard hardware or software must be
used.*
5
An example Checklist for Individual
Requirements
 Conformance with business goals: Is the requirement
consistent with business goals defined in the
introduction of the requirements document.
 Requirements ambiguity: What are the possible
interpretations of the requirement?*
 Requirements Realism: Is the requirement realistic given
the technology which will be used to implement the system?
 Requirements testability: Is the requirement testable?
That is, can the system engineers derive a test which can
show if the system can meet that requirement?
6
Requiremnts interaction:
Conflict and Overlap
 Conflict: negatively affect each other
 Overlap: affect each other but not necessarily a
conflict
 Example
R1: The file server shall respond to requests within 0.5
seconds
R2: The file server shall serve up to 200 connection
simultaneously
Conflict: The file server HW resources may prevent
requirement from being satisfied simultaneously
7
R3:“the file server shall allow logged in users of storing
up to 2GB of data daily(total)”
R4: “the file server shall allow each logged in user to
store up to 20MB of data daily”
Overlap no conflict, they affect each other, R5 might be
extracted
R5: the file server shall allow up to 100 users to login
daily
8
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
9
Example of an interaction matrix
Requirement
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
Interaction matrices only work when there is a
relatively small number of requirements ( not more
then 200 requirements)
10
The advantage of using numeric
values for conflicts and overlaps
 The sum of each row and each column give
1. the number of conflicts: the reminder when
dividing the total by 1000
2. The number of overlaps the total when dividing
by 1000
 A large number of conflicts or overlaps means that
changing a requirement has a great impact on the rest
of the system
11
Requirements negotiation
 The goal requirements negotiation is to reach
agreement on changes to satisfy all system
stakeholders.
 Requirements negotiation stage involves the different
stakeholders to solve the conflicts and overlaps and
agree on a set of requirements
 Conflicts are not ‘failures’ but reflect different
stakeholder needs and priorities
 Input –a set of conflicting or overlapped requirements
 Output –a compromised set of requirements
12
Requirements negotiation (Cont.)
 Negotiation is interleaved with elicitation and analysis
as problems are discovered and possible solutions are
agreed when the requirements are elicited
 Finding an acceptable compromise can be timeconsuming
13
Negotiation goals
 Three basic goals of requirements negotiation:
 To make the conflicts explicit.
 To make explicit, for each conflict, the relevant
alternatives, the argumentations, and the underlying
rationales.
 To facilitate in that “right” decisions are made.
 “Right” decision here denotes a decision made
rationally, decision made based by evaluating the
alternatives and selecting the best one.
14
Requirements analysis and negotiation
Requirements Analysis
Necessity
Checking
Consistency and
completeness
checking
Necessity
Checking
Unnecessary
requirements
Conflicting and
incomplete
requirements
Infeasible
requirements
Requirements
discussion
Requirements
prioritisation
Requirements
agreement
Requirements Negotiation
15
Negotiation meetings
 Meetings are an effective way to negotiate
requirements and resolve requirements conflicts
 All conflict requirements should be discussed
individually
 Participants
 Analysts who have discovered requirement overlaps,
omissions and conflicts
 Stakeholders who can help resolve the discovered
problems
 An independent chairman
16
Three stages of the negotiation meeting
1.
Information stage
Nature of the problems associated with a requirement is
explained
2. Discussion stage
 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
17
Three stages of the negotiation meeting
3. Resolution stage
 Actions concerning the requirement are agreed



Delete the requirement
Suggest specific modifications
Elicit further information about the requirement
18
Why prioritize requirements?
 Limited resources
 Customer
expectations are
high
 Schedule
 Budget
 Effort
 Too many Reqs
 Changing Reqs
Resources
Requirements
 Conflicting Reqs
All requirements are mandatory, but some are
essential/critical while others are not.
19
Prioritization
 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 at the
requirements analysis and negotiation stage
20
Challenges of prioritization
 Different stakeholders have usually different opinions
about requirement’s importance and urgency.
 People naturally have their own interest and they aren’t
always willing to compromise their needs for someone
else’s benefit.
 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
 Many of the prioritization methods are either too
complicated and time consuming or insufficient
21
Prioritization techniques
 Prioritization scales
 Assign each requirement to a priority classification
category
 Example categories: high, medium, low
 Prioritization model - cost-value approach
 Analytic Hierarchy Process (AHP)
 value, cost, and risk estimation model
 Kano method
 Other approaches
 Quality function deployment (QFD)
 Total quality management (TQM)
22
Requirements prioritization scales
 Two dimensions: Importance & Urgency
 High priority (I & U)
 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
23
Requirements prioritization scales (Cont.)
 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 –Don’t
waste your time
24
Summary of prioritization scales
 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
25
Prioritization model
 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 requirement’s attractiveness is directly proportional to the
value it provides and inversely proportional to its cost and the
technical risk associated with implementing it
26
Steps to use the prioritization model
1.
List all requirements (features or use cases) needed
to prioritize
 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 (very 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 / Σ(total value))
27
Steps to use the prioritization model (Cont).
5. Estimate the relative cost of implementing each
requirement on a scale of 1 (low) to 9 (high)
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
28
risk
Example and Template
You can download the MS Excel template from the web site.
29
 Value% = value/ sum of values * 100
 Cost% = Cost/ sum of Costs * 100
 Risk% = risk/ sum of Risks* 100
 Priority for the requirement in row 1
 Priority =
5.2
2.7 *1  3 * 0.5
 Priority = 1.2
30
Summary of the prioritization model
 Use the calculated priority sequence only as a
guideline
 The accuracy is limited by people’s 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
31
A Five-step procedure by using Kano
method
Identify the customer requirements
2. Construct a questionnaire (e.g. roller shutter control
feature)
1.
 Functional questions

e.g. Suppose that your HAS could open and close roller
shutters automatically, what would you think about that?
 Dysfunctional questions

e.g. … … would not be able to ……
3. Perform a survey
4. Analyse and interprete the collected data
5. Select the product features
32
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
33
Prioritization considerations
 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
34
Key points
 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
35
Key points (Cont.)
 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
36