Arc and ECLIPSE Suite overlap in requirements, traceability, controlled change, review and verification, but the product boundaries differ. Arc’s connected programme model links engineering records with branch-based changes. Sapienza Consulting’s ECLIPSE Software Suite is a modular space-project environment, with RVM for Requirements & Verification Management and associated modules for document control, formal reviews, risks and non-conformances.
Shortlist Arc for a new requirements workflow when connected architecture, interface changes and configuration-specific evidence are central. Give ECLIPSE serious consideration where its document and review environment already works for your team or customer. Selection still depends on a demonstration of the required records, permissions and handover. This page does not establish that Arc replaces every function in ECLIPSE’s entire suite.
Go to the product boundaries, comparison table, shared evaluation, pricing and trials or FAQs.
ECLIPSE Suite, RVM and solution packages
This comparison concerns ECLIPSE Software Suite at eclipsesuite.com. Its current website and Master Services Agreement attribute the offering to Sapienza Consulting. It is unrelated to Eclipse IDE or Eclipse Foundation modelling projects.
The product catalogue is the useful starting point. RVM addresses requirements and verification management. Document Configuration and Change Management (DCCM) controls documents and approved data packs. Review Items of Discrepancy (RID) manages formal review participation, findings and closure. RISK, Non-Conformance Tracking System (NCTS) and Action Items Management (AIM) address their respective processes.
There are documented connections between modules. DCCM can send an approved document collection to RID as a data pack. RISK and NCTS link actions into AIM. These connections matter when comparing a requirements-only scope with a wider review or product-assurance process. Ask ECLIPSE to identify the modules, services and configuration in the proposed solution instead of assuming every listed function is included in an RVM quote.
The ECSS Compliance Package names document management, non-conformance, risk, technical review and task/action management. Its public description does not settle the exact RVM entitlement in your order. Arc’s current product scope covers connected requirements, architecture, interfaces, change, reviews, risks and verification. Exact document-pack exchange, specialist assurance workflows and integrations remain acceptance questions.
Who should shortlist each?
- An existing ECLIPSE document or review team: evaluate RVM within that environment first. Established access, approved data packs, review history and operating knowledge can be valuable. A replacement needs a demonstrated reason and an accepted way to preserve those records.
- A supplier under customer tool constraints: establish the required delivery system, formats and review route before choosing. Arc’s suitability remains unresolved if a mandatory ECLIPSE exchange or board process cannot be reproduced or retained.
- A space team choosing a new requirements workflow: compare Arc’s connected change and evidence model with the proposed ECLIPSE RVM solution using the same source set. Include subsystem engineers, verification, configuration management and reviewers.
- A team planning a contained programme trial: limit the exercise to one subsystem and a consequential change. Confirm both vendors’ enabled scope and data rules before importing controlled information.
- A team working effectively in controlled spreadsheets: keep that approach while ownership, revisions and evidence remain clear. A new platform should solve an observed coordination need, not add process solely for its own sake.
For a wider shortlist, use the aerospace and space buyer guide. The startup guide focuses on the next programme milestone. Neither company size nor the word “suite” alone establishes the right choice.
Evidence-based workflow comparison
Each row identifies the published scope and the question it leaves open. Module documentation and vendor policy pages are evidence of what a vendor states, not independent proof of equivalent behaviour or availability in every deployment.
| Criterion | Arc: public scope and limits | ECLIPSE: module scope and limits |
|---|---|---|
| Requirements capture and organisation | Arc’s programme model connects requirements with architecture, systems and interfaces. Confirm the fields and hierarchy your team will maintain. | RVM lists capture, custom metadata, prioritisation and categorisation. The module catalogue describes a central, version-controlled repository. |
| Traceability to design and verification | Arc documents bidirectional traces and downstream context. Relationship meaning and completeness depend on the maintained model. | RVM documents requirements traceability and links to design, verification and validation data. Ask to navigate the actual relationship types and affected records. |
| Versioning and controlled change | Branches, record differences, discussion, review and merge support changes before a controlled baseline is updated. | RVM describes version control and change management. The catalogue adds comments and status indicators. These sources do not establish branch-and-merge equivalence. |
| Formal review and approval | Named reviewers, comments, due dates and attributable decisions are in Arc’s public scope. Confirm the required board and supplier process. | RID manages formal reviews, data packs, panels, board access, actions and discrepancy closure. DCCM provides document review and approval cycles. Do not attribute this full process to RVM alone. |
| Verification results and evidence context | Arc connects planning, execution, results and evidence to requirements and configurations. Evidence sufficiency remains an engineering decision. | RVM explicitly covers requirements and verification management and linked verification data. Demonstrate procedure, execution, configuration, failed results and re-verification handling. The public module summary does not settle that detail. |
| Document and configuration management | Arc represents configuration applicability and baselines. Its connected records do not establish replacement of every document-control or technical-data-package function. | DCCM records document reference, applicability and status, creates approved data packs for RID and supports XML Technical Data Package import/export. Confirm DCCM and RID in the proposed scope. |
| Risks and non-conformances | Arc supports configurable risk, FMEA, FTA, defect and anomaly workflows. Agree the schema, dispositions and authority. | RISK records assessments, history and mitigation actions linked to AIM. NCTS handles non-conformances, review boards, attachments and closure actions. These are separate modules. |
| Collaboration and permissions | Arc review collaboration operates with granular roles described on its security page. Test supplier visibility and administrative authority. | RVM lists predefined roles and access control. AIM allocates actions to an actionee and contributors with discussion and attachments. RID and NCTS document their own access boundaries. |
| Integrations, API and interchange | Arc publishes an authenticated REST API. Named connectors and interchange still need deployment-specific confirmation. An API does not prove an ECLIPSE integration. | DCCM documents XML package exchange and interfaces with RID/AIM. AIM documents export. The reviewed sources do not establish RVM exchange formats or a general external API contract. Request current documentation. |
| AI assistance and human authority | Arc agents surface, check, draft and propose within configured permissions. Engineers govern controlled changes. Review model routes and data handling on the security page. | ECLIPSE’s September 2026 AI article separates AI access from authority and keeps formal decisions with engineers. It is guidance on using AI alongside a controlled environment, not evidence of a particular shipped RVM AI feature. |
| Hosting and security | Arc publishes SaaS, on-premises and air-gapped deployment options. BYODB, model processing and controls depend on configuration. Assess the proposed environment. | Start-Up lists vendor hosting, while SME and Enterprise also list on-premises. The SaaS service describes a configured, managed environment. Obtain specific residency, identity, retention, backup and assurance evidence. |
| Evaluation, training and commercial model | The existing Arc free-trial request leads to setup arranged by email. No numeric Arc price, fixed trial length or immediate access is promised here. | ECLIPSE advertises a free demonstration and trial. Plans distinguish training and support. Services cover configuration, migration and training. Price depends on the agreed solution, hosting and services. |
A shared supplier-change evaluation
Fictional example, not a completed test. A supplier delivers a power-conditioning subsystem against a customer requirement set. Customer requirement CUST-PWR-014 revision B limits an interface transient. The supplier allocates it to SUB-PWR-032 revision 2, procedure VP-008 and test report TR-008 for hardware configuration HW-03. Review action RA-021 asks the supplier to justify the margin.
The customer proposes CUST-PWR-014 revision C with a changed transient limit and operating condition. TR-008 still describes the old condition. A reviewer must determine whether the design changes, which evidence remains applicable and what analysis or testing must repeat. The example intentionally leaves the engineering answer open. A trace link or green status cannot make that decision.
Give both vendors the same requirement records, revision history, procedure, report and open action. Add a supplier contributor and a customer reviewer with different permissions. Ask them to demonstrate these six tasks in the proposed configuration:
- Preserve identity and revisions. Show the customer and supplier IDs, their revisions and relationship direction. Keep revision B and its decisions interpretable after proposing C. Explain how external identifiers map to internal records.
- Expose impact. Navigate from the changed interface requirement to the allocation, relevant design context, procedure, report and review action. Introduce one missing relationship and show how a reviewer would detect or record the gap.
- Keep review ownership explicit. Show who proposes, comments, accepts or rejects the change. Retain the reason, reviewed context and unresolved RA-021. For ECLIPSE, identify the RVM, RID, DCCM or AIM handoffs involved.
- Assess evidence applicability. Preserve TR-008 as the result for HW-03 under the old condition. Record the decision about reuse or repeat work, the responsible engineer and any remaining open verification. Do not silently relabel old evidence as current.
- Prove permission boundaries. Let the supplier see the agreed package while withholding unrelated customer records. Attempt an unauthorised change and inspect the actual response. Include administrator and AI/API authority where those routes are enabled.
- Export an understandable handover. Give another reviewer the export without access to the live workspace. They should reconstruct the requirement revision, configuration, links, evidence, decisions, open work and attachments. Reconcile counts and explicitly list anything omitted.
Record the selected modules, configured rules, manual steps and unsupported tasks alongside the results. Distinguish a configuration gap from missing source data and a required feature that was not demonstrated. Agree acceptance criteria before comparing the outcomes. This produces a useful selection record without assigning arbitrary scores to marketing pages.
Supporting an agreed ECSS process
Requirements software can organise work used in an ECSS-governed programme. ECSS-E-ST-10-06C addresses technical requirements specifications and allows project tailoring. ECSS-E-ST-10-02C Rev.1 addresses formal customer-supplier verification, including a Verification Plan and Verification Control Document. Its scope distinguishes formal verification from development testing and analysis.
Keep four decisions separate: what workflow the software supports, which standards and tailoring apply to the project, whether the customer accepts the evidence and any separate certification or approval process. Buying either product does not certify a programme or guarantee customer acceptance. A module called an ECSS Compliance Package is still software supporting a process that people must define and execute.
Evaluate whether the actual system can connect the applicable obligation to its owner, requirement, document, review and evidence. Check the meaning of an accepted closure and the route for reopening it after change. Arc’s VCD and verification guide and ECSS change-control example explain those record boundaries.
Adoption, migration and coexistence
Inventory the source before estimating a move: RVM records, document packs, review items, actions, risks, non-conformances, attachments, custom fields, permissions and historical baselines. Identify which modules hold the authoritative record and which relationships cross modules. A requirements-text export is not a complete programme archive.
ECLIPSE describes data-migration services into its software environment. That does not establish an ECLIPSE-to-Arc transfer. For either destination, agree ID mapping, revisions, attachment handling, review-history retention and evidence applicability. Validate a representative export against the source, retain an exception register and have the accountable owner approve cutover. No lossless import or fixed deployment duration is promised here.
Coexistence may be worth evaluating where ECLIPSE remains the customer review or document authority while a contained Arc workflow supports internal engineering. It is not an established integration in this comparison. Define ownership, update direction, reconciliation and the accepted delivery package before allowing parallel edits. Keep the source available until the destination and archive pass the agreed checks.
Training and operating effort also need evidence. Ask engineers and administrators to configure the shared example, add a new contributor, repair a link and prepare a handover. Record the effort observed in that evaluation. Neither the age of a product nor the appearance of its interface proves that adoption will be faster or easier.
ECLIPSE Suite pricing, plans and evaluation
As checked on 1 October 2026, the published plans list the following structure. The reviewed plans and requirements pages do not publish numeric prices. ECLIPSE says pricing depends on the solutions, hosting and services required.
| Plan | Published users | Hosting and support distinctions |
|---|---|---|
| Start-Up | 5–49 | Vendor hosting, out-of-the-box product, online helpdesk and chatbot, essential online courses. |
| SME | 50–199 | Vendor or on-premises hosting, customisation options, initial implementation/configuration, onboarding support, online or on-premises courses, helpdesk and chatbot. |
| Enterprise | 200 to unlimited | Vendor or on-premises hosting and the listed SME service categories, plus onsite operational support and tailored consulting/training packages. |
Confirm what “users” means in the quote, which modules are included, external reviewer access, support limits, customisation, hosting responsibilities and export assistance. Compare like-for-like requirements and services. Neither a suite-wide quote nor a module-only quote establishes relative total cost without this scope.
The requirements solution page advertises a free demonstration and trial, with an enquiry option for trial access. It does not establish a fixed trial length, enabled module set or immediate self-service access. Its SaaS service description includes basic project configuration, a demonstration of chosen modules, online help and support within package limits. The plan’s helpdesk chatbot is not evidence of an engineering AI assistant.
Arc’s next step is the existing free-trial request at the end of this article, followed by setup arranged by email from Luc. Confirm scope and data handling before sharing programme data. This page introduces no new Arc pricing, guaranteed trial duration, instant access or bespoke migration service, and makes no claim that Arc is cheaper.
Questions about Arc and ECLIPSE Suite
What is the difference between Arc and ECLIPSE Suite?
Arc connects requirements, architecture, interfaces, risks and verification evidence with branch-based change and attributable reviews. ECLIPSE Software Suite is a modular space-project environment. Its RVM module covers requirements and verification management, while modules such as DCCM, RID, RISK and NCTS address documents, formal reviews, risks and non-conformances. Compare the configured workflows and selected modules your programme needs.
Does ECLIPSE RVM manage requirements and verification?
Yes. The official RVM page names Requirements & Verification Management and describes requirements capture, traceability, version control, change management, user roles and links to design, verification and validation data. The depth of result handling, evidence applicability and export should be demonstrated for the proposed configuration.
How much does ECLIPSE Suite cost?
On 1 October 2026, ECLIPSE listed Start-Up for 5–49 users, SME for 50–199 and Enterprise for 200 or more. The reviewed plans and requirements pages did not publish numeric prices. ECLIPSE says price depends on solutions, hosting and services, so request a quote for the relevant modules and configuration. This comparison establishes no relative price or total-cost advantage for Arc.
Does ECLIPSE Suite offer a trial for smaller teams?
The requirements solution page advertises a free demonstration and trial and provides a trial-access enquiry option. Its plans page includes a Start-Up tier for 5–49 users with vendor hosting. Trial duration, enabled modules, eligibility below five users and commercial terms were not established by the reviewed pages.
Is Arc an ECLIPSE RVM alternative?
Arc is a candidate to evaluate for requirements, connected engineering change, review and verification. It is not established as a replacement for every ECLIPSE module or an existing customer-mandated environment. Demonstrate required document packs, review history, permissions, integrations and handover before choosing or migrating.
Does using either tool make a programme ECSS certified?
No. Software can support the records and workflows used in an agreed ECSS process. Applicable standards and tailoring, engineering execution, evidence and customer acceptance remain project responsibilities. Buying Arc or ECLIPSE Suite does not certify a programme or guarantee its approval.
Can we migrate from ECLIPSE Suite to Arc?
A validated ECLIPSE-to-Arc migration has not been established in this comparison. Assess identifiers, revisions, relationships, attachments, review history and evidence separately, reconcile a representative export and obtain cutover approval. Coexistence is a route to evaluate, not a documented integration or a promise of lossless transfer.
Does ECLIPSE Suite have AI or an API?
ECLIPSE published guidance on AI access, authority and engineering review in September 2026. That article does not establish a specific shipped RVM AI assistant or API contract. DCCM documents XML technical-data-package import and export and interfaces with other ECLIPSE modules. Ask for current API, connector and AI documentation for the selected solution. Missing detail in these sources does not prove a capability is absent.
Sources and comparison method
Sources were checked on 1 October 2026. The comparison uses the ECLIPSE product, module, plan and service pages linked beside each claim and Arc’s public product, capability and security references. The September 2026 ECLIPSE AI article is treated as architectural guidance. Detailed API availability, AI product packaging, RVM interchange and deployment-specific assurance remain questions for the vendors.
No authenticated product workflow, migration or security assessment was performed. The supplier-change exercise is original evaluation guidance. Capabilities, plan terms and source pages can change, so recheck the selected configuration before procurement.
This article is part of Arc’s requirements management software comparison library, where every shortlisted approach is assessed with the same programme-level criteria.
Evaluate Arc
Evaluate a requirements change in Arc
Request a free Arc trial to explore requirements, review and verification using a contained example such as the supplier handover above.
Luc will email from luc@archelps.com to arrange setup. Agree the trial scope and data handling before adding programme information.