If your teams use both a requirements management tool and a system modeling tool on cross-domain engineering programs, you’ve probably experienced what happens when these two environments are not connected. Requirements change, but the modeling team is not properly notified. Coverage analysis depends on manual checks, and impact analysis often relies on the person with the most experience and knowledge of the model. If that person is unavailable or has left the project, the analysis takes much longer or gets done incompletely.
This article explores the root causes of this gap, what this gap costs in practice for teams and projects, and how to effectively enable traceability between requirements and systems models. To make it concrete, we’ll walk through how ReqXChanger, SodiusWillert’s requirements-to-model traceability solution, addresses this.
|
ℹ️ A note about the scope of the article Two approaches exist for enabling traceability between requirements and models: OSLC-based traceability, which provides live, real-time connections between tools, and synchronization-based traceability using ReqIF. This article focuses on synchronization-based traceability for teams and environments where OSLC infrastructure is not in place. |
The structural gap between requirements and models lies in how the tools are built.
Requirements Management tools (IBM DOORS, IBM DOORS Next, Siemens Polarion, etc.) and system modeling tools (IBM Rhapsody, Cameo System Modeler, Sparx Enterprise Architect, etc.) operate on separate repositories, with different data structures and different workflows. Maintaining traceability across these environments is inherently challenging, even when standards like ReqIF provide a common exchange format. The tools serve different engineering activities, are owned by different teams, and evolve at different paces.
So, teams attempt to fill the gap themselves and compensate by maintaining traceability matrices in spreadsheets, copying requirement ID’s into model comments, and comparing periodic exports by hand.
These approaches go stale as soon as a requirement or model element changes and break down past a few hundred requirements.
1) Design based on outdated requirements
A requirement is updated after a customer review or a change request. This change is recorded in the RM tool, but no notification reaches the modeling team. The system engineer continues working from the previous version.
The mismatch is only caught days, even weeks later, during a design review or a verification activity. By then, the model, the derived requirements, the interface definitions, and potentially the test case all need to be revisited. What could have been a controlled change propagation becomes an unplanned rework cycle that affects multiple teams and schedules.
Before a milestone review, the team needs to demonstrate that every requirement has been addressed in the design. Without a dedicated tool to link or synchronize requirements with model elements, verifying coverage means cross-referencing the requirements against model exports or reports produced by the modeling team. Requirements engineers depend on these deliverables to check whether each requirement maps to a corresponding element at the right level of architecture.
As the number of requirements grows, the effort, the number of people involved, and the risk of missing something grow with it. And at the end of the day, the result is only as reliable as a manual and repetitive process can be, with no repeatable or auditable trail. If a gap is discovered during a certification audit, the team has to go back and re-establish the missing trace links, and in some cases, re-justify design decisions that were already considered closed.
A safety requirement has changed. The requirement engineer in charge updates it in the RM tool. Now, someone else needs to trace how that change affects the model: which functional blocks implement the requirement, which interfaces are impacted, whether derived requirements need to be updated, and whether downstream verification artifacts are still valid.
Without a dedicated tool to connect or synchronize the two environments, this means opening both tools side by side, cross-referencing identifiers manually, and above all, relying on individual knowledge of the model structure. On large programs with thousands of requirements, this process can take days and still miss dependencies. These surface later, during integration or testing, where the cost of correction is significantly higher and the schedule impact harder to absorb.
OSLC (Open Services for Lifecycle Collaboration) is an open standard that creates live, linked data connections between tools. OSLC enables real-time traceability without duplicating data across environments or synchronization cycles. A requirement in the RM tool and a design element in the modeling tool are connected through live links. Changes are visible immediately, and traceability is maintained.
However, not all environments have OSLC infrastructure in place. For example, OSLC connectivity between IBM Rhapsody and IBM DOORS/DOORS Next requires IBM Rhapsody Model Manager. Some teams don’t have this component, and others simply prefer not to add it. And some tool combinations may have limited or no native support for OSLC.
|
📖 If you want to learn more about OSLC and Linked Data, read our previous publications: |
For environments where Open Services for Lifecycle collaboration is not available or not practical, a synchronization-based approach provides an alternative path. This approach relies on ReqIF (Requirements Interchange Format) and provides a vendor-neutral format for exchanging requirements data. It defines how requirements, their attributes, and their relationships are structured so that any compliant tool can read and write the same data. Most major RM tools support ReqIF. It includes IBM DOORS, IBM DOORS Next, and Siemens Polarion.
But if ReqIF handles the format, it does not handle the process. Indeed, it tells tools how to package requirements data, but it does not manage the synchronization, the linking to model elements, or the detection of changes over time. A dedicated tool must handle this part. Requirements data is exchanged through ReqIF, and the tool manages the import, synchronization, and change detection.
This approach operates through periodic synchronization rather than live connections.
📖 Read also:
Linked Data vs. Data Synchronization: Two Integration Methods Explained
Linked Data vs. Traditional Methods - Which Integration Strategy Fits Your Engineering Toolchain?
Engineers need to navigate traceability from both environments.
From the RM tool, it means that they can open a requirement and see which model elements address it. This supports both coverage analysis (are all requirements addressed?) and impact analysis (if the requirement changes, what is affected in the design?) Both are requirements-centric activities.
From the modeling tool, it means being able to navigate from a design element to the requirements it traces to serve a different purpose, for instance, identifying orphan elements. Standards such as DO-178C require that every design element be justified by a requirement. Without this visibility, unjustified elements go undetected.
This does not necessarily mean links need to be stored in both tools. In a synchronization-based approach (like ReqXchanger), visibility from the RM side requires the round-trip of model element representations back into the RM tools.
Creating a link between a requirement and a model element is a starting point, but maintaining that link over time is where most manual approaches fail. Requirements evolve throughout the lifecycle. They get refined after reviews, updated after change requests, split or merged as the architecture matures.
Each time a linked requirement changes, that change needs to be visible in the modeling environment, so engineers can review whether the design is still aligned. In a synchronization-based approach, this works as follows:
With this mechanism, changes are detected as soon as the next synchronization runs. The modeling teams see immediately which elements need to be reviewed and can act before the mismatch reaches a design review or an audit.
Tracing a requirement to a top-level architectural block is necessary but not sufficient. A block can contain dozens of internal elements: attributes, operations, interfaces, and sub-components. When an auditor or a certification authority asks how a specific requirement is realized in the design, “it maps to that block” is quite a vague answer. They want to see the specific element inside the block that addresses the requirement.
It means that traceability needs to reach below the architectural level, into the sub-elements that actually carry the design intent. This level of detail is what standards like DO-178C and ISO 26262 increasingly expect, and where most manual traceability processes fall short.
ReqXChanger is a solution developed by SodiusWillert that connects ReqIF-compatible requirements management tools with UML/SysML modeling environments. It works with IBM Rhapsody and Sparx Enterprise Architect on the modeling side, and ReqIF-compliant requirements management tools such as IBM DOORS and Siemens Polarion.
Here is how the workflow operates in practice:
Requirements are exported from the RM tools in ReqIF format and imported through ReqXChanger into the modeling environment. ReqXChanger transforms them into SysML requirement elements that appear directly in the model. From there, engineers create trace links between these SysML requirements and other model elements within the modeling tool: use cases, classes, blocks, operations, attributes, and state diagrams.
Fig. 1 - SysML requirement elements appear directly in the model
Fig. 2 - Engineers can create trace links between SysML requirements and other model elements within the modeling tool. Once trace links are established, the coverage level is calculated and displayed directly in the modeling environment.
Once traceability links are established, they need to stay up to date. This is where synchronization comes in. During each sync, ReqXChanger compares the current state of linked requirements with the previous one. If a requirement has changed, it is flagged as a suspect link in the modeling tool. Engineers search for these flags and immediately see which parts of the model need review.
Fig. 3 - ReqXChanger compares the current state of linked requirements with the previous one
The process also works in the other direction. Model elements and diagrams can be transferred back into the RM tool. For instance, a requirements engineer can open a requirement and see a representation of the model element that implements it, including its diagram context.
Both teams get visibility without leaving their own tool.
Fig. 4 - With ReqXChanger, model elements and diagrams are transferred back into the RM tool. Requirements engineers see a representation of the implementing model element directly from their requirement
For traceability that goes beyond the architectural level, ReqXChanger can include sub-architectural elements in the synchronization: attributes, operations, and other nested elements. Engineers can control the depth (first level or recursive) and which element types to include. Then, the RM tool sees not just a top-level block, but the specific elements inside addressing the requirement.
Fig. 5 & 6 - Sub-architectural elements (attributes, operations) included in the synchronization. Engineers control the depth and element types.
Fig. 7 - The RM tool sees the specific elements inside the block, not just the block itself.
Engineers can also tag specific model elements with a stereotype to include them in the synchronization, regardless of where they sit in the model hierarchy. This lets teams choose precisely which elements are relevant to share, without synchronizing the entire model.
The entire process can be automated. ReqXChanger provides a command-line interface that allows export, import, and synchronization to be scripted and scheduled in the background, without manual intervention or disruption to the engineers’ daily work.
When traceability between requirements and models is automated and maintained, the benefits are concrete:
Systems engineers share only the design data that matters to the RM side, avoiding unnecessary noise that makes coverage analysis harder.
Compliance and quality teams demonstrate traceability from tool output, not from manually assembled evidence. In DO-178C or ISO 26262 programs, this can save weeks of audit preparation.
ReqXChanger addresses the traceability gap through the ReqIF standard, with bi-directional links, suspect link detection, and traceability down to sub-architectural elements.
➡️ Request your free trial →
➡️ And if you have questions about the product, your specific toolchain, or integration scenario, contact us →
On the modeling side: IBM Rhapsody and Sparx Enterprise Architect. On the RM side: IBM DOORS and Siemens Polarion.
No. Requirements engineers stay in their RM tool. Systems engineers stay in their modeling tool. ReqXChanger handles the synchronization between the two.
Yes. Engineers choose which element types to include, how deep the synchronization goes, and can tag specific elements with stereotypes to include them selectively.
OSLC creates live, real-time links between tools without duplicating data, but requires specific infrastructure and is supported by a limited number of tools. A ReqIF-based approach uses periodic synchronization to exchange requirements data between tools. It works with virtually all major RM tools and does not require additional infrastructure.
Yes. Both standards require demonstrable traceability between requirements and design artifacts. The expected level of detail varies by assurance level, but the ability to show how a requirement is addressed in the design is mandatory in both cases.