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.