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.^[1] The normative SysML v1.7 specification is the controlling authority for the current v1 language family.^[2]

The locked identity is SysML v1.x model + requirement elements carrying requirement identity and text + graphical requirement view + a selected projection of requirement properties and typed relationships + model repository semantics shared with other SysML views -> Requirement Diagram. “Selected projection” is load-bearing. A conforming diagram need not display every requirement or every available relationship type, and one instance need not contain all of deriveReqt, containment, satisfy, verify, refine, copy, and trace. What makes it the abstraction is that the elements and connectors denote underlying SysML model elements and relationships under the v1 semantics, rather than being freehand shapes that happen to resemble them.

The node is deliberately version-qualified. OMG lists SysML 1.7, adopted in June 2024, as the latest formal v1 version and SysML 2.0, adopted in September 2025 with a March 2026 normative language document, as the next formal generation.^[2]^[3] SysML v2 retains requirements, satisfaction, graphical and textual notation, and view artifacts, but its normative language does not define “Requirement Diagram” as the v1 named diagram kind. It instead defines RequirementDefinition, RequirementUsage, and SatisfyRequirementUsage, and a general view/viewpoint/rendering mechanism.^[4] A v2 view filtered to requirements may serve a similar communication purpose, but it should not be back-labeled as the v1 diagram type without a tool or methodology explicitly declaring that compatibility convention.

The abstraction is autonomous because it supplies a repeatable modeling contract. Engineers can diagnose missing allocation, orphaned verification, opaque derivation, or confusing hierarchy by inspecting a requirement-centered view; tool builders can render and query the corresponding model relations; reviewers can move from a requirement to the design or test evidence shown beside it. Generic Requirements Engineering, a table, a traceability matrix, UML diagramming, Representation, or Traceability alone does not entail this exact SysML v1.x view contract.

Structural Signature¶

the SysML v1.x model repository — the authoritative model whose elements and relationships are projected; the drawing is a view of model content, not an independent picture;
the diagram frame — a SysML requirement-diagram context, conventionally identified by the req frame keyword and a model context such as a package;
the requirement elements — requirements represented with the SysML requirement notation, normally carrying an identifier and textual statement and optionally a name, properties, compartments, or nested presentation;
the requirement hierarchy — containment or nesting that organizes a higher-level requirement and constituent requirements without pretending that hierarchy is the only relation available;
the derivation relation — deriveReqt, relating a requirement derived from another requirement while preserving the distinction between source and derived requirement;
the design-satisfaction relation — satisfy, connecting a design or other model element to the requirement it is asserted to satisfy;
the verification relation — verify, connecting a SysML test case to the requirement it verifies;
the refinement relation — refine, indicating that another model element adds precision or detail to a requirement without simply becoming a textual duplicate;
the reuse relation — copy, supporting reuse of a requirement in a different hierarchy under the v1 copy semantics;
the generic trace relation — trace, available when a directed trace association is needed but no more specific requirement dependency expresses the intended semantics;
the selected projection — a deliberate choice of which requirements, compartments, and relationships to show for a stakeholder question; hidden content remains in the model rather than ceasing to exist;
the cross-view bridge — the fact that design, behavior, test, and other elements shown here are the same model elements that can appear in other SysML views;
the conformance boundary — visual resemblance is insufficient: element and connector meanings must be governed by SysML v1.x semantics or an explicitly documented compatible profile.

Recognition test. Ask four questions. Are the boxes SysML v1.x requirements rather than generic statements? Are connectors typed by the requirement relationship vocabulary rather than decorative lines? Do the depicted elements resolve to a shared system model rather than exist only on the page? Is the artifact presented as the requirement-centered req diagram kind or a declared compatible rendering? If all four answers are yes, the identity holds even when only a subset of relation types is displayed. If the artifact is merely a requirement list, spreadsheet, matrix, flowchart, or freehand UML-like sketch, it fails.

What It Is Not¶

Not Requirements Engineering. ISO/IEC/IEEE 29148 treats requirements engineering as life-cycle processes and information products covering the development and management of system and software requirements.^[5] A Requirement Diagram is one modeling view inside that much broader practice; it does not elicit stakeholders, negotiate scope, establish acceptance criteria, validate needs, approve baselines, or govern change by itself.
Not a requirement table. A table organizes requirements and selected properties or relations in rows and columns. It may be generated from the same model and answer a completeness or sorting question efficiently, but it lacks the diagram's node-and-connector spatial projection. The early normative SysML specification explicitly treated graphical, tabular, and matrix-style representations as distinct presentations of related requirement model content.^[6]
Not a requirements traceability matrix. A matrix usually crosses two sets—requirements against design elements, tests, source needs, or other artifacts—and marks which pairs are related. It is excellent for coverage scanning and sparse many-to-many relations; it does not show the full requirement-centered graph with heterogeneous typed links and contextual model elements.
Not generic UML diagramming. SysML v1 builds on UML, but Requirement Diagram is a SysML addition for requirements. A UML class diagram with stereotyped-looking boxes is not automatically conforming, and a use-case or activity diagram answers different questions.
Not an Activity Diagram. Activity Diagram is a behavioral notation: actions, decisions, forks, joins, control flows, object flows, and token semantics describe execution or workflow. Requirement Diagram describes requirement structure and relationships to design and verification elements. One may refine a requirement with an activity; that does not turn the requirement view into a behavioral execution model.
Not a database of requirement prose. The diagram can display id and text, but the relationship semantics and model integration are what distinguish it from boxed prose.
Not proof of satisfaction or verification. A satisfy connector records a model assertion, and a verify connector records the relationship between a test case and a requirement. The line alone neither proves the design actually satisfies the requirement nor supplies a passing test result. Formal Verification and Model Checking make much stronger assurance claims.
Not the normative name of a SysML v2 diagram kind. SysML v2 supports requirements and rendered views, including graphical diagrams, but the language specification organizes these through definition/usage and view/rendering constructs rather than preserving the v1 list of named diagram kinds unchanged.^[4]

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.^[1]

The view operates at many granularities. At enterprise or mission level it can show stakeholder and system requirements with derivation into subordinate statements. At architecture level it can show which blocks, interfaces, behaviors, or other elements satisfy selected requirements. In verification planning it can place test cases next to the requirements they verify. In reuse work it can distinguish a copied requirement from a newly derived one. In review packages it can project only the slice relevant to one subsystem, contract, hazard, or verification milestone.

Its scope includes diagrams created manually in a conforming SysML tool and generated views whose content is queried from a repository. It also includes printed or exported snapshots so long as their semantics remain traceable to the model. It does not require one vendor, one layout, or one lifecycle method. Tool-specific styling, compartment choices, validation rules, and automatic matrices are implementation features around the standard abstraction.

The temporal boundary matters. SysML v1 remains a real deployed language during migration, and OMG publishes v1-to-v2 transition guidance.^[7] This entry therefore does not become obsolete merely because v2 exists. It also does not freeze all requirement-centered modeling at v1. In v2, the exact constructs and conformance tests must be read from the v2 language: requirements are kinds of constraints; definitions and usages may nest; satisfaction is an assertion binding a satisfying feature to a requirement's subject; and view artifacts are produced from exposed and filtered model content with renderings.^[4]

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.

Now compare three artifacts built from the same repository. A requirement table lists id, text, owner, status, and perhaps a derived-from column for hundreds of requirements; it is strong for sorting and checking missing attributes. A traceability matrix puts requirements on rows and test cases on columns; it is strong for finding rows with no verifying test. A Requirement Diagram spatially selects a smaller graph so reviewers can read hierarchy, derivation, satisfaction, and verification together and see the nearby design or test elements. None is intrinsically superior. They preserve different aspects of the model for different review questions.

The sharp diagnostic is: is the artifact showing a requirement-centered typed graph, or merely displaying requirement information? A spreadsheet with arrows drawn between cells is still not necessarily a Requirement Diagram. Conversely, a sparse req view containing one requirement and one satisfy relation can qualify because its elements and relation resolve to the SysML model and use the normative meaning.

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.

The abstraction also separates model semantics from presentation. A requirement can appear in several diagrams, tables, or matrices without being copied into several independent truths. Layout can change while model identity remains stable. That enables impact analysis: when a requirement changes, the shared relations identify candidate design elements, tests, and derived requirements needing review. The diagram does not automate the engineering judgment, but it makes the dependency surface inspectable.

Typed links reduce ambiguity. A generic line between a component and a requirement might mean “mentioned by,” “allocated to,” “implements,” “tested by,” or “depends on.” satisfy and verify force different roles. deriveReqt is not interchangeable with containment; a child requirement may be structurally nested without being a logical derivation, and a derived requirement may live elsewhere in the namespace. The named types therefore compress relationship explanations while preserving distinctions needed for review.

Abstract Reasoning¶

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.
If the repository truly has no satisfying element for a baselined requirement, the diagram has exposed an allocation gap, not proved the requirement impossible.
A verify relation identifies a test case intended to verify a requirement; a test result or verification record is additional evidence. Relation existence and successful execution are different predicates.
A satisfy relation and a verify relation should not be collapsed. The design element is the proposed satisfier; the test case is the verification mechanism.
Containment answers “where is this requirement owned or decomposed?” while deriveReqt answers “from which requirement was this one derived?” Similar-looking hierarchies can encode different semantics.
A generic trace may be legal but less informative than a more specific relation. Prefer the most specific supported relationship because it carries stronger review consequences.
Copying a requirement for reuse is not the same as deriving a new requirement. Copy preserves a source relation; derivation records a new requirement justified by another.
If the diagram becomes unreadable, reduce the selected projection or switch questions. More nodes do not create more traceability when line crossings and hidden labels defeat interpretation.
A matrix is often the better coverage detector for a dense bipartite relation, while a diagram is often the better explanation of a heterogeneous local neighborhood. Choose representation from the query.
A Requirement Diagram can reveal inconsistency but cannot resolve it automatically. Conflicting requirements remain a requirements-analysis problem.
In migration, do not map glyphs alone. Map the v1 model semantics to v2 definitions, usages, satisfaction assertions, and views, because apparently similar graphics may rest on different metamodel commitments.
A diagram exported as an image loses queryability and may become stale. Its interpretation remains valid only relative to the model revision from which it was rendered.

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.

Transfer also occurs across lifecycle questions. A derivation review focuses on requirement-to-requirement lineage; an architecture review focuses on satisfy; a verification-planning review focuses on verify; a reuse review focuses on copy; and a stakeholder briefing may suppress most detail to show only a small hierarchy. These are not different abstractions. They are filtered uses of the same requirement-centered graphical contract.

Outside SysML v1.x, only the skeletal pattern transfers: represent a set of normative statements and their typed relations to design and evidence. Requirements traceability matrices, goal models, safety-case notations, and other modeling languages may instantiate that broader pattern, but calling each a Requirement Diagram would import SysML vocabulary into unlike formalisms. The transferable residue belongs to Representation, Traceability, and Dependency. The named domain-specific abstraction stays with SysML v1.x.

Examples¶

Canonical requirement hierarchy and bridge¶

OMG's explanatory SysML material uses a water-distillation system to illustrate the requirement model: a high-level requirement to produce purified water is decomposed into subordinate functional requirements, while design elements such as the boiler and heat exchanger can be related to what they satisfy.^[8] In a Requirement Diagram, the high-level textual requirement, constituent requirements, and relevant design elements share one graphical surface. The requirement boxes carry identifiers and text; nesting or containment shows the hierarchy; typed dependencies distinguish derivation or refinement from satisfaction; and the req frame tells the reader which SysML view contract applies.

Mapped back: the water-system repository is the model; the purified-water statements are requirement elements; the high-to-low organization supplies hierarchy; the equipment models are cross-view design elements; and the typed connectors turn a picture of boxes into a queryable requirements view.

Applied verification slice¶

Suppose a satellite program has a requirement PWR-042: Essential avionics shall operate through a ten-minute eclipse contingency. A requirement-centered review view shows a parent mission-availability requirement, PWR-042, a more detailed battery-capacity requirement derived from it, the electrical-power subsystem block connected by satisfy, and an eclipse-duration verification case connected by verify. The view deliberately omits hundreds of unrelated thermal and communication requirements.

The diagram licenses several questions: Is the derived capacity statement still justified by the parent? Does the power architecture claim satisfaction? Is a verification case attached? It does not license the claim that the test has passed, that battery capacity is sufficient, or that the whole mission is safe. Those conclusions require analysis and evidence beyond the relationship view.

Counterexample: spreadsheet matrix¶

A spreadsheet lists 800 requirements as rows and 120 test cases as columns, marking covered cells. It is a useful traceability matrix and may be generated from a SysML repository. It is not a Requirement Diagram because it uses a bipartite tabular encoding rather than the req node-and-connector view. Exporting the same model into different artifacts does not make their representational contracts identical.

Structural Tensions¶

T1: Completeness versus legibility. A view containing every requirement, component, test case, and relationship may be semantically complete yet visually unusable. Filtering improves comprehension but can make an omitted relation look absent. Diagnostic: state the view's scope and filter, and check model queries or a matrix before declaring an orphan from a drawing.

T2: Traceability assertion versus engineering evidence. Typed links make allocation and verification intent inspectable, but teams can create lines faster than they create valid designs or tests. A dense, connected diagram can become “traceability theater.” Diagnostic: for a sampled satisfy or verify connector, can the reviewer reach the rationale, analysis, test procedure, and result that justify it?

T3: Specific semantics versus convenient generic trace. A generic trace link is easy to add and flexible, but it weakens the inferences available to reviewers. A more specific relation improves meaning but requires the modeler to commit to direction and role. Diagnostic: if replacing a specific link with trace would lose an actionable review question, keep or repair the specific relation.

T4: Shared model versus snapshot stability. A live diagram benefits from repository identity and automatic updates; a controlled review often needs a stable baseline. Exported images and documents freeze the view but can drift from the model. Diagnostic: record model revision and generation time, and decide whether the artifact is a live view or controlled evidence.

T5: Diagram continuity versus language migration. SysML v1 users possess established req practices and tools, while v2 offers a different semantic foundation, textual syntax, and general view mechanism. Preserving familiar pictures can help adoption but can conceal metamodel differences. Diagnostic: during migration, trace each v1 relationship to its v2 semantic target and mark any tool-level rendering convention that is not a normative v2 diagram kind.

T6: Autonomous notation versus prime reduction. The diagram clearly instantiates Representation and frequently supports Traceability and Dependency. Yet those primes do not entail requirement stereotypes, the req frame, deriveReqt, satisfy, verify, copy semantics, or the v1 conformance boundary. Diagnostic: if the question is “what does this medium preserve?” use Representation; if it is “is this artifact a conforming SysML v1 requirement view?” retain Requirement Diagram.

Structural–Framed Character¶

Requirement Diagram is framed. Its structural content is substantial: a selected graph of typed nodes and edges projects an underlying model, and relationship direction and type support predictable inferences. Evaluative weight is low; the concept names a notation rather than praising or condemning its use. But the identity is institutionally constituted. OMG defines the language, conformance rules, element types, relationship vocabulary, and version history. Human modeling practice chooses the view scope and interprets its stakeholder purpose. The vocabulary travels only where SysML v1.x or a declared compatible profile travels.

This does not make the abstraction arbitrary. Once the standard is fixed, whether a model element is a requirement, whether a link is verify, and whether a view conforms are technical questions. “Framed” records where those validity conditions come from: a standards-governed modeling practice, not a substrate-independent relation found in nature.

Structural Core vs. Domain Accent¶

The portable core is typed relational projection: choose a bounded set of normative statements, represent them as nodes, and show selected relations to their origins, refinements, implementations, and evidence. That core supports trace navigation, impact analysis, and stakeholder-specific views in many formalisms. Representation captures the target–medium–mapping–faithfulness relation; Traceability captures backward and forward navigation; Dependency captures directed reliance.

The domain accent is everything that makes the view specifically a Requirement Diagram: the SysML v1.x metamodel, requirement stereotype and displayed properties, req frame, namespace containment, deriveReqt, satisfy, verify, refine, copy, trace, test-case role, and integration with other SysML model elements. Remove those commitments and a generic requirements graph remains, but the named SysML abstraction has disappeared.

This explains why the candidate is domain-specific rather than prime. Its exact machinery transfers across aerospace, automotive, medical, industrial, and software systems only because those practices share SysML. Beyond that language community, similar graphs are analogues or instances of broader primes. The version boundary confirms the point: even SysML v2 reorganizes the machinery enough that a v1 “Requirement Diagram” cannot be assumed as a normative v2 diagram type.

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 organization; the faithfulness claim is bounded by the selected projection. Every retained Requirement Diagram is therefore a Representation.
Traceability — frequent function, not strict parent. Requirement diagrams commonly make origins, derivations, satisfaction, and verification links navigable. But one conforming diagram may show a requirement or hierarchy without a complete bidirectional, metadata-rich audit chain, so Traceability is not universal inheritance.
Dependency — relation-level neighbor. Several connectors are directed dependencies in the modeling sense, but containment and graphical inclusion are not all reliance relations with a failure mode. The entire diagram should not inherit from Dependency.
Hierarchy — optional organization. Requirement decomposition or containment can create a hierarchy, but flat requirement views are possible.
Abstraction — view-selection mechanism. Filtering omits model detail to fit a review question, but abstraction alone does not encode the result in a graphical standard.
Perspective — stakeholder and concern selection. A requirement view is often scoped for a reviewer or question, while the exact v1 diagram identity remains determined by SysML notation.

Relationships to Other Abstractions¶

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

Requirement Diagram → Representation → Abstraction

Neighborhood in Abstraction Space¶

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

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Specification language — 0.75
Data Model — 0.74
Mathematical Flow Graph — 0.74
ISO 19439 Enterprise-Modelling Framework — 0.73
Market Pull — 0.73

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

Not to Be Confused With¶

Requirements Engineering: the complete life-cycle discipline for eliciting, analyzing, specifying, validating, managing, and changing requirements. The diagram is one representational instrument.
Requirement table: a row-and-column projection of requirement properties and relationships, efficient for sorting and scanning.
Requirements traceability matrix: a cross-product view of two element sets, efficient for coverage and orphan detection.
Activity Diagram: a UML/SysML behavioral view whose actions and flows describe execution, decisions, concurrency, and object movement.
Use-case diagram: a view of actors and system use cases, not a requirement relationship graph.
Class diagram or Block Definition Diagram: structural views of classifiers, blocks, and their relationships; they may show elements that satisfy requirements but do not become Requirement Diagrams.
Formal Verification: a proof-oriented assurance method establishing a formal property over a stated scope. Drawing verify does not discharge a proof.
Model Checking: exhaustive exploration of a finite-state model against a formal property, usually returning a counterexample on failure. Requirement Diagram performs no state exploration.
SysML v2 requirement view: a v2 view artifact can expose and render requirement definitions/usages and satisfaction assertions. Similar purpose does not make “Requirement Diagram” a normative v2 named diagram kind.
Freehand requirements map: a useful sketch can show statements and arrows, but without SysML v1 element identities and relationship semantics it is not this abstraction.

References¶

[1] Object Management Group. “SysML v1 Specification.” Official overview of SysML v1 scope and the requirements diagram's hierarchy, derivation, satisfy, verify, and requirements-tool bridge roles. Official page. registry ↩a ↩b

[2] Object Management Group. OMG Systems Modeling Language (OMG SysML), Version 1.7. OMG document formal/24-01-07, June 2024. Official specification record; normative PDF. registry ↩a ↩b

[3] Object Management Group. “About the OMG System Modeling Language Specification Version 2.0.” Lists the September 2025 adoption and current normative Language document formal/26-03-02. Official specification record. registry ↩

[4] Object Management Group. OMG Systems Modeling Language (SysML), Version 2.0, Part 1: Language Specification. OMG document formal/26-03-02, March 2026, especially §§7.21 and 7.26 on requirements, satisfaction, views, viewpoints, renderings, compartments, and diagrams as view usages. Official normative PDF. registry ↩a ↩b ↩c

[5] ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018, Systems and software engineering—Life cycle processes—Requirements engineering. 2^nd ed., 2018; confirmed current in 2024 and under revision in 2026. Official ISO record. registry ↩

[6] Object Management Group. OMG Systems Modeling Language (OMG SysML), Version 1.0. September 2007, especially §§16.2–16.3 on Requirement Diagram elements and graphical, tabular, and matrix-style requirement representations. Official normative PDF. registry ↩

[7] Object Management Group. “SysML v2.” Official overview of the next-generation language, textual and graphical syntax, KerML basis, API, intended use, and v1-to-v2 transition. Official page. registry ↩

[8] Hause, Matthew. “The SysML Modelling Language.” OMG-hosted explanatory paper, 2006. Describes the requirement stereotype, deriveReqt, satisfy, verify, refine, copy, containment, and graphical/table/tree formats, with a water-distiller requirements example. OMG-hosted PDF. registry ↩