Insight · SysML notation

SysML Requirements Diagram: Capturing and Tracing Requirements in Sparx EA

By Sparx Services · January 5, 2026 · 9 min read

A requirement that lives only in a document is a requirement no one can trace. The SysML Requirement element captures the requirement inside the system model rather than 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.

The systems engineer's job with requirements is to write statements that can be verified and to keep each one traced to the design that satisfies it and the test that verifies it. The mechanics take most of the time: creating elements, assigning IDs, drawing derive, satisfy and verify links, building matrices and hunting for gaps. In AI-augmented work the engineer states the requirements and the traceability rules, and AI creates the elements and links in the model and runs the gap checks, such as which requirements have no satisfy or verify relationship. The skill is writing verifiable requirements and judging whether a block really satisfies one. That judgment stays with the engineer.

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

The derive, satisfy, verify chain: from a system requirement, through a derived requirement, to the block that satisfies it and the test case that verifies it.

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 an id and text, and most programs add risk and verification method attributes from the SysML requirement extensions:

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 a set of 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:

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:

System Requirement (SYS-NAV-001): "The navigation system shall provide position accuracy better than 10 meters CEP under nominal operating conditions."
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».
Design Element: the GPSReceiverSubsystem block satisfies SS-GPS-001 via «satisfy».
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 visible straight from the model.

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?

Sparx EA is sufficient when

Requirement count is in the low thousands or below
The program does not exchange requirements electronically with external parties using formal RM-tool interchange formats
Traceability is primarily internal, the design team uses Sparx EA throughout
Change management does not require RM-tool-specific workflows (approval chains, baseline comparison, change request management)

DOORS or Jama is needed when

Your customer requires DOORS or ReqIF format requirement exchange
Regulatory submission requires a specific RM tool format (common in aviation and automotive)
Requirement count runs well past a few thousand and managing large sets is a concern
Multiple organizations each manage their own requirement sets with formal exchange protocols

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 ReqIF import and export, and a DOORS integration is available from Sparx Systems.

Frequently asked questions

Can SysML requirements in Sparx EA export to DOORS?

Yes, through an integration. Sparx Systems offers a DOORS integration (MDG Link for DOORS) that can exchange Requirement elements with DOORS, and Sparx EA also supports ReqIF import and export. Check the current Sparx documentation for the edition and setup requirements.

How do we handle requirements that come from a Word document?

Bring them into the model. Requirements held in structured sources such as spreadsheets, CSV or ReqIF can be imported as Requirement elements, and AI can help turn a requirements document into those elements for the engineer to review. The source needs a consistent structure (requirement ID and text). After import, you assign IDs, set verifyMethod values, and build the traceability relationships. Do not maintain requirements in both Word and Sparx EA; choose one as the source of truth.

What is the difference between Satisfy and Refine?

Satisfy is the design-to-requirement link: the design element is the complete answer to the requirement. Refine is a clarification link, the refining element adds detail without claiming to fully implement it. Use Satisfy for blocks and components; use Refine for activities, state machines, or use cases that describe how the requirement is realized in more detail.

Should every requirement have a Verify relationship?

Yes, at the level where requirements are baselined for delivery. An unverified requirement is either untestable (rewrite it) or not yet planned for verification (a program risk). At system level, every requirement should have a Verify relationship to a test case or a documented rationale for why it cannot be independently verified (for example, it is verified by a higher-level test).

How do we manage requirement baselines in Sparx EA?

Use Sparx EA's package baseline feature. Baseline the requirements packages at program milestones (System Requirements Review, Preliminary Design Review, Critical Design Review). Each baseline is a snapshot that can be compared to the current state, and the comparison shows which requirements changed.

What is a requirement allocation in SysML?

Allocation is not a standard requirement relationship. It uses the «allocate» dependency. A requirement is allocated to a structural element (block) or a behavioral element (activity, state machine) to assign responsibility for implementation. Allocation complements Satisfy: Satisfy says "this design element fulfills the requirement"; Allocate says "this element is responsible for implementing it." Both are useful; Satisfy is more formally defined in SysML.

How does a structured requirements model support automated queries?

When requirements carry consistent IDs, tagged values, and relationships, the model becomes queryable rather than just readable. Useful queries include "which requirements have no Satisfy relationship?" (design gaps), "list all High-risk requirements not yet verified," and "which blocks satisfy the interface requirements?" These run against the structured model and replace analysis that used to mean manual spreadsheet work.

How many requirements are manageable in Sparx EA without performance issues?

There is no fixed count. Performance depends on the database, the server configuration and the density of relationships. Use a server-based repository for large sets, test with a realistic model before you commit, and for very large programs consider partitioning requirements across packages to spread the query load.

Where Sparx Services fits

If your MBSE program needs end-to-end requirements traceability, from system requirements through design to test, Configure the Solution covers the requirements package structure, traceability matrix configuration and team methodology that make traceability routine. Start from the requirements management discipline we support, or from where your architects work.

Get requirements traced in the model, by your team or by us.

We can teach your systems engineers to keep requirements traced in the model with AI on your own repository and mentor them until it sticks, or build the traceability for you and hand it over. Most teams want some of both.

Book a call

Keep reading