Jama Connect is a strong default when formal stakeholder reviews are already working. Its documented review and traceability features deserve a real comparison, especially if suppliers and approvers have adopted them. The case for an alternative is stronger when a space team wants requirement decisions linked more directly to system architecture, interface changes and configuration-specific verification, or when an inherited Jama workflow imposes too much administrative work. This is Arc's vendor-authored assessment.
How does the working model differ?
Jama's documentation describes relationships, reviews, baselines and test management. That makes “does it have traceability?” a weak question. Ask who creates a change proposal, how a reviewer sees its effect on a subsystem, what is approved, and which test result becomes suspect. A review packet can be excellent while the engineering context around it still requires manual assembly.
Why are we considering a move?
- Arc: assess connected programme context, branch-based changes and verified evidence for a focused space team.
- ReqView: assess a document-oriented requirements workflow with Git or SVN versioning; confirm the edition needed for team collaboration and exchange.
- Polarion: assess if the organisation is aligning requirements and software ALM within Siemens tooling.
- Codebeamer: assess when broader PTC lifecycle and product-line controls are in scope.
- Visure: assess tailored requirements and assurance-oriented processes, including the effort to configure them.
What should the review trial test?
In a synthetic attitude-control example, a reaction-wheel interface gains a tighter torque limit. Have the subsystem lead propose the change, a systems engineer inspect affected requirements, and verification staff identify tests tied to the old limit. Ask each tool to preserve the accepted version while reviewers comment, reject or approve the proposal. Compare the evidence available to a late reviewer, not the speed of a prepared vendor demo.
Blank retained change-review record
- Offered edition/configuration and trial scope:
- Accepted requirement ID/revision and original torque limit:
- Proposed requirement ID/revision and changed torque limit:
- Subsystem reviewer and systems reviewer:
- Suspect test/procedure/result and assessed configuration:
- Comment, reject/approve decision and retained rationale:
- Late-review reconstruction evidence:
- Open exception, owner and next action:
- Populate observed behaviour only after running the trial.
How does migration affect the choice?
Inventory Jama item types, relationship rules, reviews, test records, baselines and attachments before deciding to move. Jama review exports can carry activity or version information as documents, but exporting requirements does not automatically recreate that history as native destination reviews. Decide what remains an archive, what is reconstructed and what becomes authoritative. If a mature Jama process already passes this test, improving that process may be cheaper than replacing it.
Where does Arc fit?
Arc's programme model connects requirements with architecture, interfaces, risks and verification. Its change workflow lets engineers inspect branch differences before a merge. Evaluate those behaviours with the same reviewers and source set used for Jama; security, deployment and exchange needs can still decide the result.
Frequently asked questions
Is Jama Connect weak at reviews?
No. Structured reviews are a documented strength. Test whether the review carries enough system and verification context for your programme.
What is the hardest part of leaving Jama?
Mapping item types and relationships is only part of it; review activity, decisions, baselines and attachments need separate preservation decisions.
When would Arc be preferable?
Evaluate Arc when connected space-programme context and branch-based engineering change are the governing needs, subject to a pilot of your real review and evidence workflow.
Does exporting Jama requirements recreate native review history in another tool?
No such equivalence follows from the export. Inventory review activity, decisions, versions, baselines and attachments, then decide what remains a controlled document archive and what must be reconstructed in the destination. Test the resulting late-reviewer view before changing authority.
How should the tighter reaction-wheel torque limit be reviewed?
Keep the accepted interface revision available while the subsystem lead proposes the tighter limit. Have systems and verification reviewers identify affected requirements and evidence for the old limit, then reject or accept the proposal with its rationale. Compare what a later reviewer can reconstruct in each candidate.