Are Your Requirements Complete?

As I was setting up my new office PC, I decided to take the opportunity to clean up my files—and I came across some old requirements specifications. Just for fun, I decided to review the documents through the eyes of a quality engineer, using a basic "organization" approach—examining all of the documentation and writing down discussion-producing questions. The exercise was, it turned out, well worth the effort. I found that had we examined the specifications this way during the actual project, we could have spotted at least one gap in each document's requirements set—gaps that caused us problems later in that project.

In many instances, the view of requirements had been tied to the CASE modeling tool(s) we were using, or to specific modeling techniques (data, event, process, or object). Our resulting requirements set was narrow and incomplete.

Why? There are several common scenarios I saw in those requirements specifications—and continue to see in my consulting assignments—that prevent us from developing a complete set of requirements. One is that the initial requirements set is missing important functional components (networks, for example), or fails to address key impacted business units (Billing, for example, or Customer Service).

Another common mistake is to omit non-functional requirements—those requirements that constrain or limit the product design decisions (performance expectations, security, maximum module size, etc.) or the way the project is conducted (resources, budget, time frames, etc.).

Just as I did with my review of those old requirements specifications, we quality engineers can provide a valuable service by identifying gaps during the review of our organization's various work products. Our keen ability to ask probing questions during the review will point out requirements gaps—to users, and to the developers creating the work products. This examination will benefit both the people who must work from the requirements specs and the quality of the end product.

The House that Zachman Built
The organization approach I used is based upon an information framework developed by John Zachman (first published in Issue 3 of the 1987 volume of the IBM Systems Journal ) that correlated two common processes: the development of software systems and the construction of a house.

Building software and building houses are similar in concept. Both processes require different roles with specific responsibilities. Each role will have a different focus and perspective. All roles have one goal: a quality product. Each defect produced by one role impacts another role. And those defects grow in severity (and in cost to repair) as they evolve through the development process.

A house builder's perspective directly relates to the level of detail that evolves through the process of building the home; an owner’s perspective, for example, is much different than the contractor's perspective. The owners will say that they want three bedrooms and two baths. However, the contractor must satisfy the owners’ perspective with a greater level of detail—so the contractor will state the specific requirements for building those three bedrooms and two baths.

The same is true in software engineering. The final product—consisting of networks, programs, and data structures—must satisfy the objective and scope set at the beginning of the project. The perspective levels are as follows:

• Planner High-level view of the product objectives; defines the scope of the investigation
• Owner Business view of the product objectives; defines how the business views the scope
• Designer System Designer's view of the product objectives; defines the essential details to run the business
• Builder Builder's solution to the designer's view of the product objectives; defines the technological solution
• Subcontractor Out-of-context view of the larger product (programs, file structures); defines the details to build