Requirement or Solution?

The description of a requirement is often stated in terms of a solution. We all unconsciously talk about requirements in terms of how we think they should be solved. We talk about solutions rather than requirements because of our personal experience of the world. This results in a statement that focuses on one possible solutionnot necessarily the most appropriate oneand hides the real requirement.

The more abstract the requirement, the less likely it is to be a solution.

Examine the requirement. Does it contain any element of technology? Is it written in a way that describes a type of procedure?

The more abstract the statement, the less likely it is to be a solution. For example, if you write

The product shall be easy to use.

then it is a requirement. By contrast, if you write

The product shall use Java script for the interface.

then it is a solution. Note the use of a technology, "Java script," in the requirement.

Sometimes we unconsciously state solutions. For example, this is a solution:

The product shall have a clock on the menu bar.

Both "clock" and "menu bar" are parts of a solution. We suggest that the real requirement is

The product shall make the user aware of the current time.

When you write the requirement in an abstract manner, other solutions become possible. There are ways other than a clock to make people aware of the timethe astrolabe is one. There are ways other than Java script to make products easy to use.

There will be requirements or constraints that sound like solutions. For example, if your product is shrink-wrapped software, and your client thinks that having a browser-like interface is a selling point, then that becomes a requirement. You would write "a browser-like interface" as one of the solution constraints in section 4 of the specification.

Examine your requirements. Investigate any that are solutions and ask whether they are what the client really wants. Could you rewrite them as requirements without the technological content?

Also, ask, "Why?" For example, suppose that you have the following requirement in your Quality Gateway:

Users shall use passwords to access the system.

Why is this a requirement? "Because we don't want unauthorized people to access confidential information." Now you are discovering the real requirement:

The product shall allow only authorized users to access confidential information.

There are lots of ways to assure confidential access to information passwords are just one of them. However, if passwords have been specified because the new product must conform to the organization's use of passwords, then the requirement is really a design constraint and is perfectly acceptable.

For more on writing requirements rather than solutions, look at Chapter 7, Functional Requirements, andChapter 8, Nonfunctional Requirements.

Of course, from time to time people will come up with great ideas for solutions. Keep them in section 19, Off-the-Shelf Solutions, or section 27, Ideas for Solutions, of the requirements specification. You should always trap great ideas when you think of them. But don't be tempted to distort the product's requirements to fit the great solution idea. It may be great, but it may also be the solution to a different problem.

The customer satisfaction/dissatisfaction ratings indicate the value that the customer places on a requirement.