Don t Write a Solution

Don't Write a Solution

We have already mentioned the danger of writing a solution instead of a requirement. But the problem is so widespread (especially with nonfunctional requirements) and potentially so serious that you will forgive us, dear reader, if we mention it again.

Don't presuppose a design solution, or enforce a solution, by the way you write your requirement. By the same token, don't adopt a current solution to a problem and write that as the requirement. For example, if you write a security requirement like this

The product shall require a password to access account data.

then the designer is forced to use passwords. This means that even if a better security device than passwords is availableand there are many to choose fromthe product builder may not use it. As you see, this requirement prevents the designer from searching for an alternative, and possibly better, solution.

By writing

The product shall ensure account data can be accessed only by authorized users.

you allow the product designer the freedom to find the most effective solution.

Apart from potentially solving the wrong problem, one of the main concerns with writing a solution instead of a requirement is that technology is constantly changing. Solutions lock you into one technology or another, and whatever is chosen may be out of date by the time the product is built. By writing a requirement that does not include any technological component, you not only allow the designer to use the most appropriate, up-to-date technology, but also allow the product to change and adapt to new technologies as they emerge.

Consider this usability requirement:

The product shall use a mouse.

We can eliminate the technological component by rewriting the requirement:

The product shall use a pointing device.

But the requirement can be even further improved by writing it as follows:

The product shall allow the user to directly manipulate all interface items.

To follow the guideline of not writing solutions, examine your requirement. If it contains any item of technology or any method, rewrite it so that the technology or method is not mentioned. It may be necessary to do this several times before you reach the desired level of technological independence, but the effect on the design of the end product is worthwhile.

Earl Beede suggests a "three strikes" approach to improving the requirement: List three things wrong with the requirement, and then rewrite it to solve those problems. Do this a total of three times. At that stage the requirement is as good as it is ever likely to be.