Software Requirement Engineering

Prioritizing the requirements

Prepared By
Mehak Usmani

Reference: 1
Software Requirements, Third Edition, Karl Wiegers and Joy Beatty
Objectives
You will learn;
• Need of Prioritizing the requirements
• Prioritizing Pragmatics
• Techniques

2
Prioritization
• Prioritization, also called requirements triage helps reveal competing
goals, resolve conflicts, plan for staged or incremental deliveries, control
scope creep and make the necessary trade-off decisions
• Few software projects deliver all the capabilities that all stakeholders want
by the targeted initial delivery date.
• Every project with resource limitations needs to define the relative
priorities of the requested product capabilities.

3
Why prioritize requirements?
• When customer expectations are high and timelines are short, you need
to make sure the product delivers the most critical or valuable
functionality as early as possible.
• Prioritization is a way to deal with competing demands for limited
resources.
• Establishing the relative priority of each product capability lets you plan
construction to provide the highest value at the lowest cost.
• Prioritization helps the project deliver the maximum business value as
quickly as possible within the project constraints
• Because prioritization is relative, you can begin prioritization as soon as
you discover your second requirement.
• Sometimes customers don’t like to prioritize requirements, thinking that
they won’t ever get the ones that are low priority

4
Some prioritization pragmatics
• Even a medium-sized project can have dozens of user requirements and
hundreds of functional requirements, too many to classify analytically and
consistently.
• To keep it manageable, choose an appropriate level of abstraction for the
prioritization—features, use cases, user stories, or functional
requirements.
– Within a use case, some alternative flows could have a higher priority
than others.
– You might decide to do an initial prioritization at the feature level and
then to prioritize the functional requirements within certain features
separately.
• This will help you to distinguish the core functionality from refinements
that can be deferred or cut entirely

5
Some prioritization pragmatics
• Various stakeholders need to participate in prioritization, representing
customers, project sponsors, project management, development, and
perhaps other perspectives.
• You really need one ultimate decision maker when stakeholders can’t
agree.
• The prioritization can include considerations of customer value, business
value, business or technical risk, cost, difficulty of implementation, time to
market, regulatory or policy compliance, competitive marketplace
advantage, and contractual commitments (Gottesdiener 2005).

6
 Six issues
Alan Davis (2005) indicates that successful prioritization requires an
understanding of six issues

1. The needs of the customers

7
Deciding priorities
• Customers place a high priority on those functions that provide the
greatest business or usability benefit. However, after a developer points
out the cost, difficulty, technical risk, or trade-offs associated with a
specific requirement, the customers might conclude that it isn’t as
essential as they first thought.
• The developer might also decide to implement certain lower-priority
functions early on because of their effect on the system’s architecture,
laying the foundation to implement future functionality efficiently without
major restructuring.
• As with all aspects of requirements development, the overarching
business objectives that led to launching the project in the first place
should drive priority decisions.
• Certain requirements must be implemented together or in a specific
sequence

8
Games people play with priorities
• The response to a request for customers to set priorities sometimes is,
“I need all these features. Just make it happen.”
• Customer feel that every requirement should be ranked as high priority,
and they might not recognize that prioritization will help to ensure the
project’s success.
• Explain to customers that all things cannot be done simultaneously, so you
want to make sure you work on the right things first
• If customers are given a chance to set priorities, they will establish
perhaps 85 percent of the requirements as high priority, 10 percent as
medium, and 5 percent as low.
• If all requirements truly are of top priority, your project has a high risk of
not being fully successful.
• Scrub the requirements to eliminate any that aren’t essential and to
simplify those that are unnecessarily complex.

9
Games people play with priorities
• Priority categories can be adopted as “high,” “super-high,” and “incredibly
high.” to satisfy customers.
• In reality each project delivered just a single release. Consequently, the
stakeholders all knew that they only had one shot to get all the
functionality they needed. Every requirement, therefore, became high
priority, overloading the team’s capacity to deliver

10
Games people play with priorities
• One study found that nearly two-thirds of the features developed in
software systems are rarely or never used (The Standish Group 2009).
• To encourage customers to acknowledge that some requirements have
lower priority, the analyst can ask questions such as the following:
– Is there some other way to satisfy the need that this requirement addresses?
– What would the consequences be of omitting or deferring this requirement?
– What effect would it have on the project’s business objectives if this
requirement weren’t implemented for several months?
– Why might a customer be unhappy if this requirement were deferred to a later
release?
– Is having this feature worth delaying release of all of the other features with
this same priority?

11
Some prioritization techniques
• Different techniques have been proposed to assist with requirements
prioritization.
• These methods involve 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
– In or out
– Pairwise comparison and rank ordering
– Three-level scale
– MoSCoW
– $100

12
In or out
• The simplest of all prioritization methods is to have a group of
stakeholders work down a list of requirements and make a binary
decision: is it in, or is it out?
• Keep referring to the project’s business objectives to make this judgment,
paring the list down to the bare minimum needed for the first release.
Then, when implementation of that release is under way, you can go back
to the previously “out” requirements and go through the process again for
the next release.

13
Pairwise comparison and rank ordering
• Rank ordering a list of requirements involves making pairwise comparisons
between all of them so you can judge which member of each pair has
higher priority.
• Pairwise comparison of quality attributes using Spreadsheet could be
applied to a set of features, user stories, or any other set of requirement
• Grouping requirements into features, or into small sets of requirements
that have similar priority or that otherwise must be implemented
together, is sufficient.

14
Three-level scale
• A common prioritization approach groups requirements into three
categories; high, medium, and low priority.
• Such prioritization scales are subjective and imprecise. To make the scale
useful, the stakeholders must agree on what each level means in the scale
they use
• Consider the two dimensions of importance and urgency

15
MoSCoW
• Must: The requirement must be satisfied for the solution to be considered
a success.
• Should: The requirement is important and should be included in the
solution if possible, but it’s not mandatory to success
• Could: It’s a desirable capability, but one that could be deferred or
eliminated. Implement it only if time and resources permit.
• Won’t: This indicates a requirement that will not be implemented at this
time but could be included in a future release

The MoSCoW scheme changes the three-level scale of high, medium, and low
into a four-level scale.
It doesn’t offer any rationale for making the decision about how to rate the
priority of a given requirement compared to others.

16
100$
• Give the prioritization team 100 imaginary dollars to work with.
• Team members allocate these dollars to “buy” items that they would like
to have implemented from the complete set of candidate requirements.
• They weight the higher-priority requirements more heavily by allocating
more dollars to them.
– If one requirement is three times as important to a stakeholder as
another requirement, she would assign perhaps nine dollars to the
first requirement and three dollars to the second. But 100 dollars is all
the prioritizers get
• when they are out of money, nothing else can be implemented, at least
not in the release they are currently focusing on.

17
Prioritization based on value, cost, and risk
• When the stakeholders can’t agree on requirement priorities through the
other relatively informal techniques, it might be useful to apply a more
analytical method.
• A definitive way to relate customer value to proposed product features is
with a technique called Quality Function Deployment, or QFD
• This approach distributes a set of estimated priorities across a range,
rather than grouping them into just a few discrete levels.
• A feature’s attractiveness is directly proportional to the value and
inversely proportional to its cost and the technical risk
• Apply this prioritization scheme to flexible requirements, those that aren’t
obviously top priority.

18
Prioritization based on value, cost, and risk
• This scheme borrows from the QFD concept of basing customer value on both
– the benefit provided to the customer if a specific product feature is
present and
– the penalty paid if that feature is absent.
• The cost can be low (quick and easy) or high (time-consuming and expensive),
technical risk is the probability of not getting the feature right on the first try
• By default, the benefit, penalty, cost, and risk terms are weighted equally but
can also be modified.
– All benefit ratings can be weighted twice of penalty ratings, penalty and cost are
weighted the same, and risk has half the weight of the cost and penalty terms. To
drop a term out of the model, set its weight to zero.
• Features with the highest risk-adjusted value/cost ratio should have the
highest priority.

19
Prioritization based on value, cost, and risk
Follow these steps to use this prioritization model
1. List in the spreadsheet all the features, use cases, use case flows, user
stories, or functional requirements that you want to prioritize
2. Have the customer representatives estimate the relative benefit and
penalty of each feature on a scale of 1 to 9
3. Calculates the total value for each feature as the sum of its benefit and
penalty scores and the percentage of the total value
4. Have developers estimate the relative cost and relative technical (not
business) risk involve in implementing each feature on a scale of 1 to 9
5. Calculate a priority value for each feature by

6. sort the list of features in descending order by calculated priority,

20
Prioritization based on value, cost, and risk

21
Participants in the prioritization
• Typical participants in the prioritization process include:
– The project manager or business analyst, who leads the process,
arbitrates conflicts, and adjusts prioritization data received from the
other participants if necessary.
– Customer representatives, such as product champions, a product
manager, or a product owner, who supply the benefit and penalty
ratings.
– Development representatives, who provide the cost and risk ratings

22
Review Questions
Question 1:
Why requirements should be prioritized?

Question 2:
What are the six issues necessary for successful prioritization?

23