How writing better requirement details drives software purchase success

When developing requirements for a major software purchase, two questions that come up are 1) How much detail should the requirements list contain? and 2) How much detail should there be in each requirement description? Where a previous article examined the different parts of a requirement, this article focuses on how to write better requirement descriptions. For an idea of how detailed requirement descriptions themselves should be, we must first examine why description detail is important and where it is used. Then we can look at how to write good requirement descriptions.

Why description detail is important

By analogy, compare a list of requirements to directions for a journey. Have you ever followed directions and yet not arrived at the desired destination? The problem can happen because directions are at too high a level; there are unexpected detours along the way, you get lost and so on. Sometimes when you arrive, the place is not what was expected, and you abandon the trip.

The problem is similar when purchasing software: you want to realize cost savings from improved efficiencies and the benefits that flow from the new functionality. You want the implementation project to be within budget, on time and with a minimum of business disruption. Well-written requirement descriptions play an important part in achieving this.

Where requirement descriptions are used

The most efficient way to gather requirements is first to develop the list, and then have users rate those requirements for importance to the organization. Sources of requirements can be purchased lists, libraries or reverse engineering requirements from the features of potential products.

When deciding how much detail a requirement description should contain, it is not necessary to go to the level needed for writing software. (If you later decided that you were going to build rather than buy, those requirements would need to be amplified.) While development detail is unnecessary for purchasing software, it is very important to keep in mind where requirement descriptions will be used.

1) Rating requirements for importance

The first place requirement descriptions are used is when rating requirements for importance. Here the requirement defines what is wanted, and the organization captures who wants it, why they want it, and how important it is to them. A well-written requirement description makes this importance rating process more accurate and faster. For example, when we are working with client teams, they sometimes rate more than 60 requirements per hour.

A vital part of having users’ rate requirements for importance is that it builds user buy-in. When employees see their names written on the requirements, they feel the organization is listening to them and considering their needs, and that builds the buy-in.

2) RFI / RFP responses

The second place requirement descriptions are used is when a vendor responds to an RFI / RFP. When vendors see an ambiguous or poorly worded requirement, they interpret it in a way that favors them rather than the buyer. Inaccuracies on RFI / RFP responses at the very least can lead to unmet expectations from users. At worst they may result in the wrong software being selected although auditing RFI / RFPs can prevent this.

3) Software implementation

The third place requirement descriptions are used is when the software is being implemented. Write enough detail so that, when combined with the importance rating and the reasons for that importance, the consultants implementing that requirement in the new software have all the information they need.

For example, if the selected software must be configured to meet that requirement, there should be enough detail in the description so the consultant can do the implementation without needing to ask any further questions.

4) Acceptance testing

The fourth place requirement descriptions are used is for acceptance testing. They should be written so that an acceptance test can be quickly developed to verify that the software unambiguously meets that requirement. The ability to measure how well software meets requirements can help avoid problems like lawsuits with implementation consultants. The only winners in such lawsuits are the lawyers.

How to write the requirement description

Write requirement descriptions to satisfy the above four points. When writing a requirement, write what must be satisfied, not how it must be satisfied. It is always a good idea to include examples to explain the context of the requirement. It is acceptable if these include how the requirement was met because they are only examples.

If you find yourself writing how in the requirement description, ask yourself why the requirement must be satisfied in this way. You may find you need to break the requirement into several more detailed requirements. Alternatively, you may be revealing a bias based on your experience. Whatever the cause, the how should only appear in examples.

Rich requirement descriptions expose a limitation of using spreadsheets for requirements management, namely that cell formatting is very limited. See a previous article: Why spreadsheets don’t cut it for enterprise software evaluations.

Wrapping up

When making a major software purchase, requirements must be adequately described. Either this is done up-front during the requirements phase, or it is done during the implementation and testing phase.  

If defining requirements properly is left to the implementation, that may result in unrealistic expectations of the software at best, or even selecting the wrong software. Either way, workarounds must be developed when requirements are not adequately met by the selected software. Too many of these workarounds cause the schedule to slip and cost to increase.

On the other hand, if requirement descriptions are well written up front, you know what is needed. RFI / RFP responses are more accurate. The implementation stays on schedule, is within budget, and there is a minimum of business disruption.

While detailed requirements can be fleshed out during implementation, reap the rewards of doing that work up front. The total amount of work remains the same, but the result can be a much more successful software project.