Requirement Prioritization

Lecture 12

Aamir Anwar
Lecturer CS & IT
University of Lahore, Islamabad Campus
 Need for Prioritization
• When having tens, hundreds or even thousands of alternatives, decision-
making becomes much more difficult
• One of the keys to making the right decision is to prioritize between
different alternatives. It is often not obvious which choice is better, because
several aspects must be taken into consideration
Example:
• Buying a car
• One aspect or several aspects
 Requirements Prioritization
• When developing software systems, similar trade-offs must be made
• The functionality that is most important for the customers might not be as
important when other aspects (e.g. price) are factored in
• We need to develop the functionality that is most desired by the
customers, as well as least risky, least costly, and so forth
• The quality of software products is often determined by the ability to
satisfy the needs of the customers and users
• So, it is very important to include those requirements in the product, which
are really needed by the customers
• Most software projects have more candidate requirements than can be
realized within the time and cost constraints
• Prioritization helps to identify the most valuable requirements from this set
by distinguishing the critical few from the trivial many
 Requirements Prioritization
• Act of giving precedence or priority to one item over another item
• Requirements prioritization means giving precedence to some
requirements over other requirements based on feedback from system
stakeholders
 80-20 Rule
• 20% of functionalities provide 80% of revenues
– Think of MS Word…

• The remaining 80% of functionalities offer a lower return on investment

while adding delays, development costs, maintenance costs...

• How to find the most useful and beneficial 20% of functionalities?

Which Sector Should We Focus On?
 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))
Wiegers’ Prioritization Example
 Wiegers’ Prioritization Example
• For this example, we will use the same weightings Wiegers used in Table 2 of his
original paper. They are: Benefit to Customer is weighted twice as high (2) as Penalty
to Customer (1) and Estimated Cost (1), while Relative Risk is weighted at only half the
value of Estimated Cost (0.5).
• For the WPM example we will use the 1 to 9 scale with a restricted range of 1, 3, 6,
and 9. For each of the criteria, the following are guides to stakeholders for selecting
the correct rating value.
• Relative Benefit
1 = No users would find this feature useful
3 = Some users would find this feature useful
6 = Some users would find this feature very useful
9 = Many users would this feature very useful
 Wiegers’ Prioritization Example
• The percentage values are typically the percentage that the specific row
value is of the total of all values in that column.
• priority = (value%) / ((cost% * cost weight) + (risk% * risk weight))
Using this formula the priority for 1st row will be:
Priority= 8.4% / (4.8% * 1) + (3% * 0.5)
Priority= 8.4% / (4.8 +1.5)
Priority= 1.3%
 MoSCoW Prioritization
• The letters of the word MoSCoW stand for Must, Should, Could and Won’t.
• Must have (or Minimum Usable Subset) – These are features that must be
included before the product can be launched.
Some of the common guidelines for Must haves are as follows:
• Cannot deliver on target date without this data
• Not legal without it (Define it)
• Unsafe without it
• Cannot deliver the Business Case without it
• Should haves are features that are not critical for the launch, but are
considered to be important and of a high value to the user.
• Important but not vital
• Solution viable without the requirement
• Work around available for the requirement.
 MoSCoW Prioritization
• Could haves are features that are nice to have and could potentially be
included without incurring too much effort or cost.
• Wanted or desirable but less important
• Workaround available for the requirement.
• Less impact if left out
• Won’t have - are features that have been requested but are explicitly
excluded from scope for the planned duration and may be included in
a future phase of development.
• The effort allocation for the Must, Should and Could - should comprise
of 60%, 20% and 20% of the total estimated effort.
• MoSCoW method works better than the numeric rating system as it is
much easier for the stakeholders to rate the requirements as Must,
Should, Could or Would.
 Three-level Scale
Eisenhower Decision Matrix
 Three-level Scale
Eisenhower Decision Matrix
• High Priority – These requirements are urgent and important. These are
requirements that are generally with respect to compliance or contract that
cannot be left out. These requirements need to be implemented in the
current release and not implementing the same will have some adverse
effect on the business.
• Medium Priority – These requirements are important but not as urgent.
Implement these after you implement the high priority items. If you see
closely there is a line that splits this quadrant into 2 parts. Implement the
items that are on the right side of the line first as they are relatively of higher
medium priority.
• Do these later – These items are urgent but do not have a lot of effect on the
business. Hence do it after completing the more important medium priority
items. Similar to the medium priority items, this quadrant has also been split
into two; the items on the right side have a higher priority relatively to the
items on the left.
• Low Priority – These items are neither important nor are they urgent.
Complete the items at your leisure after completing the items in sections 4
and 5 respectively.