Inventory requirements, parameters, links and electronics context before export, then prove what transferred and what needs a controlled reconstruction. The fastest reliable decision comes from testing one representative programme slice, not from counting generic features.
What is the direct answer?
Inventory requirements, parameters, links and electronics context before export, then prove what transferred and what needs a controlled reconstruction. Keep contractual formats, current integrations, deployment constraints and the people who must use the system in the decision. This guide is vendor-authored by Arc; it does not claim independent lab testing or customer results.
What should the migration preserve?
Use one requirement set with stable identifiers, hierarchy, attributes, owners and typed relationships. Include an interface, an open change, a verification method, a test record and its evidence. Keep the source read-only while record counts, field values, attachment inventories and relationship direction are reconciled.
- Requirement IDs, revisions, rationale, ownership and applicability.
- Upstream and downstream relationships with direction and type intact.
- Reviews, decisions, verification status, test evidence and configuration context.
- An export route that does not trap the programme in screenshots or presentation slides.
What is specific to Altium Requirements Portal?
Inspect requirement and parameter records, links to electronics context, attachments, exports and any legacy Valispace information the programme still depends on. Do not assume a capability shown in one edition, add-on or deployment exists in the exact configuration being evaluated; record that boundary in the scorecard.
Use one hard test instead of a feature checklist
Run an illustrative CubeSat power change. The accepted payload cap is 20 W and the current design point is 18 W. Propose 24 W. Total peak demand rises from 54 W to 60 W against 59 W available, so margin moves from +5 W to −1 W and the proposal is 4 W over the requirement cap. The tool should identify the electrical interface, owners, verification records and evidence that need review. These numbers are a synthetic evaluation case, not customer data or measured Arc output.
Score the workflow, not the demonstration
- Source integrity
- Can the team see the authoritative requirement revision, rationale, owner and applicability without opening parallel copies?
- Relationship integrity
- Do imported and edited links retain their type and direction, and can a reviewer follow them back to their source?
- Change control
- Can contributors explore the 24 W proposal without overwriting the accepted 20 W cap, then compare and approve an attributable diff?
- Verification continuity
- Does the changed requirement identify which method, test case, configuration, result and evidence may now be stale?
- Engineer effort
- Count manual exports, field repairs, status slides and follow-up messages needed to reach a defensible answer.
- Exit route
- Export the evaluated slice and verify that IDs, values, relationships and evidence remain usable outside the tool.
When is the current approach still rational?
Keeping Altium Requirements Portal can be the lowest-risk choice when mandatory exchange formats, validated procedures, trained users or adjacent lifecycle systems depend on it. Switching tools does not remove weak ownership, unclear acceptance criteria or missing links. Price the migration, retraining and temporary split source of truth alongside licence and configuration cost.
What should be verified before rollout?
Ask the shortlisted vendor to demonstrate permissions with two roles, a rejected proposal, a reopened verification item and a complete export. Record the product edition, deployment model and date. Then have a systems engineer, subsystem owner and verification engineer repeat the workflow without vendor assistance. A polished demo is less useful than observing where those three people lose context, need an administrator or recreate information by hand.
What does a defensible result look like?
The final evaluation pack should contain the source inventory, mapping decisions, exceptions, record counts, relationship counts and the accepted score for each criterion. Capture the time spent by each role and list every manual repair. For a migration, retain a read-only source snapshot and record who reconciled the destination. For a selection, keep the completed workflow and export from every finalist. This gives the decision an inspectable basis without pretending that one synthetic scenario predicts every programme outcome.
Where does Arc fit?
Arc connects requirements, systems, interfaces, risks, changes, verification activities and evidence in one programme graph. Branches let teams prepare changes without rewriting the accepted baseline. Through the Arc MCP server, compatible AI tools can search permitted records, follow traceability, assess impact and prepare controlled updates; configured permissions, human review and merge authority still apply.
How should a team decide?
- Write down the non-negotiable exchange, security, validation and deployment constraints.
- Use the same source package and CubeSat change in every shortlisted tool.
- Have the engineers who own requirements, interfaces and evidence complete the work themselves.
- Score missing context, manual reconstruction, review clarity and export completeness.
- Choose the lowest-maintenance option that meets the programme’s actual authority model.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.