Reliability Requirements and Targets – where do the numbers really come from?

Reliability requirements are often treated as if they simply exist as numbers in a specification, contract or statement of work.

In reality, every reliability requirement comes from a set of assumptions, trade-offs and constraints, whether those are explicitly recognised or not.

One of the most common sources of confusion is the difference between a requirement and a target.

• A requirement is a commitment. It defines the minimum acceptable level of performance that must be demonstrated or achieved
• A target is an aspiration. It reflects what the organisation would like to achieve, often providing margin against uncertainty or risk.

Problems arise when the two concepts become blurred. Targets are sometimes treated as guaranteed outcomes, while requirements are occasionally defined without understanding how they will be achieved, measured or supported.

Reliability numbers are shaped by a combination of factors, usually:

Operational need: How the system will be used, how often it must be available and the consequences of failure

Business and cost constraints: Budget, schedule, commercial risk and organisational priorities.

Technical feasibility: Design maturity, system complexity and the level of evidence available

Support and maintenance concepts: How failures will be detected, repaired, mitigated or tolerated in-service

This is where reliability engineers add real value. Rather than accepting reliability numbers at face value, they help organisations ask important questions:

• Where did the requirement come from?
• What assumptions does it depend on?
• What evidence exists or is needed to justify it?

The CRE Body of Knowledge recognises this by emphasising that reliability requirements are driven by customer expectations, operating conditions, regulatory considerations and lessons learned, not simply chosen as convenient numbers.

Well-defined requirements support good engineering decisions early in the lifecycle. Poorly defined ones often move risk into later stages of development or into operational service, where problems are harder and more expensive to resolve.

Reliability requirements and targets therefore shouldn’t be treated as abstract metrics. They are statements about how a system is expected to perform in the real world, and they need to be grounded in operational context, evidence and honest discussion about risk.