Direct Answer
The SysML Requirement element captures requirements within the system model — not in a separate document — enabling live traceability to the design and test artefacts that satisfy and verify them. Each Requirement has mandatory attributes: text (the requirement statement), id (unique identifier), risk (High/Medium/Low), and verifyMethod (Analysis/Test/Demonstration/Inspection). SysML defines five requirement relationships: Derive (parent-to-child decomposition), Satisfy (design element fulfils requirement), Verify (test case verifies requirement), Refine (elaboration or clarification), and Copy (inherited requirement from an external source). 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. For complex programmes, Sparx EA requirements are sufficient for most teams; DOORS or Jama is needed only when external contractual exchange, regulatory submission, or very large requirement counts (5,000+) demand a dedicated requirements management tool.
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:
id. A unique identifier. For contractual or regulatory programmes, the ID scheme matters — it must be stable, traceable, and consistent with the external requirement source (e.g., the customer’s SRD, the regulatory standard’s clause numbering). Do not use 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. Must be a single, verifiable, unambiguous statement. “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 element name is typically the requirement title or ID; the text is the detailed statement.
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. The method by which 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 physical item
The verify method drives test planning. Every Requirement must have a verifyMethod — if it cannot be specified, the requirement is unverifiable and should be rewritten or removed.
SysML Requirement Relationships
Derive («deriveReqt»). Used to decompose a higher-level requirement into lower-level derived requirements. A system-level requirement (SYS-001: “The system shall operate in ambient temperatures of -40°C to +85°C”) derives into subsystem requirements (SS-001: “The electronics assembly shall operate in ambient temperatures of -40°C to +85°C”). The derivation relationship shows the parent-child traceability.
In Sparx EA: draw a «deriveReqt» dependency from the child requirement to the parent. Direction: child → parent (the child is derived FROM the parent).
Satisfy («satisfy»). A design element (Block, Component, or other SysML element) satisfies a requirement. This is the primary design-to-requirement link. A HydraulicActuator block satisfies the actuation force requirement.
In Sparx EA: draw a «satisfy» dependency from the Block or design element to the Requirement. Direction: block → requirement (the block satisfies the requirement).
Verify («verify»). A test case verifies a requirement. The test case can be a SysML Test Case element, a UML Test Case, or a reference to an external test document.
In Sparx EA: draw a «verify» dependency from the Test Case to the Requirement. Direction: test case → requirement.
Refine («refine»). A model element (activity, state machine, sequence diagram) refines a requirement — it elaborates or clarifies the requirement with more detailed description. Refine does not satisfy or verify; it adds detail.
In Sparx EA: draw a «refine» dependency from the refining element to the requirement.
Copy («copy»). An organisational copy of a requirement from an external source (e.g., a customer System Requirements Document). The Copy relationship indicates that the requirement text is inherited and should not be modified independently.
In Sparx EA: draw a «copy» dependency from the internal requirement to the source requirement (or use the Notes/Constraints tab to reference the external source).
Package Structure for Requirements in Sparx EA
Requirements traceability depends on structure. A flat requirements list is unmanageable for anything above 100 requirements.
Recommended requirements package structure:
“ 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 requirement set, the Matrix view is the right tool.
In Sparx EA, open the Relationship Matrix (Project → Relationship Matrix):
- Rows: Requirement elements (select the package)
- Columns: Satisfy relationship → target Block elements (or Test Case elements for verification matrix)
- Relationship type: «satisfy» or «verify»
This produces:
- Requirements-to-Design Matrix: which design elements satisfy which requirements. Any requirement with no Satisfy relationship is a design gap.
- 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 defence and aerospace programme compliance audits. In Sparx EA they are generated live from the model — not maintained as separate spreadsheets.
End-to-End Traceability Example
For a navigation system:
- System Requirement (SYS-NAV-001): “The navigation system shall provide position accuracy of better than 10 metres CEP under nominal operating conditions.”
- Derived Requirement (SS-GPS-001): GPS receiver subsystem shall achieve better than 5 metres CEP under open-sky conditions. (Derived from SYS-NAV-001 via
«deriveReqt»)
- Design Element:
GPSReceiverSubsystemBlock satisfies SS-GPS-001 via«satisfy».
- Verification:
TC-GPS-001: GPS Accuracy Testverifies SS-GPS-001 via«verify». Test procedure references open-sky measurement under nominal signal conditions.
In Sparx EA, this chain is visible in:
- The Requirements Diagram showing the derive-satisfy-verify chain
- The Relationship Matrix (requirements vs blocks, requirements vs test cases)
- The Impact Analysis (right-click any element → Impact Analysis) which shows all elements connected by traced relationships
When a requirement changes — say, position accuracy tightens to 5 metres 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?
Sparx EA is sufficient when:
- Requirement count is below approximately 5,000 requirements
- The programme does not exchange requirements electronically with external parties (customers, suppliers, regulators) using formal RM tool interchange formats
- Traceability is primarily internal (design team uses Sparx EA throughout)
- Change management process does not require RM-tool-specific workflows (approval chains, baseline comparison, change request management)
DOORS or Jama export 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 exceeds 5,000 and performance/management of large sets is a concern
- The programme involves multiple organisations each managing their own requirement sets with formal exchange protocols
The hybrid approach: many programmes keep requirements in Sparx EA for model-based traceability (satisfy, 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
Q: Can SysML requirements in Sparx EA export to DOORS? A: Yes. Sparx EA has a DOORS integration interface that can export Requirement elements to DOORS and import DOORS requirements into Sparx EA. The integration preserves requirement attributes and can maintain bi-directional synchronisation. The setup requires DOORS to be accessible from the Sparx EA machine. Contact us if you need DOORS integration configuration as part of a broader MBSE setup.
Q: How do we handle requirements that come from a Word document? A: Import them. Sparx EA has a Word document import feature that can parse requirements from structured Word documents and create Requirement elements. The import requires consistent formatting in the source document (requirement ID and text must be in a consistent structure). 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.
Q: What is the difference between Satisfy and Refine? A: 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 or elaborates the requirement 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 realised in more detail without being the final implementation.
Q: Should every requirement have a Verify relationship? A: Yes, at the level where requirements are baselined for delivery. An unverified requirement is either untestable (in which case it needs to be rewritten) or not yet planned for verification (in which case it is a programme risk). At system requirements level, every requirement should have either a Verify relationship to a test case or a documented rationale for why it cannot be independently verified (e.g., it is verified by a higher-level test).
Q: How do we manage requirement baselines in Sparx EA? A: Use Sparx EA’s package baseline feature. Baseline the requirements packages at programme milestones (System Requirements Review, Preliminary Design Review, Critical Design Review). Each baseline is a snapshot that can be compared to the current state to identify changes. The baseline feature is available in Sparx EA Pro and Enterprise editions. For formal change management, the baseline comparison feature shows exactly which requirements changed between baselines.
Q: What is a requirement allocation in SysML? A: Allocation is not a standard SysML requirement relationship — it uses the «allocate» dependency. A requirement is allocated to a structural element (block) or a behavioural element (activity, state machine) to assign responsibility for implementation. Allocation is complementary to Satisfy: Satisfy says “this design element fulfils the requirement”; Allocate says “this element is responsible for implementing the requirement.” Both are useful; Satisfy is more formally defined in SysML.
Q: How does EA GraphLink Interface B support requirements queries? A: When requirements are in Sparx EA with consistent IDs, tagged values, and relationships, EA GraphLink Interface B (MCP) enables AI tools to query them. Useful queries: “Which requirements have no Satisfy relationship?” (design gaps), “List all High-risk requirements not yet verified”, “What blocks satisfy the interface requirements?” These are model intelligence queries that previously required manual spreadsheet analysis.
Q: How many requirements are manageable in Sparx EA without performance issues? A: Sparx EA on a properly configured Pro Cloud Server handles 10,000–20,000 requirements without significant performance impact for most query types. Above 20,000 requirements, query performance can degrade depending on the relationship density. For very large programmes (20,000+ requirements), assess the Pro Cloud Server configuration and consider partitioning requirements across multiple model packages to distribute query load.
Next Step
If your MBSE programme needs end-to-end requirements traceability — from system requirements through design to test — the Amplify engagement delivers the requirements package structure, traceability matrix configuration, and team methodology to make requirements traceability a routine practice rather than a programme milestone scramble.
