Jira is a capable work tracker, but a requirements system must prove more than issue links. For a small software-heavy project, disciplined issue types and a named owner may be enough. For a spacecraft programme with allocations, baselines and verification evidence, test whether the configured Jira estate actually preserves those meanings. This is Arc's source-based assessment, not an independent lab review.
What does Jira already do well?
Atlassian documents Jira's issue and workflow model. Engineers already use it for implementation, defects and coordination, and marketplace apps can extend it. That familiarity is valuable. Review the actual project and installed apps rather than judging an unconfigured Jira instance.
Which requirements controls must Jira prove?
Use a synthetic imaging downlink requirement that allocates data rate to radio hardware and flight software. Identify the accepted statement and revision, its parent, the design implementation, a verification method and the result for the applicable configuration. Change the data rate and ask which evidence becomes suspect. If issue links have no typed meaning, the team may have to reconstruct the answer manually.
Does delivery completion establish verification?
A software task marked “done” is not necessarily a passed product test or an approved requirement. Define separate authorities for implementation status, test result and acceptance. NASA's verification guidance describes evidence against specified requirements; use the customer's governing standard where applicable.
What should decide the choice?
Keep Jira as delivery authority when that flow is effective. Add a dedicated engineering record when requirements, approvals and evidence cannot be defended from Jira's configured model. Arc can provide the connected programme context, while Jira retains work items. Test the actual exchange boundary and avoid duplicating authoritative text in both.
Frequently asked questions
Can a Jira app turn it into a requirements system?
An app may add needed controls. Evaluate the installed app, its licence and the exact baseline, traceability and verification workflow.
Does closing a Jira issue verify a requirement?
No. Verification requires an identified method, applicable configuration, result and evidence accepted by the right authority.
Should a team remove Jira after adopting Arc?
Not necessarily. Jira can remain the implementation and defect tracker while Arc owns approved engineering requirements.
How should a downlink-rate allocation appear in Jira?
Identify the accepted requirement and revision, then distinguish its allocations to radio hardware and flight software from implementation and verification links. A generic issue link does not explain which responsibility or evidence is affected when the downlink rate changes.
What should we test in the installed Jira project before choosing another tool?
Use the project, apps and licences the team actually has. Change an accepted requirement and check how affected allocations, design links and evidence are identified, who can disposition them and which history survives. Assign one authority for engineering requirements and another for delivery status where needed.