Requirements need to be prioritized because stakeholders can’t always have everything they want, or mwe can’t always give them everything they want. This is because we are faced with a limited budget and time frames.
I need to ensure my focus on the most important requirements
The MoSCoW technique is used by analysts and stakeholders for prioritizing requirements in a collaborative fashion.
Defines a requirement that has to be satisfied for the final solution to be acceptable
This is a high-priority requirement that should be included if possible, within the delivery time frame. Workarounds may be available for such requirements and they are not usually considered as time-critical or must-haves
This is a desirable or nice-to-have requirement (time and resources permitting) but the solution will still be accepted if the functionality is not included
WON’T or WOULD
This represents a requirement that stakeholders want to have, but have agreed will not be implemented in the current version of the system. That is, they have decided it will be postponed till the next round of developments
- Each stakeholder is responsible for assigning priorities to the requirements that fall under their purview
- List all Requirements on a flip chart and prioritise by assigning categories to each
- Voting can be used to reach consensus.
- Present categorized requirements in a readable format
- The requirements should be reviewed throughout the project as stakeholder needs may evolve with time.
8 criteria to be used for assigning priorities to requirements:
- Business Value: Which requirement provides the most business value? The more business value a requirement will deliver, the greater the priority stakeholders may choose to assign to it.
- Business or Technical Risk: Some requirements pose a significant risk of project failure if not implemented successfully. The analyst may assign a high priority to this category of requirements so that if the project does fail, the least amount of effort would have been spent.
- Implementation Difficulty: Which requirements are the easiest to implement? Straightforward requirements may lead to quick-wins and provide an opportunity for the project team to familiarize themselves with other elements of the project before taking on more complex requirements for implementation.
- Likelihood of Success: Which requirements can provide quick-wins and increase the probability of project acceptance? If the objective of the project is to demonstrate value as quickly as possible and quell negative chatter, requirements that have a higher probability of success would be given high priority.
- Regulatory Compliance: Which requirements are necessary for policy and regulation adherence? These requirements are non-negotiable and usually have to be implemented within a set period of time, causing them to take precedence over stakeholder requirements in some cases.
- Relationship to other requirements: Which requirements support other high-value business requirements? Such requirements may be assigned a high priority because of their link to important requirements.
- Urgency: Which requirements have a high degree of urgency? Most stakeholders tend to place a high priority on requirements needed like yesterday
- Stakeholder Agreement: Requirements on which stakeholders disagree should be postponed or assigned a low priority until consensus can be reached on their usefulness.
The above criteria can be used for prioritizing requirements by assigning weights to each requirement using a decision table. Requirements with the highest scores receive greater priority than those with lower scores. Other useful techniques for requirements prioritization are time-boxing and voting.
Source: MOSCOW technique