Skip to content
Arc
Menu

Space

Requirements management for space teams.

Connect mission requirements, spacecraft architecture and verification evidence. Review the impact of design changes with the teams responsible for the system.

Book a demo

02Engineering challenges

Keep the mission, design and evidence in step.

A spacecraft change can reach beyond the subsystem that proposed it.

  1. Changes cross subsystem boundaries

    A payload update can affect power, thermal and data interfaces. Its review needs the connected allocations and responsible owners.

  2. Supplier assumptions diverge

    Revised component specifications can leave the spacecraft and its suppliers working from different interface definitions.

  3. Evidence belongs to an earlier design

    Analysis and test results need a clear link to the requirement revision and spacecraft configuration they assess.

03How Arc helps

Connect the engineering record from mission to verification.

Keep requirements, design changes and evidence in one connected model for the next spacecraft review.

Mission and spacecraft context

Connect mission intent to the spacecraft.

Link requirements to subsystem allocations, interfaces and their source revisions. Keep the rationale and owner with each record.

Inspect the fictional payload requirement

Illustrative engineering example: a fictional spacecraft payload demand proposal, followed through the same requirement, interface, budget and verification records.

These records illustrate a review. They are not customer results, an executed Arc demonstration or an accepted engineering change.

Illustrative engineering example · Payload power change

Requirement

PAY-PWR-014 · Rev A

Awaiting engineer review

  • PAY-PWR-014 · Rev Aconstrains

    Electrical interface

    IF-ELEC-02

    Payload and Power owners

    Awaiting engineer review

  • PAY-PWR-014 · Rev Acontributes demand to

    System power budget

    BUD-PWR-01

    Power owner

    Awaiting engineer review

  • PAY-PWR-014 · Rev Averified by

    Verification work

    VER-PWR-01

    Awaiting engineer review

Awaiting engineer review

Requirement record
RequirementPAY-PWR-014Rev A
Source
Programme payload power requirement
Rationale
Keep payload demand within the agreed power budget
Allocation
20 W, unchanged
Current demand
18 W
Candidate demand
24 W
Verification work
VER-PWR-01
Owner
Payload and Power

Awaiting engineer review

Illustrative engineering example. The source requirement and its allocation are retained. The demand proposal is awaiting engineer review.
Arc FOREST-3 demo requirements table with REQ-013 marked Needs re-verification
Arc FOREST-3 demo. REQ-013 has a candidate change from 150 to 200 W and is marked Needs re-verification.

Change impact and agents

Understand a change before approving it.

Follow a payload update into the electrical interface, power budget and verification work. Compare the candidate values with the current allocation.

Inspect the fictional power comparison
Illustrative engineering example · Payload power change

Payload and spacecraft power · PAY-PWR-014 Rev A

Payload demand

Current

18 W

Proposed

24 W

Payload allocationUnchanged
20 W20 W
Other system demandUnchanged
36 W36 W
Total demand
54 W60 W
Available powerUnchanged
59 W59 W
System margin
+5 W−1 W
Allocation exceedance
None4 W

Affected records

  • Payload and spacecraft power · PAY-PWR-014 Rev A

    IF-ELEC-02

    Payload power interface · Payload and Power owners

  • Payload and spacecraft power · PAY-PWR-014 Rev A

    BUD-PWR-01

    System power budget · Power owner

  • Payload and spacecraft power · PAY-PWR-014 Rev A

    VER-PWR-01

    Verification work to review

  • PAY-PWR-014 Rev A retains the 20 W allocation.
  • Other demand remains 36 W and available power remains 59 W.

Awaiting engineer review

Full change comparison
Payload and spacecraft power · PAY-PWR-014 Rev A
Record / valueCurrentProposed
Payload demand18 W24 W
Payload allocationUnchanged20 W20 W
Other system demandUnchanged36 W36 W
Total demand54 W60 W
Available powerUnchanged59 W59 W
System margin+5 W−1 W
Allocation exceedanceNone4 W

Unchanged constraints

  • PAY-PWR-014 Rev A retains the 20 W allocation.
  • Other demand remains 36 W and available power remains 59 W.

Affected records

IF-ELEC-02
Payload power interface · Payload and Power owners
BUD-PWR-01
System power budget · Power owner
VER-PWR-01
Verification work to review

Awaiting engineer review

Illustrative engineering example. Values show a candidate calculation, not an accepted allocation or a test result.

Review the agent’s reasoning.

Agents help check requirement quality, trace dependencies and flag gaps. Engineers inspect the source records, finding and proposed action before deciding what changes.

Inspect the fictional agent proposal
Illustrative engineering example · Payload power change

Sources

  • PAY-PWR-014 · Rev A
  • IF-ELEC-02
  • BUD-PWR-01
  • VER-PWR-01

Finding

The candidate payload demand exceeds the allocation by 4 W and leaves a −1 W system margin.

Proposed action

Reassess operating assumptions, affected allocations and the system budget. Prepare the required analysis or test before requesting approval.

Engineer review

Awaiting engineer review

Assessment is limited to the supplied fictional sources and maintained relationships. Payload and Power engineers decide what changes.

Source and proposal detail

Sources

  • PAY-PWR-014 · Rev A

    18 W → 24 W demand proposed. 20 W allocation unchanged.

  • IF-ELEC-02

    Affected payload power interface.

  • BUD-PWR-01

    54 W → 60 W demand · 59 W available · +5 W → −1 W margin.

  • VER-PWR-01

    Verification work and evidence decision await review.

Finding

The candidate payload demand exceeds the allocation by 4 W and leaves a −1 W system margin.

Proposed action

Reassess operating assumptions, affected allocations and the system budget. Prepare the required analysis or test before requesting approval.

Awaiting engineer review

Assessment is limited to the supplied fictional sources and maintained relationships. Payload and Power engineers decide what changes.

Illustrative sourced proposal. This is authored teaching content, not an executed agent assessment.
Arc FOREST-3 demo impact analysis showing a proposed branch and conflict notice
Arc FOREST-3 demo. The impact view shows an unapproved branch and a conflict notice for review.

Verification and programme review

Keep evidence tied to the assessed spacecraft.

Connect each requirement to the planned verification, result and hardware or software configuration. Identify evidence that needs another assessment after a change.

Inspect the fictional verification trail
Illustrative engineering example · Payload power change
  1. 01

    Requirement revision

    PAY-PWR-014 · Rev A

    Awaiting engineer review

    assessed by
  2. 02

    Method or procedure

    VER-PWR-01

    Analysis or test to be prepared

    Awaiting engineer review

    represents
  3. 03

    Assessed configuration

    Hardware
    To identify
    Software
    To identify
    Conditions
    To identify

    Awaiting engineer review

    documented in
  4. 04

    Result or report

    No candidate result supplied

    Awaiting engineer review

    reviewed for
  5. 05

    Applicability decision

    Payload and Power owner review

    Awaiting engineer review

All stages remain awaiting engineer review. A linked verification action does not establish a completed check.

Illustrative engineering example. Verification work and evidence applicability remain awaiting engineer review. No result is supplied.

Bring subsystem owners into the decision.

Review proposed work on a branch with the affected payload, power and verification owners. Retain the reviewed programme baseline and the configuration represented by evidence.

Inspect the fictional baseline review
Illustrative engineering example · Payload power change
Main developmentProposed branch
  1. 01Source record

    PAY-PWR-014 Rev A

    Main development
  2. 02Candidate change

    Payload demand 24 W

    Proposed branch
  3. 03Impact review

    IF-ELEC-02 / BUD-PWR-01

    Proposed branch
  4. 04Verification work

    VER-PWR-01

    Proposed branch
  5. 05Awaiting engineer review

    Payload and Power owners

    Proposed branch
  6. 06Pending decision

    Merge only after approval

    Proposed branch

Responsible review

  • Payload and Power
Baseline and configuration detail
Main developmentProposed branch
  1. 01Source record

    PAY-PWR-014 Rev A

  2. 02Candidate change

    Payload demand 24 W

  3. 03Impact review

    IF-ELEC-02 / BUD-PWR-01

  4. 04Verification work

    VER-PWR-01

  5. 05Awaiting engineer review

    Payload and Power owners

  6. 06Pending decision

    Merge only after approval

Programme baseline
Meaning
A named spacecraft programme state, including requirement revisions and open decisions. No new baseline has been accepted in this example.
Assessed configuration
Meaning
The hardware, software and conditions represented by a particular analysis or test. These remain to be identified for VER-PWR-01.
Illustrative review path. Every candidate stage is awaiting engineer review. No merge or new programme baseline is shown as completed.
Arc FOREST-3 demo test record with a retained Pass marked Needs re-verification
Arc FOREST-3 demo. A retained Pass is marked Needs re-verification. The screenshot shows no rerun.

04Standards and assurance scope

Keep ECSS obligations connected to their evidence.

Apply the ECSS editions and tailoring agreed for the contract. NASA guidance can inform relevant programmes. NASA obligations apply where invoked or contractually flowed down.

Link invoked obligations to requirements and verification records. Store the agreed tailoring, source edition and responsible owner alongside the baseline under review.

Connected records, ECSS templates and agents provide starting points for review. They do not establish contractual compliance or programme acceptance.

ECSS-E-ST-10
Systems engineering for space systems and products.
ECSS-E-ST-10-02
Product verification strategy, planning and evidence.
ECSS-M-ST-40
Configuration and information management.
NASA systems engineering guidance
Programme-specific engineering practice and invoked obligations.

Connect supplier and analysis tools through API and MCP.

Retain supplier revisions and analysis assumptions with their spacecraft configuration. Supported exchanges need agreed mappings, permissions and engineer review.

APIMCPSecurity and deployment
API and MCP
Connect supported records through the API, or give a compatible agent permitted programme context and tools through MCP. Agree mappings, permissions and review for the workflow.
Deployment and AI keys
Discuss deployment in your own AWS or Azure infrastructure under an agreed setup. Bring your own key is available for supported AI providers. Agree access, processing locations and retention for the programme.

05FAQ

Frequently asked questions

What does Arc connect for a space programme?

Arc connects mission and subsystem requirements, spacecraft architecture, interfaces, design values and verification evidence. Each record can retain its source, revision and owner so reviewers can follow the engineering context.

How can Arc support review of a payload design change?

Trace the proposed change through connected subsystem requirements, interfaces, budgets and verification records. Review the candidate values and affected owners before accepting the change. The fictional example on this page retains the original payload allocation.

Can Arc help organise ECSS and NASA requirements?

Arc can connect obligations to requirements, tailoring and verification evidence. ECSS-E-ST-10 covers systems engineering, ECSS-E-ST-10-02 verification and ECSS-M-ST-40 configuration and information management. NASA obligations apply where invoked or contractually flowed down. Use the editions and scope agreed for the programme.

Can spacecraft test evidence be reused after a change?

Retain the requirement revision, assessed spacecraft configuration and test or analysis conditions with the result. The responsible engineer assesses what the earlier evidence still supports and which verification needs updating.

How are subsystem and supplier requirements kept aligned?

Keep the supplier source revision, interface definition, allocation and owner connected to the spacecraft requirement. Branch review can bring the affected teams into the decision while retaining the current programme baseline.

Who approves changes suggested by Arc’s agents?

Engineers review the source context, finding and proposed action. Agents help identify requirement and evidence gaps, while the responsible programme owners decide whether to accept a proposed change.

Can a space team use Arc’s API, MCP and its own cloud?

Supported API operations and permitted MCP tools can connect programme records to an agreed workflow. Customer-owned AWS or Azure deployment and supported AI-provider keys are available under an agreed setup. Confirm mappings, access and processing locations before introducing programme data.

What can we review in a space requirements demo?

A demo can follow a representative mission requirement through a subsystem interface, proposed design change and verification review. Book a demo to discuss the workflow and deployment questions relevant to your team.

06Engineering resources

Engineering resources

Browse the blog
  1. ECSS compliance matrix exampleInspect obligations, tailoring and evidence in a worked matrix.Guide
  2. Requirements traceability guideFollow a requirement from its source through allocation, results and evidence.Guide
  3. Security and deploymentReview hosting, access, AI processing and rollout responsibilities.Product

07Next step

Review your next spacecraft change in Arc.

See how mission requirements, subsystem decisions and verification evidence stay connected through review.

Book a demo