Spreadsheets are usually the right starting point for a small, stable requirement set with simple relationships and clear ownership. Arc becomes the stronger option when concurrent contributors, many-to-many traceability, frequent change, multiple configurations or verification evidence make the spreadsheet expensive to keep trustworthy.
The decision is not spreadsheet bad, software good. Excel and similar tools are familiar, flexible and easy to exchange. The threshold arrives when the team spends more effort maintaining links, versions and review status than using the information to make engineering decisions.
Quick decision guide
- Choose requirements spreadsheets when: The requirement set is small, relatively stable and owned by one or two people.
- Choose Arc when: Multiple disciplines edit related requirements and evidence concurrently.
- Validate the choice by: Choose one active spreadsheet with real hierarchy, links, status and verification data.
Arc vs requirements spreadsheets: comparison at a glance
| Criterion | Arc | requirements spreadsheets |
|---|---|---|
| Time to start | Requires workspace setup and migration | Immediate for most teams |
| Data model | Typed objects and explicit relationships | Rows, columns, tabs and team conventions |
| Traceability | Navigable many-to-many links across the programme | Repeated identifiers, formulas, lookups or manually maintained matrices |
| Collaboration | Contextual change proposals, review and merge | Shared editing, comments and file or workbook controls |
| Baseline history | Connected change history and controlled programme baseline | Copies, protected files or external document control |
| Change impact | Follow upstream and downstream relationships before approval | Manual searches, formulas and engineer knowledge |
| Verification | Link methods, tests, results and evidence to requirements | Columns, tabs, file paths and separate evidence stores |
| Best fit | Growing or complex space programmes | Small, early or relatively stable requirement sets |
What requirements spreadsheets are built for
A well-owned spreadsheet can be entirely appropriate. It is transparent, portable, easy to tailor and accessible to almost every stakeholder. For a contained subsystem with one owner and straightforward requirement-to-test links, dedicated software may add unnecessary process.
The failure mode is gradual. More tabs, repeated identifiers, hidden formulas, copied baselines, file links and status columns accumulate until no one can confidently answer which version is authoritative or what a proposed change affects.
Why teams evaluate an alternative
Teams evaluate an Excel requirements management alternative when the workbook remains easy to edit but increasingly difficult to trust. Typical signals include parallel copies, hidden formulas, inconsistent identifiers, repeated status columns, broken file links and manual reconstruction of traceability before every major review. The problem is not the spreadsheet format itself; it is the growing coordination system around it.
Modern Excel improves collaboration. Microsoft documents co-authoring, Show Changes and version history for supported Microsoft 365 workflows. Those features address concurrent file editing, but they do not automatically create systems-engineering relationship semantics, coverage rules or verification evidence governance.
Capability-by-capability comparison
Requirements authoring and data model
A spreadsheet is transparent and adaptable: columns can hold identifiers, text, rationale, owner, status and verification method with almost no setup. Arc requires a defined item model but can represent systems, requirements, interfaces, tests and evidence as related objects. The tipping point comes when rows and columns can no longer express the programme's relationships without duplication.
Traceability, baselines and change control
Spreadsheets can build traceability matrices with identifiers, formulas, lookups and separate tabs. Many-to-many relationships become difficult when records move, identifiers change or several configurations diverge. File history can recover a workbook version, while Arc is intended to review the changed engineering objects and affected relationships before an approved merge into the programme baseline.
Reviews, verification and evidence
Comments, protected ranges and shared editing can support lightweight review. Formal approval often moves into email, meeting minutes or document control, while evidence is referenced through paths and filenames. Arc keeps review context and verification records connected to requirements. Compare how quickly a reviewer can move from a requirement to its current result and objective evidence.
Deployment, administration and exchange
Excel is already available in many organisations, widely understood and convenient for contractual exchange. Its hidden administration cost is the manual policy for file naming, access, copying, reconciliation and report generation. Arc introduces implementation and migration work, but can make relationship and baseline controls part of the working environment. Controlled spreadsheet exports can remain deliverables.
Aerospace and space programme fit
A spreadsheet may be entirely suitable for an early concept, a small subsystem or a stable requirement list with one accountable owner. Risk rises when suppliers return edited copies, several spacecraft configurations share requirements, interfaces change frequently or verification evidence is distributed across folders and test systems.
For PDR or CDR, time how long it takes to identify the approved requirement set, missing traces, unresolved changes and incomplete verification. Then change one shared interface and trace every affected requirement, test and configuration. This practical exercise reveals the migration threshold more reliably than row count alone.
Total operating cost and implementation effort
A spreadsheet has low acquisition and training cost, particularly when Microsoft 365 is already licensed. Count the engineering time spent reconciling copies, maintaining formulas and identifiers, rebuilding review reports, checking links and answering questions about the authoritative version. These costs are usually distributed across the programme rather than recorded as tool administration.
For Arc, include commercial pricing, data cleanup, import mapping, training and any integration work. The business case becomes credible when the pilot measures fewer missed relationships, shorter review preparation or higher confidence in the current baseline. A small stable workbook may never recover the implementation cost of a dedicated platform.
Migration and adoption path
Start by cleaning stable identifiers, duplicate rows, pick-list values and the meaning of every relationship column. Decide which workbook is authoritative and freeze uncontrolled copies. Import one hierarchy with its links and verification records, then reconcile object and relationship counts against the source.
Run the next real change in Arc while the workbook remains a read-only comparison. Generate a controlled spreadsheet export for stakeholders who still need that format. Once the workflow is accepted, define Arc as the working authority and use spreadsheets for exchange, analysis or reporting rather than parallel editing.
When Arc may not be the right choice
Arc may not be the right choice for a small, stable requirement set with one owner, simple one-to-one traceability and infrequent review. Spreadsheets also remain useful for calculations, temporary analysis, controlled customer templates and generated reports even after the connected programme model moves elsewhere.
Where Arc takes a different approach
- Relationships instead of repeated cell values. Requirements, systems, tests and evidence are connected objects rather than identifiers copied across tabs.
- Safe parallel change. Contributors can work in branches, compare diffs and merge approved updates.
- Continuous impact analysis. The programme can show affected upstream and downstream records when a requirement changes.
- Agent-assisted maintenance. Configurable agents can check coverage and propose traceability or requirement updates for review.
Which option should your team choose?
Choose requirements spreadsheets when
- The requirement set is small, relatively stable and owned by one or two people.
- Relationships are simple enough to review manually.
- The spreadsheet is a delivery format rather than the only working source of truth.
- The team is still learning which process and fields it actually needs.
Choose Arc when
- Multiple disciplines edit related requirements and evidence concurrently.
- Many-to-many relationships make the matrix hard to reconcile.
- Frequent changes require repeatable impact analysis and review.
- PDR, CDR or verification preparation has become a recurring reconstruction exercise.
What to test before making a decision
Do not decide from a feature checklist alone. Use one active subsystem and run the same engineering change through both candidate workflows.
- Choose one active spreadsheet with real hierarchy, links, status and verification data.
- Clean stable IDs and define the meaning of each important relationship before import.
- Run the next real change in Arc while retaining the spreadsheet as a controlled comparison.
- Measure review time, missed links, reporting effort and confidence in the current baseline.
Can Arc and requirements spreadsheets work together?
Yes. Spreadsheets can remain useful for stakeholder exchange, controlled exports, one-off analysis and contractual deliverables while Arc holds the connected working model. The team should avoid editing both as competing authorities.
The bottom line
Stay with spreadsheets while they remain understandable and trustworthy. Move to Arc when maintaining the spreadsheet has become a hidden systems-engineering workload and the programme needs relationships, evidence and change history to remain current by design.
Related Arc comparisons
- Arc vs Jira for requirements management
- Arc vs open-source requirements management tools
- Arc vs IBM DOORS
To see the wider market before shortlisting a platform, read the best requirements management tools for aerospace and space teams. For an implementation-level traceability example, use the requirements traceability matrix guide and template.
Frequently asked questions
When should a team stop managing requirements in Excel?
The strongest signals are frequent conflicting copies, broken links, many contributors, complex traceability, multiple configurations and repeated manual reconstruction before reviews.
Can Arc import an existing requirements spreadsheet?
Arc's published product guidance describes starting with one active programme spreadsheet and mapping its requirements, fields, links and verification evidence into a connected model for review.
Should every spreadsheet be replaced?
No. Spreadsheets remain useful for small controlled lists, calculations, exchange and generated reports. The key is to define which system is authoritative for requirements and relationships.
Does Excel version history solve requirements change control?
It helps recover and inspect workbook changes, but it does not by itself define engineering relationship impact, approval semantics, configuration applicability or verification closure.
How many requirements are too many for Excel?
There is no universal row limit. Migration is driven more by contributors, relationship complexity, change frequency, configurations, review effort and evidence distribution than by requirement count.
Can teams still export requirements to Excel from Arc?
Spreadsheets can remain useful controlled exchange or reporting formats. The important governance decision is that exported files do not become competing editable authorities.
Evaluate Arc on a real programme workflow
Bring one representative requirement set, one proposed change and its verification evidence. Arc can then be assessed against the workflow and controls your team actually needs. Book a working session with Arc.