Requirements Document

Ideally, 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 Process

Customers 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.

Screenshot

A good example of a company not being able to provide a requirements document is a genetics research company I worked for in Munich. Although the biologists and chemists I worked with were nothing less than brilliant, their minds were oriented toward biology and chemistry and not toward the organization of information within software. Recognizing that each person should stick to their gifts, I knew that I would never get an appropriate requirements document out of this group any more than they would get me to understand the finer points of genetics. I set about preparing the requirements document by learning all I could about the business. Through long meetings, I discovered the core needs of the business. Since the job was rather large, I broke it up among the various developers working for me. One was responsible for working out the process flow while another was responsible for gathering GUI requirements. I arranged the information and coordinated the effort. Through various presentations and discussions, the information was altered and corrected by the biologists and chemists in an iterative manner until we had a document that was scientifically accurate.


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 Requirements

Whatever 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 Gap

You 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.

Screenshot

Many senior developers find it difficult to communicate with management because they cannot dispense with jargon. Such communication gaps are extremely destructive to productive software engineering. If the customer cannot understand you, or you cannot understand him, it will be impossible for you to deliver what he wants. Focus your efforts on removing these communication gaps.


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.

      
Comments