Start with the estate, not a replacement ranking. If a customer mandates DOORS exchange, DXL scripts drive approved reports, or years of baselines are part of the delivery record, retaining IBM DOORS may be the least risky answer. A new programme with fewer inherited constraints can compare Arc, Jama Connect, Polarion and Codebeamer on the work its engineers must actually complete. This is Arc's source-based view, not an independent product test.
Are we replacing DOORS or DOORS Next?
Classic DOORS has modules, objects and long-lived enterprise customisation. DOORS Next is a separate web application in IBM Engineering Lifecycle Management. Ask which one the contract, supplier and export process names. A product simply described as a “DOORS replacement” can fail because the required exchange is tied to a particular version, module structure or customised report.
Which alternatives should we shortlist?
- Arc: a focused space programme model when requirements, interfaces, change review and verification need to stay connected.
- Jama Connect: review-heavy stakeholder processes with established traceability and test-management practices.
- Polarion: a Siemens-oriented ALM estate with software lifecycle governance.
- Codebeamer: a wider PTC-oriented ALM programme spanning requirements, risk, testing and delivery.
A lighter tool is attractive only if it meets the controlled exchange and evidence obligations of the actual programme.
What should a DOORS replacement trial prove?
Take one representative module, an approved baseline, a linked lower-level requirement and a verification record. Inventory object IDs, attributes, link modules, access rules and any DXL-dependent transformation. In each candidate, change the lower-level requirement, find affected evidence, review the proposed change and export a package. Reconcile IDs, relationship direction and omitted fields. IBM documents ReqIF exchange for Classic DOORS; whether that satisfies the contract and the target workflow must be demonstrated, not inferred from a format badge.
Blank module reconciliation record
- Trial version/configuration and source baseline:
- Source object ID and destination object ID:
- Attributes and hierarchy reconciled:
- Source/destination link endpoints, direction and role:
- History, permissions and required report checks:
- Omitted or changed meaning:
- Exception owner, decision and recovery:
- Completion evidence and accepting reviewer, after execution:
How do we review the antenna change?
In a fictional antenna deployment case, vibration testing leads to a proposed requirement revision. Trace the system requirement through the mechanism interface, qualification test and waiver decision. Ask a subsystem engineer to find the accepted revision without administrator help, then reproduce the supplier exchange and check link direction after receipt. Identify any DXL-dependent report separately: a successful ReqIF transfer does not recreate its logic or the authority behind the waiver.
Where does Arc fit?
Keep the IBM estate where continuity carries more value than daily friction. Pilot a contained subsystem before any cutover where a new operating model is justified. Arc supports branch review and merge in a connected engineering model; do not assume that means it reproduces DXL, IBM reports or an existing certified process. Cost the temporary split source of truth and retain the source baseline until reconciliation is signed off.
Frequently asked questions
Is DOORS Classic the same as DOORS Next?
No. They are distinct IBM applications with different architecture and workflows. Identify the exact product and version before planning exchange or migration.
When should an aerospace team retain DOORS?
Retain it when contractual exchange, validated reports, DXL customisation or historical baseline continuity controls the programme decision.
Can Arc replace every DOORS integration?
No such blanket claim is supported. Test the required format, module, link and report flows against the proposed Arc deployment before cutover.
What does a successful ReqIF transfer leave unproven?
It can show that the sampled records exchanged correctly, but it does not recreate a DXL report, preserve every history object or establish the authority behind a waiver. Reconcile IDs, attributes and link direction, then separately demonstrate the required report and decision history before retiring the IBM baseline.
Which records belong in the antenna replacement trial?
Use the system obligation, mechanism interface, qualification test, proposed revision and waiver decision against an identified baseline. Ask an ordinary subsystem contributor to find the accepted revision, then send and receive the supplier package and inspect its links. Keep any DXL-dependent transformation as a separate acceptance item.