This provides guidance on prioritising requirements. Links to download the Volere Prioritisation Spreadsheet are towards the end of the text.

Prioritisation Analysis

One problem with requirements is that there are always too
many of them. So there has to be some way of choosing which ones will be
implemented in which versions of the product. The requirements need to be put
into an order of desirability, in other words they need to be prioritised.
Decisions about prioritisation are complex because they involve many different
factors and these factors are often in conflict with each other. Also, as there
are many stakeholders with different goals, it is difficult to reach agreement
about priorities.

1. Prioritization Factors

Factors that commonly affect prioritisation decisions are
some combination of:

Minimise Cost of implementation (how much cost to develop?)

Value to customer (how
much does the customer want it?)

Time to implement (how much time to deliver?)

Ease of technical implementation (how technologically difficult?)

Ease of business implementation (how organisationally difficult?)

Value to the business (how much will the business benefit?)

Obligation to some external authority (necessity to obey law?)

Not all factors are relevant to every project, and the
relative importance of the factors is different for each project. And, within a
project, the relative importance is not the same for all of the stakeholders.
So, given this combinatorial complexity, you need some kind of agreed
prioritisation procedure to provide a way of making choices. Part of that
procedure is to determine when you will make prioritisation decisions.

2. When to prioritise

How soon should you make choices? The answer has to be as
soon as you understand what you have to choose from. The more visible you make
your knowledge, the more possibility you have to make and help others make
informed choices.

2.1 Early

Using the Volere requirements technique, you start by
doing a project blastoff to assess your level of knowledge about the contents
of the first 8 drawers of the Volere template [Rob2]. You do a high-level
context analysis and, using event partitioning, you partition it into business
related chunks. At that point, because you have some identifiable pieces, you
can do a rough prioritisation and give each business event response a priority
rating. Something like High, Medium, Low
will work fine. You can use the results of this prioritisation for deciding
which parts of the business you will investigate first. Also you can use it,
even at this stage, to guide you in version planning.

2.2 Progressively

When you start to write atomic requirements you should
progressively consider whether you can prioritise them. If there are there any
requirements that are obviously Low
value, then tag them L. Use the
idea of Customer Satisfaction and Customer Dissatisfaction [Par1], [Rob1] to
help other people make choices.

Part
of the reason for this progressive prioritisation is expectation management. We
use the term requirements, and people often think that means once they are
written down they will definitely be implemented. What we really mean are
desires or wishes that we need to understand well enough to determine how
and/or whether we can implement them. For example there might be a requirement
that is really high priority but, due to a mixture of constraints, we cannot
meet the fit criterion 100% [Rob1]. However we do have a solution that will fit
85%.

If we have been progressively
talking about prioritisation throughout the project, people are able to accept
the compromise without feeling as if they have been "had". We prepare people
for the idea that we cannot implement all the requirements, but there is no
point in saying this just once. To effectively manage expectations we need to
continue to mention the need for prioritisation and choice.

3. Prioritisation Procedures

Here are some procedures that
you can use prioritise your requirements.

3.1 Customer Satisfaction/Customer Dissatisfaction

This concept was introduced by Pardee [Par1] as a way of helping people to
make choices. Instead of saying "is this high, medium or low priority" he asks
two questions: "On a scale from 1-5 how satisfied will you be if we implement
this requirement" and "On a scale from 1-5 how dissatisfied will you be if we
do not implement this requirement". This helps people to make consider the
requirement rather than just making a binary choice. You can use customer
satisfaction/dissatisfaction ratings as input to determining the requirement
priority grading.

3.2 Requirement Priority Grading

You can grade your requirement priority however it suits
your way of working. A common way of grading requirements is High, Medium
of Low. But you can use any
other grading that suits you.

For
example some people grade requirements by release or version number: R1,
R2, R3.... The idea is that the R1 requirements are the highest priority and are
intended to appear in the first release, the R2 in the second release and so
on.

But
suppose that, after you have tagged the requirements by release you then
discover that you have too many requirements in the release 1 category. At that
point you need to prioritise the release 1 requirements into high, medium and
low.

The
idea of sorting the requirements into 3 categories is often referred to as triage and has been written about by many people in the
software engineering field. Most recently see [Dav1] for a detailed discussion
of applying the idea. In summary, triage is a term that comes from the field of
medicine. When there has been a disaster that injures a number of people there
are usually insufficient resources to treat all the patients. So the doctors
need to categorise the patients into three groups:

Those who will benefit from medical treatment

Those who will live without treatment

Those who will not survive

These groups roughly map to the idea of high, medium and
low prioritisation categories. It is a powerful idea because it makes people
realise that there are many more difficult prioritisation decisions in the
world than prioritising requirements for a product. And, if you work as a team
it is possible to arrive at a decision.

If
your progressive prioritisation using the above ideas still leaves you with
more requirements than will fit into your budget, then you need to go into much
more detail.

3.3 Prioritisation Spreadsheet

You can use a spreadsheet to prioritise the "overflow"
requirements. Ideally, especially if you have done a good job on progressive
prioritisation, these requirements will fit into the Medium or would like if
possible category. In other words you have been able to fit all the High
priority requirements into your budget. If this is not the case then prioritise
the High priority requirements and either drop the Medium and Low or tag them
for future releases.

You can use the downloadable Volere
Prioritisation Spreadsheet as a way of
prioritising requirements. The spreadsheet contains some examples that you can
replace with your own data.

The prioritisation Factors are one or more of the following (or any other
prioritisation factors relevant to your project:

Minimise Cost of implementation (how much cost to develop?)

Value to customer (how much does the customer want it?)

Time to implement (how much time to deliver?)

Ease of technical implementation (how technologically difficult?)

Ease of business implementation (how organisationally difficult?)

Value to the business (how much will our business benefit?)

Obligation to some external authority (necessity to obey law?)

On the spreadsheet I have limited the number of factors to
four. If you are trying to manage more than four prioritisation factors it is very
difficult, if not impossible to come up with an agreed weighting.

The
%Weight is the agreed percentage
importance of a factor. You arrive at the percentage weight by stakeholder
discussion and voting. The total percentage weights for all factors must be
100%

In
column 1 you list the requirements that you want to prioritise. These might be
atomic requirements or they might be clusters of requirements represented by
product use cases, product features or business event responses.

Then
for each requirement/factor combination you give a score out of 10. The score is assigned based on how much
of a positive contribution do you think that this requirement makes to this
factor. For example, for requirement 1we have assigned a score of 2 for the
first factor because we believe that it does not make a very positive contribution
to Value to Customer. On the other hand, the same requirement scores 7 because
we believe it does make a positive contribution to our business. The score for
minimising cost of implementation is 3 because we think this requirement will
be relatively expensive to implement. And ease of implementation scores 8, to
reflect that this requirement will be easy to implement.

For each score, the spreadsheet
calculates a weighted score by applying the % weight for that factor. The priority
rating for the requirement is calculated
as the total of the weighted scores for the requirement.

You
can use a variety of voting systems to arrive at the weights for the factors
and the scores for each requirement. Of course the spreadsheet is merely a
vehicle for making it possible for a group of people to review and arrive at a
consensus for prioritising the requirements. By making complex situations more
visible you make it possible for people to communicate their interests, to
understand other peoples' opinions and to negotiate.

[Dav1] Davis, Alan M The Art of Triage: A Report from the Trenches. University of Colorado Springs, 2002.