Skip to content

Evidence request lists

ECSS-E-ST-40C: Space Engineering - Software

Evidence request list. 10 controls, 10 carrying auditor artefact guidance. Generated from the compliance knowledge graph on 11 September 2026. Published by The Art of Service.

ECSS-E-ST-40C: Software Engineering Processes (Clause 5)

ECSS-40C-5.10
Software maintenance process

Maintain the software after delivery: problem and modification analysis, modification implementation, maintenance reviews, software migration and software retirement.

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.2
Software related system requirement process

Establish the software-related system requirements: analyse and specify the requirements allocated to software at system level, perform software-related system verification and integration, and hold the System Requirements Review (SRR).

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.3
Software management process

Manage the software project across its life cycle: software life-cycle management, joint and technical reviews, review phasing, interface management, and technical budget and margin management.

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.4
Software requirements and architecture engineering process

Establish and document the software requirements (Software Requirements Specification) and the software architectural design, and hold the Preliminary Design Review (PDR).

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.5
Software design and implementation engineering process

Produce the detailed design, code the software units, perform unit testing, integrate the software, and hold the Critical Design Review (CDR).

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.6
Software validation process

Plan and perform software validation against the technical specification and against the requirements baseline, demonstrating the software meets its intended use.

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.7
Software delivery and acceptance process

Deliver the software and conduct acceptance, including the Test Readiness Review (TRR) and the Acceptance Review (AR), against the agreed acceptance criteria.

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.8
Software verification process

Plan and perform software verification (reviews, analyses, inspections and testing, including integration testing) to confirm that each life-cycle output meets its specified requirements.

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing
ECSS-40C-5.9
Software operation process

Support operational use of the software, including operational testing and the support needed to operate the software in its target environment.

Artefacts an auditor will ask for
  • Process documentation and life-cycle deliverables (DRDs) for this process
  • Review records (SRR/PDR/CDR/QR/AR) evidencing the process outputs
Where this commonly fails
  • Process not defined or not applied in the software life cycle
  • Required reviews/deliverables missing

ECSS-E-ST-40C: Special Requirements (Clause 6)

ECSS-40C-6
Special requirements

Apply the special requirements that tailor the engineering processes by software criticality: software dependability and safety, the software criticality categories (A-D), software reuse justification, the use and qualification of tools and the software development environment, and the interface to software product assurance (ECSS-Q-ST-80C).

Artefacts an auditor will ask for
  • Software criticality classification (categories A-D) and the resulting tailoring
  • Dependability/safety analyses and tool-qualification records
  • Interface records with the software product assurance (Q-ST-80C) activities
Where this commonly fails
  • No software criticality classification
  • Special requirements not tailored to criticality
Assembled from the framework's own control set. Every line traces to a control in the graph, so this pack is regenerated rather than written, and stays current as the graph does.

Assembled from the framework’s own control set, so this list is regenerated rather than written and stays current as the graph does.