Skip to content
Arc
Menu

Software

Requirements management for software teams.

Connect software requirements, component interfaces and release evidence. Review the effect of code and contract changes against the intended behaviour.

Book a demo

02Engineering challenges

Make the release decision traceable.

Completed tickets and passing tests need a connection to the behaviour the release should deliver.

  1. Intent gets lost behind tickets

    Delivery items need to retain the source need, rationale and acceptance conditions behind the implementation.

  2. Contract changes reach other components

    A changed response can affect consumers in other repositories. Compatibility assumptions need an explicit review.

  3. Test status leaves coverage unclear

    A passing result needs requirement, revision and environment references to show which release behaviour it verifies.

03How Arc helps

Connect intended behaviour to the release decision.

Keep requirement intent, component assumptions and verification evidence together as the software changes.

Requirements and component context

Keep the reason for the work visible.

Connect requirements to their source needs, acceptance conditions and component interfaces. Retain the rationale and owner alongside delivery references.

Inspect the fictional software requirement

Illustrative engineering example: a fictional response-contract change connects interface, requirement, repository reference, integration test and pending release evidence.

The candidate repository revision is a teaching reference. No real commit, supplied connector, test execution, passing result or accepted release is invented.

Illustrative engineering example · Response-contract release review

Software requirement

REQ-SW-04

  • REQ-SW-04constrains

    Component interface

    IF-MSG-01

    Response-contract proposal

    Pending

  • REQ-SW-04implemented through reference

    Implementation reference

    Candidate repository revision (teaching reference)

    Pending

  • REQ-SW-04verified by

    Integration test

    TEST-INT-04

    Candidate result not supplied

    Pending

Awaiting engineer review

Requirement record
Software requirementREQ-SW-04
Interface
IF-MSG-01 response contract
Acceptance context
Producer and consumer compatibility to review
Implementation reference
Candidate repository revision, teaching reference
Integration test
TEST-INT-04
Release evidence
Pending
Owner
Software and release owners

Awaiting engineer review

Illustrative engineering example. Repository and test references are teaching records, not a real commit or executed test.
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.

Contract changes and agents

Trace the effect of a changed contract.

Follow a response or component-interface change into dependent requirements and integration tests. Review compatibility assumptions before accepting the candidate behaviour.

Inspect the fictional contract comparison
Illustrative engineering example · Response-contract release review

IF-MSG-01 response-contract candidate

Response contract

Current

Source definition · payload not supplied

Proposed

Candidate definition for review

Affected records

  • IF-MSG-01 response-contract candidate

    REQ-SW-04

    Behaviour, constraints and compatibility review

  • IF-MSG-01 response-contract candidate

    TEST-INT-04

    Integration evidence for the candidate release remains pending

  • No actual payload, repository SHA or test result is supplied.
  • Implementation references require an agreed custom workflow.

Awaiting engineer review

Full change comparison
IF-MSG-01 response-contract candidate
Record / valueCurrentProposed
Response contractSource definition · payload not suppliedCandidate definition for review
Requirement referenceUnchangedREQ-SW-04REQ-SW-04
Repository revisionSource reference not suppliedCandidate repository revision (teaching reference)
Integration test referenceUnchangedTEST-INT-04TEST-INT-04
Release evidencePrevious evidence not suppliedPending for the candidate configuration

Unchanged constraints

  • No actual payload, repository SHA or test result is supplied.
  • Implementation references require an agreed custom workflow.

Affected records

REQ-SW-04
Behaviour, constraints and compatibility review
TEST-INT-04
Integration evidence for the candidate release remains pending

Awaiting engineer review

Illustrative qualitative comparison. No real source revision, interface payload or test outcome is supplied.

Review an agent’s finding before changing the record.

Agents help check requirements, trace dependencies and flag evidence gaps. Engineers inspect the sources and decide which proposed updates to accept.

Inspect the fictional agent proposal
Illustrative engineering example · Response-contract release review

Sources

  • IF-MSG-01
  • REQ-SW-04
  • Candidate repository revision
  • TEST-INT-04

Finding

The linked integration test does not supply evidence for the candidate repository revision and release configuration.

Proposed action

Review producer and consumer compatibility, define the required checks, and record the candidate revision, settings and environment with their results before requesting release acceptance.

Engineer review

Awaiting engineer review

This is authored teaching content. It supplies no real code revision, CI execution, passing result or accepted release.

Source and proposal detail

Sources

  • IF-MSG-01

    Candidate component response-contract change.

  • REQ-SW-04

    Affected software behaviour and compatibility context.

  • Candidate repository revision

    Teaching reference, not a real commit.

  • TEST-INT-04

    Linked test. Evidence for the candidate release remains pending.

Finding

The linked integration test does not supply evidence for the candidate repository revision and release configuration.

Proposed action

Review producer and consumer compatibility, define the required checks, and record the candidate revision, settings and environment with their results before requesting release acceptance.

Awaiting engineer review

This is authored teaching content. It supplies no real code revision, CI execution, passing result or accepted release.

Illustrative sourced proposal. It is not an executed coding, CI or release-assurance result.
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.

Release evidence and review

Connect passing tests to intended behaviour.

Retain the requirement revision, repository reference and test environment with the result. Identify which release evidence is present and what remains pending.

Inspect the fictional release-evidence trail
Illustrative engineering example · Response-contract release review
  1. 01

    Component interface

    IF-MSG-01

    Candidate response-contract change

    Pending

    reviewed against
  2. 02

    Software requirement

    REQ-SW-04

    implemented through reference
  3. 03

    Implementation reference

    Candidate repository revision (teaching reference)

    Settings
    To identify
    Test environment
    To identify

    Pending

    verified by
  4. 04

    Integration test

    TEST-INT-04

    Pending

    needs scoped result
  5. 05

    Release evidence

    Pending release evidence

    Pending

    reviewed for acceptance
  6. 06

    Review decision

    Software and release owner review

    Pending

No test result, real repository SHA or accepted release is supplied. The configuration and evidence gaps remain open.

Illustrative release-evidence trail. No real commit, execution result or accepted release is supplied.

Review the release across components.

Bring component, integration and verification owners into the candidate branch. Keep the accepted baseline and pending release decisions identifiable.

Inspect the fictional release review
Illustrative engineering example · Response-contract release review
Main developmentProposed branch
  1. 01Review basis

    Source requirement and interface

    Main development
  2. 02Branch proposal

    IF-MSG-01 candidate

    Proposed branch
  3. 03Software review

    REQ-SW-04 compatibility

    Proposed branch
  4. 04Teaching reference

    Candidate repository revision

    Proposed branch
  5. 05Pending verification

    TEST-INT-04 / release evidence

    Proposed branch
  6. 06Awaiting engineer review

    Software and release owners

    Proposed branch
  7. 07Pending decision

    Merge only after acceptance

    Proposed branch

Responsible review

  • Software and release owners
Baseline and configuration detail
Main developmentProposed branch
  1. 01Review basis

    Source requirement and interface

  2. 02Branch proposal

    IF-MSG-01 candidate

  3. 03Software review

    REQ-SW-04 compatibility

  4. 04Teaching reference

    Candidate repository revision

  5. 05Pending verification

    TEST-INT-04 / release evidence

  6. 06Awaiting engineer review

    Software and release owners

  7. 07Pending decision

    Merge only after acceptance

Programme baseline
Meaning
The named software-programme requirements, interface revisions, review decisions and open issues. No new release baseline is accepted here.
Assessed configuration
Meaning
The repository revision, relevant settings and test environment represented by a result. The example supplies a candidate teaching reference with evidence pending.
Illustrative review path. It does not imply a supplied Git or CI connector, completed merge or accepted release.
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

Retain the requirements and assurance context for the release.

ISO/IEC/IEEE 29148 addresses requirements-engineering processes and information items across systems and software. Assurance obligations depend on the software’s intended use and invoked standards.

Connect source needs, requirements and acceptance conditions to verification evidence. Record the invoked assurance obligations, intended use and accountable review owners for the release baseline.

Traceability organises evidence. It does not establish compliance. A linked result needs assessment against the requirement revision and configuration it represents.

ISO/IEC/IEEE 29148
Requirements engineering processes and information items, including behaviour, constraints and acceptance context.
Programme assurance obligations
Activities, evidence and acceptance authorities determined by the software’s intended use and governing process.

Connect repository and release references through API and MCP.

Your repository continues to own source code. A custom integration can propose supported records and evidence references through agreed mappings, permissions and review. Permitted MCP tools provide context to a compatible assistant.

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 software requirements management?

Arc connects software requirements, source needs, component interfaces, proposed changes and release evidence. Repository and delivery references can retain their authoritative owners while the requirement and review context stays connected.

How can Arc support a response-contract change review?

Trace the proposed contract change through dependent component requirements, compatibility assumptions and integration tests. Review the candidate behaviour and pending evidence before accepting a release decision.

How can Arc help with ISO/IEC/IEEE 29148?

ISO/IEC/IEEE 29148 addresses requirements-engineering processes and information items across systems and software. Arc can connect behaviour, constraints, source needs and acceptance context to verification records. Additional assurance obligations depend on the intended use and invoked standards.

Does a passing CI test establish requirement coverage?

A passing result applies to the revision, configuration and environment assessed. Connect it to the requirement and acceptance conditions it addresses, then review missing coverage or applicability after a change.

Can software teams keep their repository and issue tracker?

Your repository continues to own source code and the issue tracker can remain the delivery record. Arc connects requirements, interfaces and review evidence through supported references with agreed mappings and ownership.

Can Arc’s agents approve a software release?

Engineers review the sources, finding and proposed action before accepting changes. Agents help inspect requirements and evidence gaps, while the release decision remains with the responsible owners.

How can API and MCP connect software delivery workflows?

A custom integration can propose supported records and evidence references through the API with agreed mappings, permissions and review. Permitted MCP tools expose supported context to a compatible assistant. Customer-owned AWS or Azure deployment and supported AI-provider keys are available under an agreed setup.

What can a software team review in an Arc demo?

A demo can follow a software requirement through a component-contract change, dependent tests and pending release evidence. Book a demo to discuss your requirement, integration and release-review workflow.

06Engineering resources

Engineering resources

Browse the blog
  1. API documentationRead the current contract for programme context and controlled changes.Product
  2. MCP documentationRead supported assistant context and controlled-change workflows.Product
  3. Requirements traceability guideFollow requirements from their sources to verification evidence.Guide

07Next step

Review your next software release in Arc.

See how intended behaviour, component changes and release evidence stay connected through review.

Book a demo