Performance Requirements: Type 12

Performance requirements are written when the product needs to perform some tasks in a given amount of time, some tasks need to be done to a specific level of accuracy, or the product needs to have certain capacities.

The need for speed should be genuine. All too often we want things to be done quickly when no real need for speed exists. If a task is to produce a monthly summary report, then there is probably no need to do it quickly. By contrast, the very success of the product may depend on speed:

The product shall identify whether an aircraft is hostile or friendly within 0.25 second.

Capacity is another performance requirement. For example, the client for the IceBreaker product wanted to sell it to road authorities around the world. These authorities are responsible for geographical areas of varying sizes, and the client needed to ensure that the product could handle the largest area covered by any potential client. Initially we would have written the requirement as follows:

The product shall accommodate the largest geographical area of any road authority in the world.

Of course, this is not a practical requirement to hand over to a designer, so eventually we refined it:

Description: The product shall have the capacity for 5,000 roads.

Rationale: The maximum number of roads in the area of any potential customer for the product.

When you are thinking about performance requirements, consider such aspects as these:

• Speed to complete a task

• Accuracy of the results

• Safety to the operator

• Volumes to be held by the product

• Ranges of allowable values

• Throughput, such as the rate of transactions

• Efficiency of resource usage

• Reliability, often expressed as the mean time between failures

• Availabilitythe uptime or time periods when users can access the product

• Fault tolerance and robustness

• Scalability of most of the above

Performance requirements include the risk of damage to people or property. If your product is a lawn mower, then there is a genuine need for the product to avoid cutting off the user's toes. And Isaac Asimov included this in his laws of robotics:

A robot shall not injure a human being.

Hardware is not the only potential source of damage. You should consider whether your software product could cause damage, either directly or indirectly. The IceBreaker product schedules trucks to spread de-icing materials on roads. Because environmental damage from this material can be serious, the requirement covers this issue:

Description: The product shall schedule de-icing activities so that the minimum necessary amounts of de-icing material are spread on roads.

Rationale: To minimize environmental damage.

In some cases, you may want to specify a performance requirement for the outcome of a use case. For example, we found this performance-related requirement:

Description: The product shall schedule de-icing activities so that the rescheduled de-icing truck is estimated to arrive at the breakdown location within 30 minutes of breakdown notification.

Rationale: To resume de-icing as soon as possible.

The performance requirements come mainly from the operating environment. Each environment has its own set of circumstances and conditions. The people, machines, devices, environmental conditions, and so on all place demands on the product. The way your product responds to these conditionshow fast it has to be, how strong, how big, how oftendictates the appropriate performance requirements.