|
Vesa Purho
Development Manager, Nokia
In the last two articles, I have discussed defining requirements. Normally, you
cannot actually implement all the requirements due to budget constraints. Therefore,
you need to have some method to prioritize the requirements. Hopefully, your method
is not "whoever speaks the loudest and is the most active gets their requirements implemented."
The requirements can be viewed from many different angles depending on what you
are designing. The cost of implementation is always an issue, unless you have unlimited
budget. But other factors may not get analyzed enough because they are not as concrete
as money. Even in thinking about the implementation cost, one may neglect the cost of
testing, documentation, and training of a particular feature. These might add to the cost
significantly. The other factors you should consider when prioritizing the requirements
relate to the benefits the system brings to the users. If you are designing a documentation
system, you have two user groups for it: the authors and others who use the system to create
documentation, or other training and information products; and the users of the information
products who expect certain features such as search engines, linking, indexes and so on,
to be implemented.
When analyzing any complex issue, your analysis needs to be simplified so
that it can be handled and discussed in a meaningful way as opposed to just
speaking about opinions. One often-used method is to create a two-dimensional
matrix and place the objects to be analyzed in it. A matrix is also an effective
method to prioritize requirements. Naturally, there are always some base requirements
that need to be implemented in any case. Those base requirements can be left out
of the analysis but you should prioritize the borderline cases.
For documentation systems, the dimensions of the matrix could be "improves
the efficiency of creating documents" and "adds value to the customer." Efficiency
can be either expressed in terms of money, if you can estimate how many hours can be
saved compared to the current ways of doing things or, in a more rough way as a scale
low, medium, high. The other dimension (adds value) can usually be estimated only on a
rough scale because it is very difficult to evaluate that kind of value in terms of money.
It is not so important that you actually get the exact absolute values because you are
only comparing the requirements against each other. It is more important that you evaluate
each individual requirement in relation to the others. You would get a matrix something
like the following:
It is also possible to add the cost of implementation to the matrix.
For example, you can represent each requirement with a circle. The size of the
circle indicates the cost.
One of the first decisions you have to make is whether you put more value on
the customer benefits or the internal cost savings. The decision depends on
your company's general situation and your competitive strategy. If you are
competing on price, then the cost savings naturally have more value, but if
you are competing on quality, or perceived added value, the customer benefits
are more important. In any case, the highest priority requirements would be
those that both add value to the customer and improve cost efficiency (and
those that are the cheapest to implement). The second priority requirements
would then be either the ones that save costs but do not add much value for
the customer or add value for the customer but do not save much. The requirements
that should be looked at very critically are the ones that save costs the least and
do not add much value to the. Are they really needed at all or are they just "nice
to have" features that you could easily live without, especially if the implementation
costs are high.
There are many ways to look at requirements. Some might think that
putting them in a two-dimensional matrix is an oversimplification. Nonetheless,
it is a good way to look at the important aspects and to bring some structure to
the discussion so that the decisions are not based only on people's opinions.
This article is the personal opinion of the author and does
not necessarily reflect the opinion or practice of Nokia.
|
