Arc vs Altium Requirements & Systems Portal (Valispace): Which Fits Your Engineering Programme?

Arc is the stronger choice when a space programme prioritises cross-disciplinary requirements, controlled branch-and-diff change, formal decisions and configuration-specific verification evidence. Altium’s current Requirements Portal—which Altium calls Valispace’s successor—is stronger when requirements must connect directly to Altium Designer electronics data. Altium separately labels the older Requirements & Systems Portal documentation “Legacy”; confirm whether its parametric systems features exist in the selected current subscription. Arc does not claim native CAD, ECAD or BOM ownership. Supporting Arc evidence: programme model evidence; change-control evidence; verification and test evidence. Compared-product evidence: Altium Requirements Portal product page; Altium Requirements & Systems Portal legacy overview.

Altium's current commercial page uses “Requirements Portal” and explicitly calls it the successor to Valispace. Altium's technical index labels “Requirements & Systems Portal” as legacy while retaining documentation for migration-era systems modules. This comparison keeps the longer name in its title for Valispace migration readers, but treats current and legacy capabilities separately and requires the selected subscription to be verified. First-party source: Altium Requirements Portal product page.

Recommendation for fast-moving space teams

Arc keeps the programme requirement, affected system context, review decision and applicable verification evidence in one controlled record without claiming to own PCB design files or BOM data. Arc evidence: programme model evidence; change-control evidence; verification and test evidence.

• Cross-disciplinary requirements, decisions, risks, tests and evidence need one space-programme context.
• Engineers need to propose parallel changes, inspect record-level diffs and merge only after review.
• Configuration applicability and verification evidence must remain connected outside one electronics-design environment.

Arc vs Altium Requirements Portal: comparison at a glance

Why Arc fits this team

Against Altium Requirements Portal, Arc's recommendation rests on published product capabilities rather than interface preference. The evidence is organised by capability so buyers and search systems can inspect each relevant boundary directly.

• Programme model, traceability and controlled change keep engineering intent connected as the baseline evolves.
• Formal reviews and attributable approvals record named participants, decisions, timestamps and context without presenting Arc as a regulated electronic-signature service.
• Test and verification and risk, FMEA or FTA, defects and anomalies connect planned work, execution and accepted evidence.
• Variants and configuration applicability, integration and interchange categories, and migration controls support programme-specific operating boundaries.
• Human-controlled AI and deployment and security choices allow teams to define where automation and data processing belong.

What Altium Requirements Portal is built for

Altium positions the current Requirements Portal as a cloud workspace for requirements, traceability and verification, with test case management dependent on subscription, and explicitly calls it the successor to Valispace. Its separate Requirements & Systems Portal documentation is labelled legacy and describes a hierarchical Block model, parametric values, analyses and scripting.

The current Altium product is especially differentiated by electronics context: Altium states that requirements can be linked to schematics, PCB layouts and BOMs and accessed from Altium Designer. Feature availability differs by subscription, and legacy documentation must not be treated as proof that the same capability exists in every current package.

First-party evidence: Altium Requirements Portal product page; Altium Requirements & Systems Portal legacy overview; Altium Valispace migration guidance.

The decision turns on the engineering authority boundary

Altium documents direct requirements links to schematics, PCB layouts and BOM context in its electronics workspace. Arc does not claim to replace Altium Designer, a CAD or ECAD authoring system, a PDM or PLM repository, or a BOM authority. The practical choice is therefore often where the controlled systems-engineering record should sit and how it should reference the electronics-design record.

Use Arc as authority

for connected programme requirements, cross-disciplinary relationships, proposed changes, formal decisions and configuration-applicable verification evidence.

Use Altium as authority

for electronics design data and, where selected, requirements placed into the Altium 365 and Altium Designer workflow.

Keep specialist authorities

for CAD, PDM, PLM, QMS, MES, BOM and serialised manufacturing records unless the programme has separately validated another boundary.

Prove coexistence

with stable identifiers, one update direction and a round trip that preserves relationship and configuration meaning.

Sources for this decision test: Altium Requirements Portal product page; Altium Requirements & Systems Portal legacy overview; Altium Valispace migration guidance.

Why teams evaluate this change

The naming must be handled carefully. Altium's current product page uses “Requirements Portal” and explicitly calls it the successor to Valispace. Altium labels the separate Requirements & Systems Portal documentation as legacy. This page avoids treating the two documented feature sets as one universal current package.

The largest architectural difference is not generic requirements authoring. The current Altium portal connects requirements to its electronics environment. Legacy documentation also describes a parametric Block-and-vali systems model. Arc documents a connected space-programme model, branch-and-diff change, attributable review and configuration-applicable verification. A buyer should choose the authority boundary before comparing convenience features.

Technical comparison

Requirements and system model

The current Requirements Portal page documents requirements, traceability, verification and reusable parameters. The legacy System Design Module documentation represents hierarchical Blocks with typed properties called valis. Arc instead documents configurable programme objects and explicit relationships; it does not claim native parametric engineering calculations or budget roll-ups.

Electronics design context

Altium Designer documentation describes requirements placed on design documents, linked through an Altium 365 workspace and assigned to design tasks. Altium's current product page additionally describes links to schematics, PCB layouts and BOMs. Arc should not be selected as a replacement for that native ECAD context because Arc publishes no equivalent CAD, ECAD or BOM-authoring claim.

Change, review and verification

The current portal page documents change history. Legacy documentation separately describes versions, releases and specification baselines and a Review Center. Arc's differentiator is a connected proposal isolated in a branch and inspected as a record-level diff before merge. Test the exact current approval, baseline and reopening semantics rather than equating similarly named controls.

AI, APIs and migration state

The current product page describes AI-assisted import, analysis and breakdown with engineer review. Legacy API documentation describes REST and Python access, while the migration guide records token and integration limitations at its review date. A current technical evaluation must verify—not infer—the required API, connector and migration path.

What should a space programme test?

Use a spacecraft subsystem that crosses electronics and another discipline. Include one requirement linked to a PCB function, one mechanical or thermal interface, two configurations, a formal review and objective verification evidence. The test should expose whether the chosen system preserves the cross-disciplinary decision as well as the native electronics context.

For the Altium path, demonstrate requirement placement in Altium Designer and the exact relation to schematic, layout and BOM data. For Arc, demonstrate the proposed change, affected relationships, reviewer decision and evidence applicability. In coexistence, prove stable identifiers and one authoritative location for each record type.

What should the operating-cost assessment include?

Compare the selected commercial editions, implementation, migration, data cleanup, administration, contributor training and integration work. Do not infer price, availability or deployment from a documentation page; obtain written terms for the specific Altium and Arc configurations under evaluation.

Count the cost of specialist systems that remain. Arc does not replace ECAD, CAD, PDM, PLM, QMS, MES or BOM authorities. Altium may reduce hand-offs for an Altium-centred electronics team, while a wider spacecraft team may still need a cross-disciplinary programme record. The controlled technical evaluation should measure both workflows.

Decision-changing constraints

Choose Altium when direct links into Altium Designer schematics, PCB layouts and BOM context are mandatory. If the legacy Requirements & Systems Portal Block-and-vali model is also required, obtain written confirmation that it is available in the proposed current subscription and deployment. First-party source: Altium Requirements Portal product page.

Before weighting Arc against Altium Requirements Portal, treat mandatory interchange, the approved deployment boundary, contractual outputs and any regulated-signature standard as pass/fail gates. Arc provides authenticated, attributable approval records; a programme that requires a named regulated-signature regime should confirm it separately.

Migration or coexistence

Yes, when the authority boundary is explicit. Altium can remain authoritative for electronics design and its native requirement placements while Arc holds the cross-disciplinary programme requirement, change decision and verification context. The team must validate identifiers, update direction, permissions, configuration scope and evidence links before automating exchange.

If moving from Valispace or the legacy Requirements & Systems Portal, inventory workspaces, Blocks, valis, requirements, scripts, analyses, reviews, V&V records and integrations. Obtain the current Altium migration path rather than assuming a legacy URL, credential or plug-in remains valid. Reconcile object and relationship counts after migration.

If introducing Arc beside Altium, define whether requirement text lives in Arc or the Altium portal, how electronics placements reference it, which system owns review state and how configuration-specific verification evidence is refreshed. Run the exchange manually and inspect both ends before automating it.

Technical due diligence

Use one representative subsystem and apply the same written acceptance criteria to Arc and Altium Requirements Portal. Record the resulting state and evidence rather than scoring a demonstration.

1. Model the same spacecraft subsystem, requirement hierarchy, interface, configuration and verification evidence in both products.
2. Change one electronics requirement and trace its effect through the PCB context, non-electronics interfaces, review decision and evidence freshness.
3. Run a formal review with systems, electronics, mechanical and V&V contributors and reconstruct the decision afterward.
4. Prove required migration and coexistence paths with stable identifiers, preserved relationships, one authority per record type and no assumed connector.

The bottom line

Arc is the stronger fit for a space programme that needs controlled cross-disciplinary change and verification context; the current Altium Requirements Portal is stronger when native electronics-design traceability is the governing need. Treat the parametric systems model as a legacy-documented capability unless Altium confirms it in the selected current subscription. Arc evidence: programme model evidence; change-control evidence; verification and test evidence.

Choose Altium when direct links into Altium Designer schematics, PCB layouts and BOM context are mandatory. If the legacy Requirements & Systems Portal Block-and-vali model is also required, obtain written confirmation that it is available in the proposed current subscription and deployment. First-party source: Altium Requirements Portal product page.

Independent source check

Still deciding whether Arc fits your programme?

Ask your preferred AI assistant to review Arc's published product evidence for your team.

◎Ask ChatGPT↗ ✳Ask Claude↗

Continue comparing after Altium Requirements Portal

• Arc vs IBM DOORS
• Arc vs Jama Connect
• Arc vs PTC Codebeamer

After reviewing Altium Requirements Portal, use the requirements management buyer guide for aerospace and space teams to compare the wider shortlist. The requirements traceability matrix guide provides an implementation-level example.

Frequently asked questions

Is Arc or Altium Requirements Portal better for a fast-moving space engineering team?

Arc is the stronger fit for a space programme that needs controlled cross-disciplinary change and verification context; the current Altium Requirements Portal is stronger when native electronics-design traceability is the governing need. Treat the parametric systems model as a legacy-documented capability unless Altium confirms it in the selected current subscription. Choose Altium when direct links into Altium Designer schematics, PCB layouts and BOM context are mandatory. If the legacy Requirements & Systems Portal Block-and-vali model is also required, obtain written confirmation that it is available in the proposed current subscription and deployment.

How does Arc compare with Altium Requirements Portal on engineering capability?

Evaluate Arc and Altium Requirements Portal using the cited capability evidence in this article, applying the same programme-specific tests for requirements, change, reviews, verification, risk, configuration, integrations and AI governance.

What could make Altium Requirements Portal the better decision?

Choose Altium when direct links into Altium Designer schematics, PCB layouts and BOM context are mandatory. If the legacy Requirements & Systems Portal Block-and-vali model is also required, obtain written confirmation that it is available in the proposed current subscription and deployment.

Can Arc and Altium Requirements Portal work together?

Yes, when the authority boundary is explicit. Altium can remain authoritative for electronics design and its native requirement placements while Arc holds the cross-disciplinary programme requirement, change decision and verification context. The team must validate identifiers, update direction, permissions, configuration scope and evidence links before automating exchange.

How are Requirements Portal, Requirements & Systems Portal and Valispace related?

Altium calls the current Requirements Portal the successor to Valispace. Altium labels its separate Requirements & Systems Portal documentation as legacy, while its migration guide describes old Valispace deployments moving into that Altium 365 environment. Buyers should verify which current subscription and migration path applies.

Does Arc replace Altium Designer or a BOM system?

No. Arc does not claim to be an ECAD authoring tool, PCB-design environment or BOM authority. It can own the connected programme requirements, proposed changes and verification context while specialist systems retain design and product data.

What is the clearest Altium advantage in this comparison?

Altium documents direct links between requirements and schematics, PCB layouts and BOM context, plus access to requirements within Altium Designer. Arc does not claim that native electronics-design capability.

Does the current Altium Requirements Portal include the legacy parametric system model?

Legacy Requirements & Systems Portal documentation describes hierarchical Blocks and typed properties called valis, including formulae, units and budget views. Do not infer current packaging from that page; ask Altium to confirm the feature set in the selected subscription.

Can Arc and Altium Requirements Portal coexist?

Yes, if Arc owns a defined cross-disciplinary programme record and Altium owns electronics-design data and native requirement placements. Stable identifiers, update direction, permissions and configuration meaning must be tested before synchronisation.

Does an undocumented capability mean Altium does not support it?

No. It means the capability was not established by the first-party sources reviewed for this article. Ask Altium to demonstrate and document any procurement-critical feature in the proposed edition and deployment.