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.

The allocation matrix

The allocation matrix gives you a grid view of model elements against requirements, so you can see at a glance what’s allocated and what isn’t. It’s the fastest way to 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.

The requirements table in context

Within the architecture module, a requirements table lets you work with the relevant requirements alongside the model — filtering by priority, status, or type — so you can allocate and review without leaving your modeling context.

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 a change to the architecture can flag downstream items as suspect, and coverage from need to design to verification becomes visible end to end. The broader picture — the trace matrix, suspect links, and impact analysis — is covered in Traceability.