You are here

Requirements prioritization

7 September, 2015 - 14:40

It is impossible to satisfy all the requirements that a group of users and other stakeholders may come up with, especially if you are doing iterative development. The decision to include one set of requirements and not another is difficult. First, different stakeholders are interested in different results. Second, two requirements may be mutually contradictory; for example, higher performance may require more powerful hardware at greater cost. Third, some requirements may need to be satisfied before others can be implemented. The process needs to be seen as both fair and responsive to stakeholders’ wishes.

In some cases, a straightforward economic analysis such as return on investment may be the right approach. This usually works best for requirements in the aggregate and less well for each detailed requirements. The difficulty is tying each individual requirement to a specific benefit and a specific cost. It is also a tedious job when the number of requirements is large. Thus, a prioritization scheme based on pure economics is best suited for the big-bang approach to systems development.

A similar approach, but based on risk (highest risk first) is appropriate for the prototyping approach to very innovative projects.

An alternative approach is Quality Function Deployment. This approach (introduced by Toyota in the 1970s to improve their process for designing automobiles) 1 sets up a series of matrices describing how well each requirement contributes to fulfill each business objective, then how each design feature (developed at a later stage) implements each requirement, and so on, thus illustrating qualitatively where the most benefit will be had. The unique part of this approach is that a group of stakeholder is asked to rank features pairwise – “I prefer B to A, C to B, C to E....” The end result is a series of ranked requirements where all the participants feels that their voice has been heard, thus helping to build consensus.