Prioritisation means setting relative values on different requirements.
Its purpose is to ensure that the most necessary items are obtained (first) even if resources are insufficient to meet all the requirements.
For simple projects it may be enough to have a single priority value on each requirement. This may be as basic as an IN/OUT List.
More generally, projects need 2 kinds of priority:
| Technique | Purpose | Suitable Tools | Procedure | Risks |
|
Triage = IN/OUT List |
Identify what you really need, and really don't | Spreadsheet, Table, or Database with minimum of 3 columns/fields: ID, Requirement Text, Priority |
1) Mark as IN all requirements that are obviously
essential for the system to work. 2) Mark as OUT all proposed requirements that are obviously not needed. 3) Prioritise the rest (see below). |
Could unwittingly axe essential but
non-obvious requirements unless Dependency Clustering is in
place to protect them. Rework, if triaged-out requirements are physically deleted. It is better to mark them as OUT and to record the reason why. Decisions may be revisited if conditions change. |
|
"MoSCoW" = Basic Stakeholder Prioritisation |
Set simple input priorities only | as above. |
Populate the Priority column with values agreed by
Stakeholders, from a list
such as: M = Must have it (= Essential, IN) S = Should have it (= Desirable) C = Could have it (= Possibly Useful) W = Would like it (= Nice to have) – = Not needed (= Luxury, OUT) |
Stakeholders may mark everything as
Essential. Stakeholders may disagree on values. Input priorities may not translate directly into a sensible project plan. |
|
Priority + Phase/ Release = This Year, Next Year, Sometime, Never |
Set input and output priorities | as above, with extra column for Phase/Release (or, a separate column for each phase) |
As above, then identify which requirements must be included in
Release 1, Release 2, etc.
Allocation of requirements to releases may demand Dependency Clustering. The technique is readily adapted for handling requirements for Product Families (shared requirements within Product Lines). |
|
| Dependency Clustering | Identify which requirements must go together, which must be first |
as above, with a column for Dependencies (representing links). Dependency links (in a requirements database). |
There are 2 basic approaches: A) Capture scenarios or use cases describing how the requirements fit together. All steps needed within a scenario form a dependency cluster and must be implemented together to realise the goal of the scenario. B) Identify pieces of infrastructure (eg computer network) needed by the (most important) requirements. If you have a tool able to make dependency links (Traceability), then link each requirement to the items it depends on. Ensure the key pieces of infrastructure (those that a critical requirement depends on) are implemented in the earliest Releases. |
Wasting time when the priorities are obvious. See Triage above. |
| Key Requirement | Identify the essence of the system under design | as above, with a column for a "Key" flag. | List the 7 things your system absolutely must have to be viable at all. Mark those as "Key". Implement those at all costs. Implement whatever else is necessary to attain those goals. | (Does not address the issue of comparing subsidiary/minor requirements, eg change requests) |
| Value-Oriented Prioritisation Matrix | Identify the most valuable changes | Spreadsheet matrix of Requirements (Y-axis) vs Core Business Values and Risks (X-axis) |
1) Agree (in a workshop) the core values in your business, eg
reputation for reliability, total sales, customer loyalty. You
should not have more than about 7 of these. 2) Agree a relative weight for each core value, eg reputation = 8, loyalty = 10. 3) Agree (in a workshop) the risks that drive the product business, eg technical and commercial. Again, keep the number of driving risks small. 4) Agree a (negative) relative weight for each driving risk, eg technical = -9, commercial = -5. 5) Score each requirement on each of the core values and driving risks. 6) Multiply the scores by the weights and sum the results to give a final score for each requirement. 7) Sort the requirements by final score. |
(c) Scenario Plus 1997-2007