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.
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.
Evaluate these programme criteria in Arc
Arc connects requirements, systems and interfaces, controls branch, review and merge, and links verification evidence to the relevant requirements and configurations. Evaluate one representative work package against this guide’s criteria.
Luc will email from luc@archelps.com to arrange setup. Agree scope and data handling before adding programme information.