Linking to requirements

A model earns its place in a regulated lifecycle when it’s connected to the requirements it satisfies. Linking architecture to requirements is what puts the model on the thread — so coverage, impact, and verification flow through it like any other artifact.

Allocating elements to requirements

Model elements are linked to the requirements they realize. A block that implements a capability is allocated to the requirement that calls for it; the connection is a real link, not an annotation. This makes the architecture answerable to the specification: every significant element should trace to a need, and every need should be realized somewhere in the design.

Seeing allocations

Allocation is not presented as a grid. There are three places to see it:

• The Trace overlay on a diagram draws each element’s live links beside the diagram, including the requirements it is allocated to.
• The allocation report lists what is allocated to what.
• The Trace module shows the links across modules, so you can find an element with no requirement behind it, or a requirement with nothing in the design realizing it — the two gaps that matter most when you’re proving the architecture is complete.

Onto the thread

Once elements are linked to requirements, the model joins the rest of the thread. The requirements those elements realize are themselves verified by tests and constrained by risks, so coverage from need to design to verification becomes visible end to end. Suspect flagging follows your trace rules and suspect-triggering fields; editing an architecture block’s content does not flag linked items suspect automatically. The broader picture — the trace matrix, suspect links, and impact analysis — is covered in Traceability.