6.3.4 Capacity measures

What this heading covers

Capacity needs a failure definition. Without one, the maximum is where the tester stopped, not where the product stopped. The property that fails might be response time, error rate, memory, or a hard stop, and each gives a different capacity figure. The data volume matters as much as the user count, and the environment matters as much as both. A capacity measure should be reported as a curve with the failure boundary marked, not as a single number.

Record position: family 6 of 40 in clause 6, under 6.3 Performance efficiency, which carries 3 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.3.4 in the public contents; the text behind it is not public.

How a measure for this family is built

Find the load at which the stated property crosses its limit, then compare that load with the load the requirements state. Record the step size of the load test, because a coarse ramp can miss the boundary. A ratio of achieved capacity to required capacity is defensible only when both are defined at the same property.

What to put in place before publication

1. Define the failing property and its limit before the test.
2. Run the load in steps and keep the intermediate results, not only the last one.

Evidence to keep

Two questions to ask

• Which property fails at the capacity limit, and at what value?
• What load steps were tested, and can we see the intermediate results?

Where teams usually fall short

• A capacity figure quoted from a single run at one load level, with no failure boundary.

What the number cannot tell you

It cannot tell you how the product degrades. The load at failure is one point on a curve, and the shape before it is what users feel.

What happens next

If capacity is the constraint, read scalability under flexibility: it describes the shape of the same curve.