Requirement Gathering Essentials
Fools rush in where angels fear to tread Measure twice, cut once Look before you leap
This article looks at the value of requirements and which areas to focus on in order to deliver projects on time and on budget.
Fools rush in where angels fear to tread Measure twice, cut once Look before you leap What do all these sayings have in common? They are all about thinking before acting. Why? Because it saves time, money, effort and embarrassment. It's plain common sense. Yet, when it comes to web development, this common sense seems to disappear. All too often, projects start before thought has been put into the project’s purpose, its desired results, and how its success will ultimately be measured.
Studies have shown that as many as 4 out of 5 projects go over time, over budget or don't deliver expected results (The Chaos Report, 1994 Standish Group). With such long odds, it pays to put in the effort upfront to minimise the risk of failure. The question is, how do we achieve this?
There is no one perfect method for gathering and analsying requirements. If there was, we'd all be using it. Rather, there are many approaches to choose from. This article is not about how to gather or what’s the right method, but what are the key issues to consider.
Focus & Clarity Focus is the most import aspect of any requirements document. A good requirements document clearly states the objective of the project and defines its scope; clarifying what the project does and does not cover.
The shorter and clearer the project objectives, the easier it is to ensure what is delivered meets those objectives, and the less room there is for assumptions and varied interpretations.
On a recent designIT project (an online survey), there were two key objectives:
increase response rate and improve quality of data obtained. These straighforward objectives made it easy to employ focus throughout the requirements document. When discussing options with the client, any confusion as to what should be included was easilly resolved by simply posing the question “will it help increase the response rate or improve the quality of the data?” If the answer was yes, the requirement was in, if the answer was no, it was out.
This becomes a powerful technique when there are numerous stakeholders, all of whom have their own view of what to include. Any requirement, regardless of who it comes from has to pass the simple test: “Does it help achieve the objectives?”. That's why it's important to include all stakeholders in defining the objectives upfront.
The ideal objective is short, concise, clear and agreed to by all stakeholders.
Format Discussing the many ways of gathering requirements can end up in one of the many heated and impractical debates that seem to be a part of our industry. The short answer is whatever works for you. Whether you prefer a written document, screen diagrams, prototyping or use cases, the most important thing is that the people that need to understand the requirements can do so. If the people that form the project team (client / stakeholders / designers / developers) are happy with the format, then that's half the battle won.
That’s not to say that all formats of documenting requirements are equal. If you happen to believe that use cases are effective but your client doesn't understand UML, then it's going to be very hard for them to effectively review the document and identify any errors. It increases the risk of misintepretation. If the document is too technical, the client is likely to assume its correct because they don’t really know otherwise. These sorts of assumptions don't surface until the work is done at which point it becomes far more expense to fix. This brings us back to the purpose of a requirements document - to avoid these mistakes in the first place.
So, if you have a format that you,your client and your project team are comfortable with, then stick to it.
Author The art of writing requirements is a difficult one that takes great skill and, like writing code, the end result is usually cleaner and more consistent if there is a single author. Great care should be taken in selecting who is the author. It's a matter of balancing the need for a thorough understanding of the project domain (i.e. the client's business) against understanding the process of building websites. An author with a great understanding of the project domain but no experience with web development is a risky choice. So is an author with no understanding of the project domain but extensive experience in web development. Ideally, you want to aim for an author that has both. If that's not possible - which is often the case - make sure there are good review processes in place so that the details can be identified.
Language If there's only one rule in the use of language then it’s to use the same language as your client. It's that simple. If the language is consistent, it greatly lowers the risk of misinterpretation of the requirements. For example, a recent project contains a product catalogue for seeds. In the first draft we categorised the seeds into 'types', 'categories' and 'sub-categories'. While this made sense to us, the client and other skateholders use the terms ‘crop’, ‘type’ and ‘variety’. This was bound to cause problems if we didn’t use the same terms as the client. A useful technique to avoid this problem is to include a glossary of terms and definitions in the requirements document.
Accuracy There's little use writing requirements if they are not an accurate reflection of what the client wants. We've found the best way to deal with this is to walk the client through the requirements, they will rarely read them on their own. If it takes five reviews to get it right then so be it. While it can become a drain to do multiple reviews, persistance pays off, it costs many times more to fix things in testing than in the requirements phase.
Having said that, don't expect to get the requirements 100% correct. You need to allow for human nature. A requirements document is a statement of 'what' the end result has to achieve. Even with the best intentions in the world, sometimes when we arrive at the end result, it just doesn't work the way we expected. It's a fact of life. So, the requirements should capture what the client wants but allow for change as long as the objectives are still being met.
Interpretation Being clear and unambiguous is difficult. In law, there are rules for interpretation but even then, those rules are applied by judges who will have their own interpretation of how to apply the rules. What does that mean for requirements? It's important to ensure everyone has the same understanding. One of the best ways to minimise the risk of different interpretations is to include examples; whether it be diagrams, pictures, or sample data to illustrate what the requirements mean.
Conclusion There is no silver bullet, no one answer, no perfect approach method or technique. It’s about giving your project the best chance of success by reducing the risk of common mistakes that arise from a lack of communication or understanding. Get this right and you're off to a good start.