Techniques to Prioritize Requirements

Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.

Most customers on their part have a reasonable idea of what they need and what they want. But during requirements elicitation the customer provides the Business Analyst (BA) with all the requirements that he feels will make his work easier. The customer is not wrong on his part; the BA needs to understand the needs of the business to prioritize the requirements.

Prioritization means “Order of importance”. BABOK 3.0 suggests 8 factors that influence the prioritization of requirements.

1. Benefit - It is the advantage that the business accrues as a result of the requirement implementation. The benefit derived can refer to functionality, quality or strategic / business goals.
2. Penalty - It is the consequence of not implementing a requirement. It can refer to the loss in regulatory penalties, poor customer satisfaction or usability of the product.
3. Cost - It is the effort and resources that are required to implement a requirement. A resource can refer to finance, man-power or even technology.
4. Risk - It is the probability that the requirement might not deliver the expected value. This can be due to various reasons ranging from difficulty in understanding the requirement to implementing the requirement.
5. Dependencies - It is the relationship between requirements. As such, a requirement will require the completion of another requirement for its implementation.
6. Time Sensitivity - Everything comes with an expiry date. There has to be mention of what time the requirement will expire or also if the requirement is seasonal.
7. Stability - It refers to the likelihood of the requirement remaining static.
8. Regulatory/Policy Compliance – Those requirements that must be implemented to meet the regulatory requirements.

Prioritizing requirements is fraught with challenges – prioritization of requirements requires a good combination of both analytical and social skills. Most customers will put their foot down and demand that all their requirements be implemented and the do-it all developers would be willing to provide the customer with any feature he desires. But, in reality there are only so many requirements that can be developed because of various constraints such as time, resources, etc. Hence, prioritization is an important activity that defines what goes into the product and what does not.

Whose responsibility is it to prioritize?

Prioritization of requirements cannot be done by the BA alone based on his understanding of the project scope. He needs to bring in various stakeholders into the process and get their agreement on the priority of requirements. The BA can use any of the prioritization techniques to statistically prioritize the requirements. But, before prioritizing the requirements, the BA needs to understand the dependencies between the requirements. Creating a dependency map helps the cause.

The requirements dependency map

Most requirements are interdependent and you will hardly find any requirement that exists independently. To understand why we need a dependency map – let us take a scenario where you have 8 requirements X,Y,Z,P,Q,R,M,O and N with priorities, on a 5- level scale where 1 is most critical and 5 least critical, as 1,2,1,4,5,1,2,2,3. So, with these priorities it would be logical to begin with requirements X, Z and R.

Now, consider the below dependency chart for the above requirements. The chart clearly brings out the idea that we need to complete X before commencing with Y, although X and Y have the same priority levels. Similarly, we need to complete O before commencing R, although when R has higher priority than O.

Figure 1:Dependency Map - In the above requirements dependency map - requirements on the left are the root requirements. Requirements that are connected to the requirements on the left are dependent on them.

Understanding the requirements dependency is as just as important as prioritization. Without understanding the requirements dependency, it is highly unlikely that you will arrive at the right order of requirements implementation. So, it is a good idea to have the requirements dependency map in place before prioritizing the requirements.

There are numerous prioritization techniques that are used in the market today; we have listed some of the more frequently used techniques below:

1. Decision Analysis – Decision Analysis can be traced back to Bernoulli in the 1700s. It was an academic pursuit until the evolution of computers which has made decision analysis possible. Decision analysis is one of the most widely used decision making techniques, from the stock market to the battle grounds, to choose the from the given alternatives. Decision analysis is popular because it provides a scientific approach to arrive at a decision by breaking down the most complex of problems into small manageable problems. There are different types of decision making techniques. In this article I will only touch upon the decision tree technique (it is easier to understand).

A decision tree is a visual analytical tool. It is a flow-chart like structure with 3 different types of nodes -

1. Decision nodes denoted by squares - at these nodes a decision needs to be made choosing among the different alternatives.
2. Chance nodes denoted by circles - these are also called the event node. It is the event that happens when a decision is made.
3. End nodes denoted by triangles are also known as the terminal nodes. This is the final decision point that is arrived at based on various decisions taken.

Other information such as the value, risk, probability, etc. can be added to aid in the computation of the result.

Figure 2: Decision Tree

In the above decision tree the user traverses from the left to right. The user needs to make a decision at A, B, C and to choose from the alternatives, 1, 2, 3, 4, 5, and 6. Based on the decisions that the user makes the user gets to points @, $, #, %.

Decision tree is popular as value, risk, probability, etc., can be set against each of the alternatives and the same be analyzed statistically. The statistical analysis will provide us with insights to make the best decision possible with the present understanding of requirements.

2. MoSCoW – This prioritization technique was developed by Dai Clegg of Oracle UK Consulting, who later donated the intellectual rights to Dynamic Systems Development Method (DSDM) Consortium. Though the technique has been criticized for its lack of clarity in distinguishing the priority of requirements, it is one of the more widely used techniques for its simplicity and ease of use. 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.

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

Should and Could are differentiated by the relativity of importance. The ones that have higher business impact are categorized under Should.

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.

As a BA, challenge the Must have requirements and try pushing them in any of the other categories. 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.

3. Three-level Scale – When a BA categorizes the requirements in any of the ordering or ranking scale, it is subject to the analyst’s understanding of the business. Many analysts suggest that this method has some drawbacks and advocate methods that have more than one scale.

Covey, Rebecca and Merrill would have never in their wildest dreams have thought that their “The four-quadrant 'Eisenhower Decision Matrix' for importance and urgency”, from their self-help book First things First, would become one of the most widely used prioritization techniques in the IT space.

Figure 3: Eisenhower Decision Matrix – Lower the number, higher the priority of the section.

With the numbering on the different sections of the diagram, the priority of the sections is implicit. Important items have the highest preference, while urgent items have lower preference.

1. 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.
2. 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.
3. 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.
4. 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.

The items on the right hand side of the diagonal have higher priority. Start with the bottom-right corner of the high-priority quadrant and work your way up and left.

4. Timeboxing/Budgeting – Timeboxing or fixed budgeting process is used when there are fixed timelines/budgets to achieve the project milestones. Timeboxing is used in projects that are constrained by deadlines where the delivery of the project is as important as the project being delivered on time or being developed within the budget.

This technique is based on the premise that it is more important to have at least the basic product features and release the product on time rather than having all features and launching the product at a later date. Miranda, Program Director, Ericsson Research Canada, in her paper proposes 2 points of estimate – the normal completion effort and the safe completion effort. The normal completion effort is the happy case scenario of requirement being developed while safe completion effort is the estimation based on the worst case scenario.

In Timeboxing, which is the refined version of MoSCoW analysis, the requirements are grouped into small subsets that can be called wholly; these are given relative importance and the time schedule required for implementation. The idea is to move the more important features or Must, Should and Could to earlier phases of implementation to ensure completion of more important features at the time of product launch.

This method is highly used in agile projects as it helps in identifying the more important features and it works very efficiently for iterative approach.

According to BABOK V2, there are 3 approaches that may be used for determining the requirements to include in iteration:

• All In – Include all the requirements necessary for the solution to be developed and then remove/postpone the requirements whose implementation will cause the project to miss the deadline.
• All Out – Exclude all the requirements for a start and then include the ones that can be implemented within the constrained time schedule.
• Selective – Identify the high priority requirements and then add or remove requirements to meet the deadline.

5. Voting – This is the simplest way to prioritize the requirements. When there are too many requirements that need to be categorized into different categories with inputs from different stakeholders, voting is one of the best ways to sort out the prioritization of requirements. I will suggest the voting technique that worked for me in one of the projects I was managing.

In this method we gathered all the stakeholders in a room (others not physically provided were looped in through a call) and each of the stakeholder was given points(say 200, 100, 50 based on the stakeholder’s importance ) to vote on each of the requirement that had to be incorporated. Then we ran through over 400 requirements on which the stakeholders voted. The requirements with the highest points were chosen for implementation in the first iteration.

Care has to be taken while putting out the requirements to vote such that the requirements are grouped in a logical manner and that the stakeholders are voting on a requirement that can be delivered in entirety. The entire process took a day but it worked out really well.

Concluding remarks

• Prioritization is one of the most important stages in the requirements analysis stage. Involve the stakeholders for better categorization and prioritization of requirements.
• Analyze the requirements and understand the effect of different factors listed above on the requirements.
• Choose the requirements prioritization technique that best suits your need and start prioritizing your requirements.
• Challenge the importance of requirements. Lower the priority the better it is.

Business analysis is all about taking the most complex of requirements and breaking it down to simple problems that can be implemented by anyone.

Author: Anand Krishnan, Associate Consultant, Maveric-Systems

A core banking consultant working with Maveric-Systems with over 4 years of experience in requirements elicitation, requirements design and product development. His primary areas of interest are payments, channels and emerging technologies such as mobile and cloud.
Prior to joining Maveric-Systems he obtained his Masters in Business Administration from Great Lakes Institute of Management.

For information on Requirements Assurance at Maveric Systems, visit http://maveric-systems.com/program-assurance_requirement-assurance.html or write to us at [email protected]