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