SysML Requirements Diagram: Capturing and Tracing Requirements in Sparx EA

A requirement that lives only in a document is a requirement no one can trace. The SysML Requirement element changes that: it captures the requirement inside the system model — not in a separate Word file — so you can trace live links to the design and test artifacts that satisfy and verify it. In Sparx EA, requirements live in a structured package hierarchy, can be traced through a matrix view, and connect to blocks, components, and test cases in the same model.

This piece walks through the Requirement element's mandatory attributes, the five SysML relationships that build traceability, the package structure that keeps a large set manageable, and the honest call on when Sparx EA is enough versus when you need a dedicated requirements management tool like DOORS or Jama.

The SysML Requirement element

The SysML Requirement element is not a UML class with a name — it has a formal structure defined by the SysML profile. Each Requirement carries mandatory attributes:

id. A unique identifier. For contractual or regulatory programs, the ID scheme matters — it must be stable, traceable, and consistent with the external requirement source (the customer's SRD, the regulatory standard's clause numbering). Avoid auto-generated IDs; use a hierarchical scheme that reflects the requirement structure: SYS-001, SYS-001.1, SYS-001.1.1.

text. The requirement statement — a single, verifiable, unambiguous sentence. "The system shall achieve a mean time between failures of at least 10,000 hours under nominal operating conditions," not "The system should be reliable." In Sparx EA, the text attribute is the primary content field, not the element name; the name is typically the title or ID.

risk. The assessed risk level — High, Medium, or Low — based on the consequence of non-compliance and the likelihood of implementation difficulty. High-risk requirements warrant more frequent review, early prototyping, and dedicated verification planning.

verifyMethod. How compliance will be demonstrated:

• Analysis — mathematical or simulation-based verification
• Test — empirical measurement against a test procedure
• Demonstration — operational observation without detailed measurement
• Inspection — review of documentation or a physical item

The verify method drives test planning. Every Requirement must have one — if it cannot be specified, the requirement is unverifiable and should be rewritten or removed.

SysML requirement relationships

SysML defines five requirement relationships, and together they are what turn a flat list into a traceable network.

Derive («deriveReqt»). Decomposes a higher-level requirement into lower-level derived requirements. A system requirement ("The system shall operate in ambient temperatures of -40°C to +85°C") derives into a subsystem requirement for the electronics assembly. In Sparx EA, draw a «deriveReqt» dependency from the child to the parent (the child is derived from the parent).

Satisfy («satisfy»). A design element (Block, Component, or other) satisfies a requirement — the primary design-to-requirement link. A HydraulicActuator block satisfies the actuation force requirement. Draw a «satisfy» dependency from the block to the Requirement.

Verify («verify»). A test case verifies a requirement. The test case can be a SysML Test Case, a UML Test Case, or a reference to an external test document. Draw a «verify» dependency from the test case to the Requirement.

Refine («refine»). A model element (activity, state machine, sequence diagram) refines a requirement — it elaborates or clarifies it without satisfying or verifying. Draw a «refine» dependency from the refining element to the requirement.

Copy («copy»). An organizational copy of a requirement from an external source (a customer System Requirements Document). The Copy relationship indicates the text is inherited and should not be modified independently. Draw a «copy» dependency from the internal requirement to the source.

Package structure for requirements in Sparx EA

Requirements traceability depends on structure. A flat requirements list is unmanageable for anything above 100 requirements. A workable hierarchy separates stakeholder, system, subsystem, and derived requirements:

Requirements
├── Stakeholder Requirements (StRS)
│   ├── Customer Requirements
│   ├── Regulatory Requirements
│   └── Operational Requirements
├── System Requirements (SRS)
│   ├── Functional Requirements
│   ├── Performance Requirements
│   ├── Interface Requirements
│   ├── Environmental Requirements
│   └── Verification Requirements
├── Subsystem Requirements
│   ├── Subsystem A Requirements
│   └── Subsystem B Requirements
└── Derived Requirements
    ├── Software Requirements
    └── Hardware Requirements

Each requirement package has a corresponding Requirements Diagram. The diagram shows the requirements and their relationships — it is a visual complement to the structured package, not a replacement for it.

Matrix view for traceability

The Requirements Diagram is useful for showing a handful of requirements and their relationships. For traceability across a large set, the Relationship Matrix is the right tool (Project → Relationship Matrix):

• Rows: Requirement elements (select the package)
• Columns: target Block elements (or Test Case elements for a verification matrix)
• Relationship type: «satisfy» or «verify»

This produces a Requirements-to-Design Matrix (which design elements satisfy which requirements — any requirement with no Satisfy relationship is a design gap) and a Requirements-to-Test Matrix (which test cases verify which requirements — any requirement with no Verify relationship is a verification gap). These matrices are mandatory for most defense and aerospace compliance audits, and in Sparx EA they are generated live from the model rather than maintained as separate spreadsheets.

End-to-end traceability example

For a navigation system, the chain runs:

1. System Requirement (SYS-NAV-001): "The navigation system shall provide position accuracy better than 10 meters CEP under nominal operating conditions."
2. Derived Requirement (SS-GPS-001): the GPS receiver subsystem shall achieve better than 5 meters CEP under open-sky conditions. Derived from SYS-NAV-001 via «deriveReqt».
3. Design Element: the GPSReceiverSubsystem block satisfies SS-GPS-001 via «satisfy».
4. Verification: TC-GPS-001: GPS Accuracy Test verifies SS-GPS-001 via «verify».

In Sparx EA this chain is visible in the Requirements Diagram, the Relationship Matrix, and Impact Analysis (right-click any element → Impact Analysis). When a requirement changes — say, position accuracy tightens to 5 meters CEP — Impact Analysis immediately shows which derived requirements are affected, which design elements satisfy them, and which test cases verify them. The change impact is known in minutes, not days.

Sparx EA requirements vs DOORS / Jama

When is Sparx EA's native requirements capability sufficient, and when do you need a dedicated requirements management tool?

The hybrid approach: many programs keep requirements in Sparx EA for model-based traceability (satisfy and verify relationships to design and test elements) and use a DOORS/Jama integration for exchange and formal baselining. Sparx EA supports DOORS integration and ReqIF import/export natively.

Frequently asked questions

Where Sparx Services fits

If your MBSE program needs end-to-end requirements traceability — from system requirements through design to test — Configure the Solution helps you build the practice: the requirements package structure, traceability matrix configuration, and team methodology that make traceability a routine rather than a milestone scramble. Start from the requirements management discipline we support, or from where your architects work.