Requirement Traceability Across DOORS Next, a CM Tool, and a Supplier's Polarion
Helios Medical is developing an infusion pump. Requirements live in a DOORS Next project (2,140 requirements, IDs REQ-PUMP-xxxx). The SysML model has 380 «Requirement» elements whose text was copied from DOORS Next 7 months ago. The «satisfy» relationships point to blocks. A recent change to REQ-PUMP-0871 (occlusion alarm threshold) was made in DOORS Next only. The model baseline B4 is in a CM tool; the DOORS Next baseline is D5. The team needs a traceability report for an audit in 6 weeks. A tool vendor offers a one-way export from DOORS Next to SysML every night. The systems engineer wants to store the full requirement text in SysML so the model is 'self-contained'. The audit requires bi-directional traceability and evidence that the model matches the requirement baseline. Two requirements engineers and one modeler are available.
1. Assess the proposal to store full requirement text in SysML and the nightly one-way export. What traceability and configuration-management failures do they create for the audit?
Read the worked answer
Storing full requirement text in SysML creates a second authoritative source. The existing 380 copies are already seven months old, and REQ-PUMP-0871 proves the drift: the model still contains the old threshold. A nightly one-way export makes the problem worse because it overwrites model-side edits and still cannot carry the model's «satisfy» links back to DOORS Next. The audit needs bi-directional traceability and evidence that the model matches baseline D5, not just that a file was exported. On the CM side, model baseline B4 currently has no record of which requirement versions were satisfied, so an auditor cannot distinguish 'satisfied the current requirement' from 'satisfied an obsolete one'. The correct pattern is a requirement proxy: a SysML «Requirement» that carries the external ID and a link to the authoritative record, while the text remains in DOORS Next. The «satisfy» links stay in the model and are joined to the RM tool by ID. CM must baseline the model and the RM baseline together, or store the RM baseline identifier in the model baseline record.
2. Propose an integration architecture and a six-week plan that produces the audit report. Show how REQ-PUMP-0871 is detected and how the CM tool is used.
Read the worked answer
Use an OSLC or ReqIF-based link, not a nightly text export. In the model, each of the 380 requirements becomes a proxy with id, source, version, and link URL; the text is not copied. A synchronization job reads the RM tool's modified dates and marks any «satisfy» link whose requirement changed as suspect. The CM tool records model baseline B4 together with DOORS baseline D5 and the link-set version. The audit report is a query that joins model elements, proxy IDs, requirement versions, and satisfy links, and lists suspect links separately. Six weeks: week 1 map and reconcile the 380 IDs; week 2 establish links and run the change detector, which should immediately flag REQ-PUMP-0871; week 3 review and re-baseline the affected satisfy links; week 4 freeze B5 and D5 together; week 5 generate the traceability report; week 6 dry-run the audit and fix gaps. Two requirements engineers and one modeler can do this if they do not rekey text.
3. The supplier uses Polarion. What should be standardized so traceability survives across three tools?
Read the worked answer
Standardize a tool-neutral requirement identifier and a small link vocabulary. Every requirement proxy should carry a stable ID, source system, version, and URL, regardless of whether the source is DOORS Next, Polarion, or a spreadsheet. Use ReqIF or OSLC for exchange and map requirement types explicitly; do not rely on vendor-specific attributes such as Polarion's work item type names. Keep the trace semantics in SysML: «satisfy», «deriveReqt», «verify», and «refine» should mean the same thing across all three tools. Publish a traceability matrix keyed by the neutral ID, and validate that every proxy resolves to exactly one source record. When a supplier sends a Polarion export, import it into a separate proxy set with the supplier's source identifier, then link to the prime model through the neutral ID. This avoids merging two tool schemas and preserves the audit trail even if one tool is replaced.