14 July 2009 - 13:36 Foundations for Defect-Free Requirements by Elizabeth Stoops

From a software analyst’s point of view, there are two very important types of requirements: those that are “qualitative” (which describe the qualities of the software) and those that are “functional” (which describe how the software performs). Qualitative requirements are usually represented by requirements like these:

CIC_004: The system will be able to handle a constantly growing inventory.
CIC_005: The system will be able to add new categories of inventory.
CIC_006: The system will be able to record inventory changes.

These are sometimes referred to as business requirements, that is, the requirements and constraints the business puts on the software. They define the boundaries of the software and what it must be able to do. What they do not define is how it will do as required. Unfortunately, all too often, business requirements like the above are all a software team or an analyst receives. Consider these ambiguities that the software and analyst teams must work around:

Ambiguity #1: How large an inventory must the system realistically support? Would 3,000 items be overkill? (Perhaps in the case of a company specializing in custom-made Renaissance Faire costumes, this would be more than enough to fill their needs. In the case of Amazon.com, it would be woefully inadequate.)

Ambiguity #2: Will each item, even if it is the same as another item, be listed separately within the inventory? Or will the inventory be able to hold an item count?

Ambiguity #3: How will items be added to the inventory?

As you can see, these ambiguities could be resolved in any number of ways. Using functional requirements like the ones that follow can eliminate creative coding by defining clearly how each qualitative requirement will be implemented. Also it will enable testers to delineate between expected functionality and unexpected functionality without constant meetings, reviews and rework.

CIC_104: The system will have slots for 10,000 individual inventory items.
CIC_114: Each inventory slot will have fields for an inventory number, an item description, inventory category, item price and item quantity.
CIC_124: An inventory number will be 10 digits, starting at 0000000001.
CIC_134: An inventory description may contain 140 characters.
CIC_144: An inventory category may contain 10 characters.
CIC_154: Item price must follow the format of dollar sign ($), numerical characters, decimal point, two numerical characters. The acceptable range for item price is $0.01 - $9999.99.
CIC_164: Item quantity must be a number from 0-9999.

Each qualitative requirement will need its own functional requirements that describe how the needed quality is implemented in the software. Before any development process begins, the following process should be used to create qualitative and functional requirements that will prevent ambiguities:

1. Define what problems the software should solve for the company. (e.g., the inventory is poorly tracked).
2. Define what the general business needs are for a Central Inventory Control system. (i.e., write and edit all the qualitative business requirements).
3. Consider how the software should behave to meet all of those business requirements. (i.e., write and edit all functional software requirements).

Of course, the third step is where things often become confused. There is a need in most specifications to separate the business requirements from software requirements. While business requirements do impact the software requirements, it is our experience that there is a trend to use them in place of software requirements, which leaves functionality ambiguous to both the developers and the analysts. The design will, of course, influence the development and functionality of the software, but the software must have its own functional requirements to avoid missing a key business necessity.

Consider functional requirements to be a blueprint; no one would let an electrician wire their new custom home on the fly without even the roughest of sketches. Nor should the plumber and electrician find that they both intend to put infrastructure in the same place in the wall. By considering each step of the way, and clearly designing even small details in advance of the development of the software, your software project can be done right from the start with a minimum of rework due to misunderstandings, ambiguities or on-the-fly development decisions. The time and money savings from using defect-free software requirements is enormous. Like a carefully planned custom home, a carefully planned software project can be a value for years to come.