Skip to content

Requirement Diagram

The SysML v1.x graphical view that presents requirements and selected hierarchy, derivation, satisfaction, verification, refinement, copy, trace, or containment links to other model elements.

Version
v2 · 2026-09-06 · History
Domain-specific #
2659
Origin domain
systems engineering
Subdomain
model based systems engineering
Aliases
Requirements Diagram

Core Idea

A Requirement Diagram is the named SysML v1.x graphical view that presents textual requirements as model elements and makes selected requirement-to-requirement and requirement-to-model-element relations visible in the same modeling surface. Its characteristic job is not merely to put prose in boxes. It connects requirements to a system model through a standardized vocabulary for hierarchy or containment, derivation, satisfaction by design elements, verification by test cases, refinement, copying, and generic trace relations. The Object Management Group (OMG) describes the requirements diagram as capturing requirement hierarchies and derivation while using satisfy and verify relationships to bridge requirements-management artifacts and the system model. The normative SysML v1.7 specification is the controlling authority for the current v1 language family.

Scope of Application

The home is model-based systems engineering using SysML v1.x. Requirement Diagrams recur in system concept definition, architecture development, subsystem decomposition, interface specification, safety and reliability work, verification planning, acquisition documentation, and software-intensive system development wherever teams integrate textual requirements with model elements. The OMG v1 overview describes the language as supporting specification, analysis, design, and verification of complex systems and explicitly positions the requirements diagram as a bridge from conventional requirements-management tools into the system model.

Clarity

Consider a vehicle braking model with a requirement BRK-001: The vehicle shall achieve the specified stopping distance. A higher-level safety requirement may contain or motivate it; a more detailed wet-road stopping requirement may be derived from it; a brake-system block may be connected by satisfy; and a stopping-distance test case may be connected by verify. A Requirement Diagram can show those heterogeneous relations around BRK-001 in one requirement-centered view.

Manages Complexity

Large engineered systems contain requirements at multiple levels, design elements across many disciplines, and verification evidence spread across test programs. The Requirement Diagram manages that complexity by projecting a bounded neighborhood of the model. Instead of reading a thousand-row specification and separately searching design and test repositories, a reviewer can inspect one selected requirement graph and follow why a requirement exists, what refines or derives from it, what claims to satisfy it, and what test case claims to verify it.

Abstract Reasoning

  1. If a requirement has no displayed satisfy relation, do not infer that no design element satisfies it; first ask whether the current view filter hides the relationship. Diagram absence and model absence differ. 2. If the repository truly has no satisfying element for a baselined requirement, the diagram has exposed an allocation gap, not proved the requirement impossible. 3. A verify relation identifies a test case intended to verify a requirement; a test result or verification record is additional evidence.

Knowledge Transfer

Exact transfer occurs across engineering domains that use SysML v1.x. In aerospace, a requirement view can connect mission and safety requirements to vehicle subsystems and verification cases. In automotive engineering, it can connect braking, propulsion, diagnostics, and regulatory requirements to blocks and tests. In medical-device development, it can place risk-control requirements beside design elements and verification cases while regulated evidence remains in controlled repositories. In software-intensive systems, it can relate performance or interface requirements to components, behaviors, and tests. The substrate changes, but the same req view, requirement elements, and typed relationship meanings carry.

Relationships to Other Abstractions

Local relationship map for Requirement DiagramParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Requirement DiagramDOMAINPrime abstraction: Representation — is a kind ofRepresentationPRIME

Current abstraction Requirement Diagram Domain-specific

Parents (1) — more general patterns this builds on

  • Requirement Diagram is a kind of Representation Prime

    Representation — strict instantiation and proposed parent. The target is a selected part of the SysML model; the medium is a graphical diagram; notation maps requirements and relationships into boxes, compartments, connectors, and spatial.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Requirement Diagram sits in a sparse region of the domain-specific corpus (99th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08