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\u00a0previous 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.\nWhy description detail is important\nBy 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.\nThe 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.\nWhere requirement descriptions are used\nThe 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\u00a0requirements from the features of potential products.\nWhen 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.\n1) Rating requirements for importance\nThe 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.\nA vital part of having users\u2019 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.\n2) RFI \/ RFP responses\nThe 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\u00a0lead to unmet expectations\u00a0from users. At worst they\u00a0may result in the wrong software being selected\u00a0although auditing RFI \/ RFPs can prevent this.\n3) Software implementation\nThe 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.\nFor 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.\n4) Acceptance testing\nThe 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\u00a0unambiguously\u00a0meets 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.\nHow to write the requirement description\nWrite 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.\nIf 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.\nRich 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.\nWrapping up\nWhen 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. \u00a0\nIf 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.\nOn 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.\nWhile 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.