As Possible

This is a problematic phrase often seen in requirements and in comments from customers and managers. For example,

The system shall respond as quickly as possible.
The program shall be as small as possible.
The system shall be implemented and deployed as quickly as possible.
The cost of the system shall be as low as possible.
The system shall reuse existing code whenever possible.
The system shall reuse existing hardware and network infrastructure whenever possible.
The new system's user interface shall be as similar to the old system's as possible.
The system shall handle as many requests per second as possible.
Maintenance-related downtime and costs shall be low as possible.

Usually, the person adding such a phrase to requirement is really making an assertion about the relative importance of a given requirement in relation to others. All customers want their systems to be as reliable, fast, small, and inexpensive as possible, but they don't understand the tradeoffs. Customers will say that the system must be as fast as possible and as small as possible, without realizing that there is a conflict between those two goals.

The problem with this phrase is that it has no clear meaning, nor any way to test that the system meets the requirement. It is generally impossible or infeasible to have a formal proof that there is no possible way for the system to be faster or smaller than it is. The best possible implementation may be prohibitively expensive. An implementer may try to trivially meet the requirement by simply saying that whatever the system does, it is the best way possible relative to the schedule and budget.

There is a big difference between "as fast as possible" and "AsFastAsNecessary". Focus on the latter; focusing on the former leads to PrematureOptimization.

So, don't write such phrases in requirements, and when you see such a phrase, clarify its meaning. PutaNumberOnIt (e.g., "The system shall respond within two seconds, 99.9% of the time."). Verify that performance-related requirements really are requirements and not just somebody's fantasies of what a perfect system would do.

There is an implementation school in existence to formalize such tradeoffs: QFD, or QualityFunctionDeployment. The idea is to assign points to the value of any particular requirement in relation to all the other requirements. Thus, if there is a fixed maximum of ten points for all the features of the product and Speed is assigned a value of 5, Size is 3, and Cost is 1, then whatever other consideration there is can't have a weight greater than 1. If the client thinks that Coolness needs to be greater than 1 for this new product then he has to give up some weight for another factor, possibly Size or Speed.

CategoryRequirements