Software development or any other project facing multiple requirements, budgetary constraints, and tight deadlines often necessitate the need to prioritize stakeholders' requirements. At some point, it’s usually necessary to make decisions on which set of requirements need to be implemented first and which ones can be delayed till a later release.
Numerous methods on how to prioritize requirements have been developed. While some work best on a small number of requirements, others are better suited to very complex projects with many decision-makers and variables. This list of requirements prioritization techniques provides an overview of common techniques that can be used in prioritizing requirements.
When you rank requirements on an ordinal scale, you give each one a different numerical value based on its importance. For example, the number 1 can mean that the requirement is the most important and the number n can be assigned to the least important requirement, n being the total number of requirements. This method works best when you are dealing with a single stakeholder as it can be difficult to align different stakeholders’ perspectives on what the priority of a requirement should be; taking an average can however, address this problem to some extent.
2. Numerical Assignment (Grouping)
This method is based on grouping requirements into different priority groups with each group representing something stakeholders can relate to. For example, requirements can be grouped into critical priority, moderate priority and optional priority. Stakeholders may also classify requirements as compulsory, very important, rather important, not important, and does not matter in order to describe their importance.
These groups should be clearly defined so that stakeholders do not have a different understanding of each during the prioritization exercise. To prevent stakeholders from putting all requirements in one category, the percentage of requirements that can be placed in each group should be restricted. One disadvantage to this, however, is the fact that requirements in each group will then have the same priority with no unique priority assigned per requirement.
3. MoScoW Technique
Instead of numbers, this method uses four priority groups: MUST have, SHOULD have, COULD have, and WON'T have. With this technique, stakeholders can prioritise requirements in a collaborative fashion. The acronym represents the following:
- MUST (Mandatory)
- SHOULD (Of high priority)
- COULD (Preferred but not necessary)
- WOULD (Can be postponed and suggested for future execution)
The decisions of stakeholders on requirements' priorities are categorised as shown above. See MoSCoW : Requirements Prioritization Technique for more on this.
4. Bubble Sort Technique
To prioritize requirements using bubble sort, you take two requirements and compare them with each other. If you find out that one requirement should have greater priority over the other, you swap them accordingly. You then continue in this fashion until the very last requirement is properly sorted. The result is a list of requirements that are ranked.
5. Hundred Dollar Method
This simple method is useful anywhere multiple stakeholders need to democratically vote on which requirements are the most important. All stakeholders get a conceptual 100 dollars, which they can distribute among the requirements. As such, the stakeholder may choose to give all 100 dollars to a single requirement, or the person may distribute the points more evenly. The higher the amount allocated to each requirement, the higher the priority of the requirement. At the end, the total is counted and the requirements are sorted based on the number of points received.
This technique should only be used when you have a small group of requirements to prioritize and when you have the same set of requirements to prevent respondents from influencing their results by assigning more dollars to their favourite requirement.
With this technique, however, it can be difficult to keep track of how much has been assigned and what amount is left to dispose of.
6. Analytic Hierarchy Process (AHP)
This famous requirement prioritization method was designed by Thomas L. Saaty. The method actually describes an entire framework for making correct decisions in fields such as business, healthcare, government, and many others. In essence, stakeholders decompose their goal into smaller sub-problems, which can easily be comprehended and analyzed (in the form of a hierarchy).
Once the hierarchy is built, decision-makers evaluate the elements by comparing pairs to each other. The total number of comparisons recommended with AHP are n × (n-1)/2 (where n is the number of requirements) at each hierarchy level. Participants make judgements (sometimes based on data) about the relative importance of each element. Numerical values (based on priorities) can then be assigned to each element of the hierarchy.
This method is not suitable for a high number of requirements as the number of requirements determine the number of comparisons that need to be made.
7. Five Whys
It often happens that stakeholders want to implement a certain feature for reasons that are not founded on logical arguments or the business interests of the company. With five whys, the analyst asks the stakeholder repeatedly (five times or less) why the requirement is necessary until the importance of the requirements is established. The answers reveal whether the requirement is really necessary or can be cancelled/postponed once the priority is determined.
So, which prioritization technique is best? The one that fits your needs the most and accomplishes your goals in the least amount of time and with a minimal amount of resources. Once you have an idea of which techniques are applicable to your project, you can evaluate them in real life to see how well they perform.
Picture Attribution: Image courtesy of Stuart Miles at FreeDigitalPhotos.net