Requirements Prioritization

Requirements once elicited and approved from the authentic sources are further put for analysis and the first step in the process of requirement analysis is to prioritize the requirements in the order of their implementation. It is mandate for business analysts to prioritize the requirements as it’s a process to add value to the deliverables. The business analyst (or the one seated on the business analyst’s chair) has to consider certain factors while prioritizing the requirements so that the smooth process can be implemented. These factors or aspects which are considered at the time of prioritizing the requirements are: importance, risk, cost, benefit, time, strategy etc. The software development is a set process and the requirements are said to be changing till the final version is deployed in the production environment for the end-users and thus its a challenge for a business analyst to keep track of the requirements and alter the priority with the progress in the development but the decision on prioritizing the requirements depends on the decisions made by the stakeholders involve in the project and business analysts being a liaison between different stakeholders have to co-ordinate the activity.

Why to prioritize the requirements?

Eliciting the requirements and fit them into the releases to develop the functionality is a major step towards the success of the development of the software/project and it’s very important to understand the risk of not prioritizing the requirements. In the words of Frederick P. Brooks, “The highest single part of building a software system is deciding precisely what to build… No other part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later” Thus to mitigate the risk of re-work in the later part of the development, it’s advisable to define the requirements and prioritize them before starting the implementation. In simple words, “No matter prioritization technique is considered simple, medium or difficult it’s a fundamental activity for successful implementation.”

Prioritization Techniques

Requirement prioritization techniques have more pragmatic reference then the theoretical aspects and it differs with the domain and the organizations. Different BAs consider different aspects and follow various approaches in the process of prioritizing the requirements on the premise of different aspects of prioritization. The prioritization techniques are broadly classified into two main categories –

1) Method

2) Negotiation

On one hand if “Method” helps in defining the numerical figures to different aspects and then calculating the aggregate the “Negotiation” on other hand decide the priority after discussing the facts with the stakeholders and thus to final the priority list the stakeholders should be involved with 3 important perspectives –

1) Customers (single or mass-users)

2) Developers (representative from development team)

3) Finance (people with the idea of numerical figures related to cost and revenue)

Apart from the above list the people focusing on strategic importance, risks, time etc. are considered to define the priority of the requirements and thus to choose the right people to decide the priority of the items becomes critical for a BA. She is advised to prepare a list of all the stakeholders and then select the most appropriate ones for the suggestions to complete the prioritization details.

There are several techniques developed and followed by different business analysts to prioritize the requirements, some of them are discussed below:

1.     100-Dollar Test: Also known as cumulative voting and described by Leffingwell and Widrig this technique is pretty simple and straightforward. All the participants are given a constant amount (say 100$) and they have to divide the amount as per their priority list. The higher the amount, higher is the priority. The participants have been given option to devote full amount for 1 requirement and it depends on the intellect of the person who is dividing the amount as per the requirements. There may be a situation that any requirement might not get any amount and thus it is believed that the requirement is not important for the stakeholders but when the decision is to be taken by checking the ratios in different chunks the zero amount requirements in one chunk can corrupt the calculation.  To overcome the situation, some BAs define the baseline and thus every requirement gets at least that baseline amount. Nevertheless in case of bulk requirements this technique can create havoc and confusion to do the calculations.

2.     Top-10 Requirements: This technique provisions the participants to define their top 10 requirements from the set of requirements and later in different brainstorming sessions the list of requirements with their priorities are drafted and documented for further steps. No doubt this process needs so much of discussion and in case of bulk requirements the timeline increases and the biggest threat is to convince the stubborn stakeholders (believe me there are few cases where a participant is adamant for his vote and it becomes a challenge for a BA to convince the lad).

3.     Numerical Assignment (Grouping): Under this technique the requirements are classified into different groups to define the importance. The requirements can be classified as below:

  1. Mandatory (project cannot go live without it)
  2. Very Important (project needs them and customers want them)
  3. Rather Important (customer appreciates the inclusion)
  4. Not Important (Can live without them)
  5. Does not matter (one hardly notices its presence or absence)

This technique was defined by J.W. Brackett in his Software Requirements Technical report in 1990

4.     Analytical Hierarchical Process (AHP): Developed in 1980 by T.L. Saaty, this technique is widely accepted with some customized amendments. However no further improvements or modifications are made in the original theory till date. This technique explains the concept of pairing the requirements and then the same are compared to define the importance of the pairs. This is rather mathematical approach and Saaty explains if there are n requirements total pair should be n*(n-1)/2 and then the analysis should be done. Prima facie, it seems quite regressive as each requirement should be paired and then analyzed but with regular use the approach can be implemented comfortably. It is conducted by comparing all the possible pairs of hierarchy in order to determine which has higher priority usually defined in the range 1-9.

5.     MoSCoW: Latest of all the prioritization techniques, MoSCoW is defined in the IIBA BABOK for business analysts. This technique categorizes the list of the requirements into following segments:

  • MUST (Mandatory)
  • SHOULD (High Priority)
  • COULD (Desired but not necessary)
  • WOULD (Can be delayed and proposed for future releases)

Under this technique the stakeholders’ decisions on requirements are classified into above mentioned categories and then listed in an order of their preference.

Above mentioned are not the only methods used in the prioritization process but there are several other methods used by different BAs to perform the activity. As the requirement management is the continuous process till the project is not in live state (please note the further changes in the requirements come under change management once the project is live), the process of prioritization is also continuous and the priority level of the requirements can be updated with add/update of requirements. Also the results of the prioritization are evaluated in retrospect.

When we grill the requirements both functional and non-functional requirements are considered but the most important aspect to keep in mind is to prioritize the non-functional requirements separately as the abstraction level of these non-functional requirements is not similar to the functional. One can use any of the above mentioned techniques to prioritize these non-functional requirements also.

Happy Reading!!

Any other suggestions on requirement prioritization are welcome!

3 thoughts on “Requirements Prioritization”

  1. Very good points and ideas – all I would add is having a clear, well defined project vision that gives a clear picture of what we want to achieve in the end helps tremendously with prioritising.

    If the project knows where it wants to go, then deciding which requirements are the most important, i.e. contribute the most to reach the desired goal, is much easier.

    Whatever method you use – I prefer MoSCoW with negotiation -, being able to look at the goal and answer the question “How much closer this requirement takes us to our goal?” is a huge help.

    And by picking the wrong requirements you can actually move farther from your goal.

    1. Hi Roland,
      Thanks for your valuable comments.
      And this is true that if we know the expected outcome, the requirements can be prioritized accordingly. Nice point.

Leave a Reply