Previous Next |
Requirements DocumentIdeally, a data model begins with a requirements document, in which the customer specifies all aspects of the system. Once this document is delivered, the architects analyze it and extract the data model. Unfortunately, real life is usually not so simple. An Iterative ProcessCustomers rarely know enough about what they want in the software to write a full requirements document. While the people you work with may be quite intelligent, it's likely that their minds aren't attuned to organizing information for use in a piece of software. The solution to this problem is that you must write the requirements document for them. By talking to the customer's employees, you can learn a great deal about the company and its operations. This should enable you to write a first draft of the requirements document.
Once you have the first draft of the requirements document, it is much easier for the customer to understand how their software will be built. The next step is to present the document to the customer and ask whether the document explains exactly what he wants. Invariably, he will say that it is close but needs some modifications. This is the start of an iterative process in which the customer proposes changes to the requirements document, and these changes are incorporated into the document. The process continues until you and the customer agree on what is feasible yet still satisfies the needs of the business. Although this may seem easy, it is actually the most difficult part of a new project. Getting Approval of RequirementsWhatever you do, don't proceed without a requirements document. The problems of having to improvise are too costly. One of the biggest problems with a fast-and-loose approach is that you have no measure by which to judge the project as complete. Also, without a requirements document specifying the business processes, a concept or critical piece of information could be completely wrong. Such a mistake could cost you weeks, even months, of work and blow your deadlines to pieces. If the customer seems reluctant, or "too busy," to read a requirements document, there are a couple of tricks you can use to motivate him. The first is simply to say, "This is what I am going to build for you if you make no changes." This usually galvanizes the customer to study the document. The second trick is to ask the customer to sign off on the document. Since people are reluctant to sign their name to something that they haven't read, it is likely the customer will carefully review the document and suggest changes; of course, this is exactly what you want to happen. Closing the GapYou should make the customer explain everything about his business. Although you may know quite a bit about the field for which you are writing the software, it is often important that the customer explain everything to you; just as he is no expert in computers, you are most likely not an expert in his field. When a customer talks about his business, it often makes him think about his problems in ways he has never considered before. Your goal should be to act as the bridge between the business and the computing world. Before you present the first draft of the requirements document, you should brush up on your communication skills. Just as you may not know what RNA transcription is, the customer is not likely to know what a decorator pattern is, or the difference between inheritance and aggregation. Dispense with the jargon and use plenty of metaphors during the requirements meeting. Compare such terms as inheritance to concepts with which the customer is familiar. It doesn't matter if he doesn't understand the finer points of the concept. He just needs to know enough to understand you. For example, when talking to a business development manager, you can use the concept of one business owning another to represent the idea of aggregation or composition. By speaking in metaphors, you will be able to communicate productively with the customer.
Using these techniques will help you extract a requirements document out of even the most recalcitrant customer. Once the requirements document is completed, use it extensively and update it religiously. If your developers routinely have the requirements document open on their machines or on their desk in hardcopy, then you did a good job in preparing it. |
Previous Next |