WHAT VERSUS HOW

When writing a requirement, ask what a particular solution does to uncover unnecessary design and get to the real requirement. Don't write restrictive requirements to avoid undesired solutions. Use a design selection process or your project may end up in the Requirements Hall of Horrors, as these examples show.

Requirements with unnecessary design can restrict the range of solutions or result in bad solutions.

Users needed the capability to drink hot liquids, so the analyst wrote the following requirements:
  1. The thing shall contain up to 8 ounces of hot liquid.
  2. The thing shall have a handle.
Cup with handle inside

This design meets the requirements. In response to a requirement quality review, the analyst asked the users what the handle (solution/design) did and rewrote the second requirement as: The thing shall allow a person to hold it without getting burned. This requirement allowed multiple solutions including: a cup with handle (outside) and a Styrofoam cup.

Problem requirement: The system shall store financial data in the XYZ system format.

Discussion: Would you want the design of your system dictated by another system? In addition to affecting the design of the new system, this requirement would force database changes any time XYZ was modified. Designers had a hearty laugh. The real concern was that the system could receive data from XYZ system without requiring the XYZ system to be modified. They wisely ignored this requirement and had the system reformat the data each time it transmitted or received XYZ's data. In a project with formal processes, however, the designers would have changed the requirement through the configuration management process. As uncontrolled changes like these occur, the requirements become out of sync with the system, making them less useful for future enhancements, modifications, or maintenance of the system. Uncontrolled changes can also lead to disputes with the customer, especially if the real requirement wasn't identified.

Correction: The system shall receive financial data from XYZ system. Note: a requirement might be written that points to an interface control document (interface requirements specification), which provides specifics about data elements and formats.

Problem requirement: The first time an applicant opens an electronic application for benefits, the system shall automatically create a blank record for the applicant in the database.

Discussion: This requirement contains unnecessary design and detail, especially "electronic" and "automatically."

Correction: The system shall create new benefit applications.

Locate pages with requirements examples on the Site Index page.

Page updated 8/23/2008
Ludwig Consulting Services, LLC