6.10.2 Operational constraint measures

What this heading covers

A constraint is a limit the product must not cross: a speed, a dose, a temperature, a concurrent user count, a data retention period. The measure is a count of violations or a proportion of operations within limits. The constraints have to come from the hazard analysis or the domain, not from the product's current behaviour, because a product that has always exceeded a limit has not defined it. The measure should record the operating envelope and what happens at the boundary.

Record position: family 36 of 40 in clause 6, under 6.10 Safety, which carries 5 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.10.2 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the operations within the stated constraints as the numerator over the operations observed. Report violations by constraint and by consequence. For a boundary measure, test the value just inside and just outside the limit, because that is where the constraint is decided.

What to put in place before publication

1. Source each constraint from a hazard analysis or a domain rule.
2. Test at the boundary, not only in the comfortable middle.

Evidence to keep

Two questions to ask

• Where does each constraint come from: a hazard analysis, a domain rule or the current configuration?
• What happens at the boundary, and was it tested from both sides?

Where teams usually fall short

• A constraint inferred from the current configuration, so the product can never violate it by definition.

What the number cannot tell you

It cannot tell you whether the constraints were complete. A constraint set from the wrong hazard analysis measures the wrong envelope.

What happens next

Risk identification is the family that asks whether the product can see a hazard developing.