Writing Requirements

Written requirements are expected when the customer is external to the organization. If an organization lives or dies by its ability to bid for contracts, as in the defense industry, it would be inconceivable that written requirements would not be provided in the form of a statement of work (SOW). Yet, when the customer is internal to the organization, it is more likely that a written description of the desired product or service not only won't be provided, but will not even be considered. The fact is, all projects should have written requirements, and each internal project should be viewed and managed just as if it is governed by a binding contract. The reasons for doing this will become clear in the following sections.

The best requirements writing guides are the requirements or specification documents from previous, successfully completed projects. The organization's lessons learned archives quickly yield the basic elements for developing a working template for writing your next project SOW. Some tips for describing your requirements and developing a good SOW are shown in Exhibit 4-1.

Exhibit 4-1: Tips for writing good statements of work.

• Describe the work— Describe all the work to be done as completely, clearly, and concisely as possible.

• Do not dictate how to do the work— Write a functional description of the desired product or service when possible.

• Clearly differentiate requirements— Describe only one requirement per requirement statement.

• Avoid ambiguous statements and words— Avoid words or phrases that do not have exact meanings.

• Repeat the statement of requirements for clarity and legality— If requirements are embedded in other documents attached to the contract, repeat them in the statement of work (SOW) or include them by reference.

• Include illustrations, tables, charts, and diagrams— Include anything in the SOW that aids in understanding the requirements.

• Flow down requirements— Pass on my requirements from prime contracts to subcontracts. Requirements imposed on the prime provider by the customer must be included in the vendor's SOW for the vendor's area of work responsibility.

• Always have the statement of work reviewed/critiqued by others— A review by an objective reader will reveal how clearly the SOW is written.

Writing a good SOW—that is, developing a project requirement statement—is an art and the ultimate test of good written communications skills. A requirement should be written in as simple language as possible and should be stated in one sentence. If you find that describing a requirement takes more than one sentence or requires two or more verbs and/or conjunctions, then you are probably describing two or more requirements. Consider this requirement statement:

The product shall be capable of testing 300 samples per hour and shall print test results on a standard-size sheet (81/2 by 11 inches) in a two-column, tabular format.

There are actually two requirements in this statement. The first deals with how many samples the product must test per hour. The second addresses the test report characteristics. The point to be learned here is that whether writing or interpreting requirements, it is important they be completely differentiated to avoid overlooking one or more of them.

We have discussed that the customer develops and writes his requirements as a part of the statement of work, but we have not yet discussed precisely what this document is. The statement of work is the second step in bringing the customer and the provider to an understanding of the project's purpose. In short, the SOW is how the requirements are transmitted to the provider. It basically defines the project scope and is the communication medium in the process of defining the project.