In March 1996, Frank McGrath addressed the problem of capturing requirements at a meeting of the Project Management Association in Tysons Corner, Virginia. In summary, McGrath pointed to the software community as being simply arrogant in starting development work without having requirements nailed. By example, he pointed to the building trades. What general contractor would start construction of a building with a requirement that states, “It will be a big building with offices inside?” What does that mean? What is the requirement for a manufacturing plant in which airplanes will be made or a skyscraper where many businesses will reside? McGrath continued using the general contractor example, pointing to the fact that the general contractor finds out not only what type of building, but also what materials need to be used in the construction of the building. The general contractor then finds out what tolerances are needed in the materials and so on and so forth. Given some thought, it is easy to see how important clarifications are in defining requirements in the building trades. They are no less important in the software business, but all too often software developers wrongly feel that they deal in the creative zone where it is far more difficult to articulate and capture requirements effectively.

It may not be as hard as it seems. Software developers must first remember that they are capturing people’s dreams, not what they need — though they may need it — not what they want — though they may want it. Software developers are capturing their dreams, their true desires. In this respect it is very personal for each person participating in the requirements definition process. They may argue over minor points and fail to communicate what is going on in their mind. A leader of the requirements definition process can overcome this by:

1. Conducting regularly scheduled meetings with a previously distributed agenda so that the right people attend and the attendees know what will be covered and what is expected of them.

2. Structuring each meeting to ensure that previously identified requirements are documented for review and analysis, allowing new requireme nts to be submitted and recorded for review at a future meeting and making sure that requirements that are out-of-scope for a specific project or release of a project are identified and tabled.

3. Making sure that each person at the meeting has an opportunity to speak and be heard without criticism or fear of being laughed at or made to feel dumb or stupid.

4. Spending time to make certain the information communicated as a requirement is meaningful; that is, make sure everyone understands that the big building is a tall skyscraper and not a warehouse or a manufacturing plant. Although it may appear that a significant effort is being spent to capture and review requirements, there is a big pay-back if the requirements are identified correctly up front. The cost of correcting software for missing or incorrect requirements goes up significantly the later in the development process the error is found.

These unattractive and very costly statistics can be brought down significantly when the ambiguities common enough to everyday conversation and exaggerated by the separate areas of expertise brought to the table by the customer and the developers are eliminated. Use the helpful hints and techniques proven over time by software professionals such as Donald Gause and Gerald Weinberg, who are noted in the field of requirements definition. The result will be a negotiated understanding of the customer’s desire and a certainty that everyone involved in the project is working toward completion of the same system. Start by removing ambiguities at the statement level.

Clarifying Ambiguous Requirements

Ambiguity at the statement level is tested through verbalization of visualizations. For example, if the requirement is to build a structure to protect a human against wind and rain and snow and ice is given to five people, each of the five people may have a different visualization. One might visualize a kiosk at a bus station, another a threebedroom ranch house, and someone else a nice shiny Rolls Royce. As people at the meeting explain their visual image of what has been stated, clarification can be made, and agreement can be reached.

So, how does one visualize the following requirement statement: The user will be able to store one or more windows in a scrapbook, and how does one express that vision. The visualization here may not be as obvious, but one certainly would want to know if anyone around the conference table is getting the impression that they will be able to store windows into a scrapbook the way files can be stored in directories for indefinite periods of time. So, test the statement:

§ What is the customer interpreting the statement to mean?

§ What does the developer intend the capability, i.e., a brief functional description of what will be implemented to satisfy the requirement, to be?

§ What are the system requirements, i.e., How many windows will be stored? How long are they required to be stored? What are the retrieval time requirements for different types of storage?

Document the negotiated understanding that is reached between the customer and the developers regarding the requirement(s) and how it (they) will be implemented. At the word level, use synonyms and comparisons to clarify and ensure the correct interpretation of what is being said. For example, if the requirement is initially stated as:

A big clock will be displayed …

It should be restated as:

A large clock will be displayed …

Start by using the synonym large for the word big. Then, clarify the use of the word large again using a specific comparison, i.e., does large mean it fills the entire screen or just half of the screen? Finally, restate the requirement to spell out the specific size or range of sizes to which the customer and the developers have agreed. In this way, the understanding by both the customer and the developer are consistent. There will be no surprises when the product is presented as complete. More importantly, the incidents of on-the-spot fixes that add up so quickly at the end of a project will be reduced significantly.

Determining Scope

The value of eliminating compound requirements can be seen at all levels, from upper management to project developers and from the customer to the quality assurance team. Only after compound requirements are eliminated can the true scope of the project be assessed, change control applied, testing be correctly managed, and meaningful metrics be collected.

A simple example of a compound requirement is: The user must be able to add, delete, and modify a row. What causes this to be a compound requirement are the multiple things that the user must be able to do. In determining the scope of the work, the compound requirement will be considered as one unit of work, when in fact to provide this capability within the system it may take three separate programs to make it happen. Additionally, if any portion of a compound requirement encounters a problem during testing, the entire requirement is shown as not satisfied. This can skew test result metrics.

To rid a project of compound requirements, identify the statements within each requirement, then make each statement a standalone requirement. This action not only helps to clarify the requirement, but it also provides a more accurate view of the size and scope of the project. The other thing that eliminating compound requirements does is allow requirement dependencies to be identified and tied together in a database.