Independent systems engineering practice · Sydney

Risk requirements are derived, not asserted.

Functional Directions applies Capability Risk Analysis: a model-based method that starts with how a capability will actually be operated, and traces a defensible line from the risks in that operation to the controls the capability needs and the requirements that follow from them.

Capability architecture

A capability emerges from three domains, modelled together.

Operational needsOperational activities, the performers that carry them out, the items of information exchanged between them, and the operational tasks that thread them into use cases: how the capability will be operated and what it has to deliver.
ImplementationComponents and the functions allocated to them, the links that join the components, and the items those links carry: the system whose interaction delivers the operational need.
Lifecycle processesProgram activities and the organisations that perform them: how the capability is acquired, operated, sustained and changed.
Analysis modelCapability Risk Analysis sits across the three. The risks, controls and derived requirements it holds tie need to implementation to process, so each is justified by the others.

Holding the three domains and the analysis model together gives a lifecycle perspective rather than a project one. Requirements reach the implementation with their reasons attached, so the design is built to the need rather than to an assumption about it, and the quality of what is delivered rises.

When the operation, the design or the organisation changes, the model shows what else is affected, which is the substance of change management. And because the reasoning is kept rather than rediscovered at each review, upgrade and re-certification, the cost of owning the capability over its life falls — and that is where most of the cost of a long-lived capability is incurred.

The investment is made early, in the activities that shape the capability before anything is built. The return is harvested for as long as the capability is in service.

The derivation

Select a stage

The system mitigations become part of the operational model, and the derivation runs again on the refined operation. Each pass leaves the model, the requirements and the reasoning between them in step.

01 · Operational model

How the capability will actually be operated: its activities, the information that moves between them, the decisions taken, and what it delivers at its boundary. The kinds of risk that apply — safety, fitness for purpose, security, human performance — and the opportunities open to the operation are settled here too. The analysis works on this, not on a design.

Capability Risk Analysis derives a top-down requirement set. Taken together, those requirements form a requirements-based argument for the mitigation of risk: one that can be put to stakeholders and regulatory authorities, and defended line by line.

See the derivation applied: a stopped vehicle becomes a fire →

The work

What an engagement produces

An operational model

A model of how the capability is used — activities, the information that moves between them, and the decisions taken. It describes the operation rather than any particular implementation of it, and it is refined as the controls the analysis identifies are added.

A bounded risk analysis

Risk scenarios — and the opportunities the operation could take — drawn from that model and from domain expertise, each with a stated scope, so a reviewer can see what was considered and what was not.

Requirements with a derivation

Controls placed where they belong — in the system, or in the operating procedures — and the derived requirements traced back to the risk they address. When the design or the concept of operations changes, the affected capability elements and their requirements are identifiable rather than needing to be rediscovered.

Targets that are derived

Given the level of risk the owner is prepared to accept, the risk reduction each control must deliver is derived rather than assumed. That turns a risk matrix from a scoring device into a source of requirements.

Redundancy put in the right place

Redundancy obligations derived per subsystem from what the capability has to keep delivering, rather than applied uniformly from a tier or class standard. That stops availability targets being met by duplicating the wrong thing.

A specification that holds up

The result is a set of requirements with their reasoning attached — not a register of scores — that can be put in front of an assurance authority, a certifier or a customer and defended line by line.

Where it applies

Domains with a capability to lose

Defence and maritime systemsMission and safety assurance for complex, long-lived platforms and their support systems.
Civil infrastructureTunnels and major assets where operational hazards cross system and organisational boundaries. Worked example: a stopped vehicle becomes a fire →
Intelligent transportReference architectures for road and multimodal networks, and the safety obligations that follow from them.
Data centres and critical facilitiesDeriving per-subsystem redundancy obligations from the mission the facility actually serves, upstream of tier standards.

Tooling

The CRA Workbench

The method is supported by a purpose-built modelling tool. It holds the operational model, the risk analysis and the derived requirements together, and generates the requirement set directly from the diagrams rather than from a separate spreadsheet.

It reads models exported from established MBSE platforms and is designed to sit alongside them, not replace them — the same way a specialised safety tool coexists with a general systems engineering environment. Demonstration on request.

Practice lead

Murray Bailes

Capability architect. Thirty-five years in IT and system development across defence, civil infrastructure and intelligent transport, following fifteen years in system maintenance — which is where the interest in how capabilities actually fail began.

Capability Risk Analysis was formalised through doctoral research at the University of Queensland, completed in 2022, building on an earlier commercial research programme into transferable safety assessment. A textbook on the method is in preparation.

Bailes, M. “Operational Hazard Analysis and the Safety-Aware Concept Development Method.” PhD thesis, The University of Queensland, 2022.
Bailes, M. “Operational Hazard Analysis in DoDAF.” Australian System Safety Conference, 2014.
Bailes, M. “Maritime Safety Case in a Box.” Australian System Safety Conference, 2011.