Space engineering

Verification

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-E-ST-10-02C Rev.1 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Division
    ESTEC, P.O. Box 299,
    2200 AG Noordwijk
    The Netherlands
Copyright:     2018 © by the European Space Agency for the members of ECSS

Change log

ECSS-E-10-02A	First issue
ECSS-E-ST-10-02B	Never issued
ECSS-E-ST-10-02C 6 March 2009	Second issue
ECSS-E-ST-10-02C Rev.1 1 February 2018	Second issue, Revision 1 Major changes of this version with regard to the previous version are: Implementation of Change Requests Addition of the Pre-tailoring matrix per space product types in clause 6 Clause 3 Terms, definitions and abbreviated terms updated. List of Abbreviated terms deleted as all are covered by ECSS-S-ST-00-01 Clause 3.4 Nomenclature added Figure 4-1 redrawn Deletion of inf. Annex G "Verification documents delivery per review" Added requirements 5.2.4.2d; 5.4.2f-g; C.2.1<2>b. Modified requirement 5.2.1a-c; 5.2.2.1e; 5.2.2.3c-d; 5.2.3a; 5.2.4.1a; 5.2.4.2a; 5.2.4.3.1a-b; 5.2.4.5a; 5.2.4.5d NOTE added; 5.2.4.6b; 5.2.6.1b; 5.2.6.2b; 5.2.7b; 5.2.7e NOTE added; 5.2.7.g; 5.2.8.1a NOTE ; 5.2.8.2a NOTE; 5.2.8.2b; 5.2.8.3a-b; 5.3.1a, d; 5.3.2.1a-d; 5.3.2.2a, c-d; 5.3.2.3a-d; 5.3.2.4a-d; 5.3.2.5a-d; 5.3.2.6e NOTE 2 added; 5.4.1b-d; 5.4.2a, c-d; 5.4.3a; 5.4.4.1b, d NOTE; B.2.1<6>a (two interleaved Notes moved to end of requirement); C.2.1<1>a; C.2.1<2>a; C.2.1<3>a; C.2.1<4>a-c; C.2.1<5>a; C.2.1<6>a; D.2.1<1>a; D.2.1<3>a; D.2.1<4>a; D.2.1<5>a; E.2.1<1>a; E.2.1<2>a; E.2.1<3>a; E.2.1<4>a; E.2.1<5>a; F.2.1<1>a; E.2.1<2>a; E.2.1<3>a; E.2.1<4>a-b; E.2.1<5>a-b. Deleted requirements 5.2.2.1b-c; 5.2.2.2b-g; 5.2.2.3b; 5.2.4.5e; 5.2.6.1c; 5.2.6.3a-b; 5.3.1b; 5.3.2.2b; 5.3.2.6a-d. Editorial modifications and corrections: Update of Scope; Punctuation in text of clause 2 corrected, Title of clause 3 corrected; ECSS reference number in clause 3.1 corrected to read ECSS-S-ST-00-01; List of Abbreviated terms in clause 4.3.1 deleted; Correction of typo in text of C.1.2; Replacement of abbreviated terms for "TSPE", "TPRO", "TRPT", "ARPT", "RRPT"; "IRPT" and "VRPT" by their full term.

Scope

This Standard establishes the requirements for the verification of a space system product.

It defines the fundamental concepts of the verification process, the criteria for defining the verification strategy and specifies the requirements for the implementation of the verification programme. It includes also the list of the expected documentation (i.e. Document requirements definitions, DRDs).

This Standard is intended to apply to different products at different levels from a single equipment to the overall system.

Discipline related verification aspects are complemented in Standards specific to those disciplines.

For verification process for SW the following standards are considered fully sufficient for development of these items:

ECSS-E-ST-40 Space engineering – Software

ECSS-Q-ST-80 Space product assurance - Software product assurance

Detailed requirements for Testing are covered in the ECSS E-ST-10-03.

This standard does not specifically address Validation of space products as a separate process, since product Verification is performed against requirements that also address the suitability of the product to fulfil the needs of its intended use. As such, Validation is achieved through the Verification process provided adequate requirements are placed on the product.

It is recognised that testing and analysis also occur during the product development process, but they are not addressed by this standard as they are not formal requirement verification activities in the sense of the customer-supplier relationship.

The guidelines on verification are provided in the associated handbook ECSS-E-HB-10-02A.

The requirements on the systems engineering process are gathered in ECSS-E-ST-10 “System Engineering”; specific aspects of the SE process are further elaborated in dedicated standards, in particular: ECSS-E-ST-10-06 “Technical Specification”, ECSS-E-ST-10-02 “Verification” (the present standard), and ECSS-E-ST-10-03 “Testing”. These standards are based on the same principles, process and documentation model.

The applicability of each these standards can therefore not be considered in isolation from the others

This standard may be tailored for the specific characteristic and constraints of a space project in conformance with ECSS-S-ST-00.

Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of any of these publications do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.

ECSS-S-ST-00-01	ECSS system — Glossary of terms.
ECSS-E-ST-10	Space engineering – System engineering general requirements
ECSS-E-ST-10-03	Space engineering — Testing
ECSS-M-ST-10	Space project management — Project planning and implementation
ECSS-Q-ST-10-09	Space product assurance — Nonconformance control system
ECSS-Q-ST-20	Space product assurance — Quality assurance.

Terms, definitions and abbreviated terms

Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply, in particular for the following terms:
acceptance
analysis
commissioning
inspection
qualification
test
validation
verification

Terms specific to the present standard

model philosophy
definition of the optimum number and the characteristics of physical, virtual, and hybrid models required to achieve confidence in the product verification with the shortest planning and a suitable weighting of costs and risks

review­of­design
verification method using approved records or evidence that unambiguously show that the requirement is met

design documents, design reports, technical descriptions, engineering drawings

Verification Control Board (VCB)
board composed of customer and supplier representatives that monitors the verification process and assesses the requirements verification close-out.

verification level
product architectural level at which the relevant verification is performed

Abbreviated terms

For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01 apply.

Nomenclature

The following nomenclature applies throughout this document:

The word “shall” is used in this Standard to express requirements. All the requirements are expressed with the word “shall”.
The word “should” is used in this Standard to express recommendations. All the recommendations are expressed with the word “should”.

It is expected that, during tailoring, recommendations in this document are either converted into requirements or tailored out.

The words “may” and “need not” are used in this Standard to express positive and negative permissions, respectively. All the positive permissions are expressed with the word “may”. All the negative permissions are expressed with the words “need not”.
The word “can” is used in this Standard to express capabilities or possibilities, and therefore, if not accompanied by one of the previous words, it implies descriptive text.

In ECSS “may” and “can” have completely different meanings: “may” is normative (permission), and “can” is descriptive.

The present and past tenses are used in this Standard to express statements of fact, and therefore they imply descriptive text.

Verification principles

Verification process

Verification objectives

The overall objective of verification is to demonstrate, through a dedicated process, that the deliverable product meets the specified requirements.

A satisfactory completion of the verification process is the basis for a contractual acceptance (as defined in ECSS-S-ST-00-01) of the product by the Customer.

The objectives of the Verification process are as follows:

to demonstrate the qualification of design and performance, as meeting the specified requirements at the specified levels;

to ensure that the product is in agreement with the qualified design, is free from workmanship defects and acceptable for use;

to confirm product integrity and performance at particular steps of the project life cycle (e.g. launch, commissioning, mission events and landing).

to confirm that the overall system (including tools, procedures and resources) is able to fulfil mission requirements;

Verification activities

The verification process activities consist of planning, execution, reporting, control and closeout as summarized in Figure 41.

Figure 41: Verification process and activities

Verification documentation

The verification process and its implementation activities are documented by means of a specific set of verification documents.

Verification plan (VP), see clause 5.2.8.1.

Assembly, integration and test (AIT) plan, see ECSS-E-ST-10-03.

The Verification Plan and the AIT Plan can be combined in one single AIV Plan (i.e. in this case VP and AIT plans do not exist anymore as single entities).

Verification control document (VCD), see clauses 5.2.8.2 and 5.4.4.1.

Test specification, see ECSS-E-ST-10-03.

Test procedure, see ECSS-E-ST-10-03.

Test report, see ECSS-E-ST-10-03, and clause 5.3.2.1 of the present standard.

Analysis report, see ECSS-E-ST-10, and clause 5.3.2.2 of the present standard.

Review of design report, see clause 5.3.2.3.

Inspection report, see clause 5.3.2.4.

Verification report, see clause 5.3.2.5.

Verification planning

Verification approach

To reach the verification objectives the verification approach is established in early phases of a project by analyzing the requirements to be verified, taking into account:

design peculiarities and constraints,

qualification status of candidate solutions (product category),

availability and maturity of verification tools,

verification (including test) methodologies,

ground segment and in orbit constraints for the in-orbit stage (including commissioning),

programmatic constraints, and

cost and schedule.

In generating the verification approach, the supplier conducts the following steps:

Identify “what” are the products and requirements subject of the verification process;

Identify “How” to verify them by considering the methods stated in the technical specification

Identify “When” to implement by applying the chosen verification strategy.

These steps are generally conducted in an iterative process based on technical, cost and schedule considerations, ensuring that the approach is agreed by both the supplier and the customer.

Verification methods

The verification is executed by one or more of the following verification methods: test, analysis, review of design and inspection. This list shows the order of precedence that, in general, provides more confidence in the results.

Verification levels

The verification is performed incrementally at different product decomposition levels. The number and type of verification levels depends upon the complexity of the project and on its characteristics.

The usual verification levels for a space product are equipment, subsystem, element, segment and overall system.

Verification stages

The verification process is implemented in subsequent verification stages along the project life cycle.

The stages depend upon project characteristics and identify a type of verification. The verification stages are qualification, acceptance, pre­launch, in­orbit (including commissioning) and post­landing.

Model philosophy

The verification by test is implemented on the selected models chosen for the project.

Model philosophy is defined by means of an iterative process which combines programmatic constraints, verification strategies and the integration and test programme, taking into account the development status of the candidate design solution.

Verification tools

The verification tools to be used to perform verification activities are identified and their procurement and utilisation planned. The extent to which the tools are themselves subjected to formal verification depends upon their role.

Verification execution and reporting

The verification process activities are incrementally performed at different product decomposition levels and in different stages, applying a coherent bottom-up strategy and utilizing a suitable combination of different verification methods.

In particular the verification by test is carried-out on different physical models in agreement with the selected model philosophy.

Verification control and closeout

The verification process is monitored in its execution by the Verification Control Board (see 5.4.2) and confirmed completed when, based on objective evidence, the VCD deems the product as verified against the identified requirements and the associated verification objectives. This has to be finally confirmed by the customer.

Verification requirements

Verification process

The verification process shall demonstrate that the deliverable product meets the specified customer requirements and is capable of sustaining its operational role through:

• Verification planning;
• Verification execution and reporting;
• Verification control and close-out.

Verification planning

Verification approach

The supplier shall identify any constraints on the verification process arising from both the verification objectives and the requirements defined by the customer as needing verification.

For example, ground segment characteristics, launch service, envisaged end to end tests involving several suppliers. The usual general objectives are listed in clause 4.1.1 “Verification objectives”.

The requirements specified in 5.2.1a shall always include those of the technical specification.
The supplier shall define the verification approach by conducting the following steps:

• Identify and agree with the customer the set of requirements to be subject of the verification process.
• Select the methods and the levels of verification, the associated model philosophy and the verification tools.
• Identify the stages and events in which the verification is implemented. The verification approach shall be defined by the supplier in the Verification Plan (VP) for approval by the customer prior to implementation.
  For each requirement to be verified, the verification strategy shall be defined in terms of the combination of the selected verification methods for the different verification levels at the applicable verification stages, in the initial issue of the Verification Control Document (VCD) also called verification matrix (see Annex B), for approval by the customer.

Verification methods

General

Verification shall be accomplished by one or more of the following verification methods:

• test (including demonstration);
• analysis (including similarity);
• review­of­design;
• inspection. <<deleted>>
  <<deleted>>
  For each requirement verified only by analysis or review-of-design, a risk assessment (part of the VP) shall be conducted to determine the level (major/minor) of the impact of this requirement on the mission.
  For each case where the risk assessment performed as a result of 5.2.2.1d identifies the impact of the requirement as being major, risk mitigation planning shall be defined and reported as part of the Verification Plan.

Test

Verification by test shall consist of measuring product performance and functions under representative simulated environments.
<<deleted>>
<<deleted>>
<<deleted>>
<<deleted>>
<<deleted>>
<<deleted>>

Analysis

Verification by analysis shall consist of performing theoretical or empirical evaluation using techniques agreed with the Customer.

Techniques comprise systematic, statistical and qualitative design analysis, modelling and computational simulation.

<<deleted>>
Analysis to demonstrate qualification of a product by similarity with an already qualified product shall fulfil the following criteria:

• The already qualified product was not qualified by similarity.
• The product to be verified belongs to category A or to category B (defined in Table 51) but no testing is required to achieve qualification.

Implicitly the product to be verified cannot belong to categories C and D equipment (defined in Table 51).

Similarity analysis shall define differences that can dictate additional verification activities.
An analysis programme shall be defined in the Verification Plan (VP).
An analysis programme shall be applicable to qualification and in-orbit stages only.

Review­of­design (ROD)

Verification by Review-of design (ROD) shall consist of using approved records or evidence that unambiguously show that the requirement is met.

Examples of such approved records are design documents and reports, technical descriptions, and engineering drawings.

A review-of-design programme shall be defined in the Verification Plan (VP).
A review-of-design programme shall only be applicable in the qualification stage or in the in-orbit stage.

Inspection

Verification by inspection shall consist of visual determination of physical characteristics.

Physical characteristics include constructional features, hardware conformance to document drawing or workmanship requirements, physical conditions, software source code conformance with coding standards.

An inspection programme shall be defined in the Verification Plan (VP).

Verification levels

Verification shall be accomplished through the verification levels in conformance with those defined with the Annex A Verification Plan DRD.

Usual levels are defined in 4.2.3.

When a requirement is fully verified at lower level, the traceability to lower level verification evidence shall be identified.
Formal close-out of qualification and acceptance at lower levels shall be performed prior to close-out at higher level.

Verification stages

General

The Verification Plan shall state which verification activities are to be accomplished in each of relevant verification stages.
Qualification, acceptance and pre-launch stages shall be completed before launch.
When the verification programme includes an in-orbit stage, the verification shall not rely only on in-orbit activities.
When the verification programme includes a post landing stage, the verification shall not rely only on in-orbit activities or post landing activities.

Qualification

In the qualification stage the supplier shall demonstrate that the design, including margins, meets the applicable requirements.
Qualification shall be carried-out on hardware and software which is representative of the end item configuration in terms of design, materials, tooling and methods.
The qualification programme shall be prepared considering the product category according to heritage as defined in Table 51.
For product categories A, B and C, the supplier shall state the qualification status at the EQSR (Equipment Qualification Status Review).
Table 51: Product categories according to heritage

Category	Description	Qualification programme
A	Off-the-shelf product without modifications and subjected to a qualification test programme at least as severe as that imposed by the actual project specifications including environment and produced by the same manufacturer or supplier and using the same tools and manufacturing processes and procedures	None
B	Off-the-shelf product without modifications. However: It has been subjected to a qualification test programme less severe or different to that imposed by the actual project specifications (including environment).	Delta qualification programme, decided on a case by case basis.
C	Off-the-shelf product with modifications. Modification includes changes to design, parts, materials, tools, processes, procedures, supplier, or manufacturer.	Delta or full qualification programme (including testing), decided on a case by case basis depending on the impact of the modification.
D	Newly designed and developed product.	Full qualification programme.

Acceptance

General

In the stage the verification shall demonstrate that the product meets specified margins with the agreed deviations and waivers, and it is free of defects when delivered by the supplier.
Acceptance shall be carried-out on the product which is declared as the acceptance article with a defined configuration of hardware and software.

Acceptance article

The acceptance article shall be manufactured in agreement with the qualified design.
The acceptance article shall perform as the qualified product.

Pre-launch

In the pre-launch stage the verification shall demonstrate that the product is properly configured for launch activities and early operations.
In the pre-launch stage the verification shall confirm that the product is capable of functioning as planned during launch and early operations.

In-orbit

In the in-orbit stage the verification shall address the minimum set of requirements that cannot be verified on ground.
In the in-orbit stage the verification shall supplement/confirm ground verification by providing operating conditions which cannot be fully or cost effectively duplicated or simulated on ground.
In the in-orbit stage the verification shall characterize the system under operational conditions especially for the aspects that cannot be determined before the launch.
In the in-orbit stage the verification shall confirm that the space and ground elements are compatible with each other.

The working arrangement between the elements suppliers (e.g. satellite, ground segment) and the final customer defines the share of responsibilities for preparing, conducting and reporting the in orbit - commissioning activities. The completion of this stage allows declaring readiness for routine operations (Phase E2-exploitation).

<<deleted>>

Post-landing

The verification in the post-landing stage shall address the product integrity and performance after the mission.
In case the product is intended to be re-launched the verification shall address:

• a health check, at periodical intervals agreed with the customer, during storage periods;
• the product performance after modification, repair or replacement;
• the readiness for reuse.

Models

The model philosophy shall be defined as part of the overall verification planning.

Verification tools

General

Tools to be used to support the implementation of the verification process shall be identified.
All verification tools shall be validated and maintained for their intended use.
<<deleted>>
Formal verification procedures shall be established and applied to tools which are specified as deliverable items.

Ground support equipment (GSE)

All ground support equipment (GSE) shall be verified under expected environmental conditions and operational constraints.
The compatibility of the interfaces of the ground support equipment (GSE) with flight products and facilities shall be verified.
The prevention of damage on the flight product due to ground support equipment (GSE) failure shall be verified.

For hazards to personnel, flight hardware, facilities and environments related to GSE, see ECSS-Q-ST-40.

Ground support equipment (GSE) that is modified or used in a new application shall be re-verified or re-validated.

<<deleted>>

<<deleted>>
<<deleted>>

Simulators

Simulators shall be verified to demonstrate that the simulator characteristics are representative of the simulated product to the extent required for the verification to be supported.

Software tools for verification by analysis

Suitability of previously validated analytical software tools shall be assessed for the intended application.
Non-validated analytical software tools shall be subjected to a validation process prior to their use.

Integration and test facilities and test tools

The capability of the integration and test facilities and test tools to perform their intended function in terms of performance and calibration shall be verified as part of the overall integration and test process.

See ECSS-Q-ST-20-07 for test facilities.

Verification process phasing

The verification process shall be phased with the project life cycle, in accordance with ECSS-M-ST-10.
Verification planning to assess feasibility and support development planning shall start during phase A.
The preliminary verification planning shall cover all products and requirements by the end of phase B.
Verification planning shall be completed by the end of Phase C.

Covering all verification stages e.g. pre-launch, in-orbit (including commissioning) and post landing.

Verification execution and reporting shall be incrementally carried out through the project life cycle starting from phase C.

The majority of verification execution is undertaken during phase D, however verification by analysis and review of design (and potentially for long lead items) starts in phase C.

Verification control shall start with the initial issue of the verification control document (VCD) during phase B.
The supplier shall provide the Verification close out status for each product at the end of each stage to the customer for approval.

E.g. qualification close out status at the end of the qualification stage during the Qualification Review (QR).

Verification planning documents

Verification plan (VP)

The supplier shall provide a Verification plan (VP) for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

The contents of the Verification plan (VP) shall be in conformance with the DRD in Annex A.

Verification Control Document (VCD)

The supplier shall provide a Verification Control Document (VCD) for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

The Verification Control Document (VCD) shall be in conformance with the DRD in Annex B.

Other verification planning Document

The supplier shall provide the AIT Plan for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

The AIT plan shall be in accordance with the DRD in ECSS-E-ST-10-03 Annex A.

Verification execution and reporting

General

The supplier shall identify those responsible for the implementation of the verification activities.
<<deleted>>
When nonconformity is detected during the verification process, a Nonconformance Report (NCR), in conformance with Annex A of ECSS-Q-ST-10-09, shall be raised and processed according to ECSS-Q-ST-20.
The verification results shall be recorded by the supplier in verification reports and provided to the Verification Control Board (VCB) for review.

Verification execution and reporting documentation

Test report

The test report for each test verification task as identified in the VP or AIT Plan shall be submitted to the Verification Control Board (VCB) after the test completion, within the time frame agreed with the customer.
The supplier shall provide Test reports for the reviews in conformance with the DRD in Annex C.
The supplier shall provide the Test reports for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

A Test report shall be provided for each Test verification task as identified in the VP or AIT Plan.

Analysis report

The Analysis report for each analysis verification task identified in the Verification Plan shall be submitted to the Verification Control Board (VCB) after analysis completion, within the time frame agreed with the customer.
<<deleted>>
The supplier shall provide an Analysis report for the reviews as agreed with the customer.

• 1    See ECSS-E-ST-10 Table A-1 for review deliverables.
• 2    For each discipline specific analysis reports is covered in the respective ECSS standard. A generic guideline for the content of an Analysis Report is given in Annex S of ECSS-E-ST-10.
  An Analysis report shall be provided for each Analysis verification task identified in the Verification Plan.

Review-of-design report

The Review-of-design report shall be submitted for each Review-of-design verification task identified in the Verification Plan to the Verification Control Board (VCB) after the Review-of-Design completion, within the time frame agreed with the customer.
The supplier shall provide the Review-of-design report in conformance with the DRD in Annex D.
The supplier shall provide a Review-of-design for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

A Review-of-design report shall be provided for each Review-of-design verification task identified in the Verification Plan.

Inspection report

The Inspection report shall be submitted for each Inspection verification task identified in the Verification Plan to the Verification Control Board (VCB) after the inspection completion, within the time frame agreed with the customer.
The supplier shall provide the Inspection report in conformance with the DRD in Annex E.
The supplier shall provide an Inspection report for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

An Inspection report shall be provided for each Inspection verification task identified in the Verification Plan.

Verification report

The supplier shall prepare a Verification report when more than one of the defined verification methods are utilized to verify a requirement or a specific set of requirements.
The supplier shall provide the Verification report in conformance with the DRD in Annex F.
The Verification report shall be submitted to the Verification Control Board (VCB) after the completion of the last contributing verification activities, within the time frame agreed with the customer.
The supplier shall provide a Verification report for the reviews as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

Other verification execution and reporting Document

<<deleted>>
<<deleted>>
<<deleted>>
<<deleted>>
The rules for the analysis, inspection and review of design shall be defined in writing before their execution.

• 1    For example, analysis, inspection or review of design procedures.
• 2    The rules for Test are as detailed in ECSS-E-ST-10-03.

Verification control and close-out

General

The implementation of the verification process shall be monitored by the Verification Control Board (VCB).
The supplier shall provide a computer based verification database to support the verification process control.
The supplier shall deliver the verification database to the customer in an electronic form to be agreed with the customer.
The supplier shall capture and provide verification close-out evidence in the verification database for those customers requirements agreed to be verified.

Verification control board (VCB)

A Verification Control Board (VCB) shall be established by the supplier and invite the participation of the customer, to assess the achievements and status of the verification process.

The VCB is set-up in relation to the complexity and the extents of the verification activities.

The verification process shall be considered completed when the Verification Control Board (VCB) confirms that:

• documented evidence is recorded in the VCD,
• identified requirements have been verified
• associated product verification objectives are reached The conclusions of the VCB shall be submitted for approval to the customer.
  The supplier’s Verification Control Board (VCB) representative shall support the VCB in the assessment of the verification status with a periodicity agreed with the customer.

The results of the VCB are at least presented on the occasions of project reviews as defined in ECSS-M-ST-10.

The supplier's VCB representative shall ensure the Verification Control Board (VCB) endorses the final issue of the Verification Control Document (VCD).
The supplier's VCB representative shall ensure the Verification Control Board (VCB) includes participation of Engineering and Quality Assurance representatives within its members.
The supplier's VCB representative shall ensure that for VCBs related to qualification the QA representative acts as the board chair.

Re-verification

The extent of the re-verification to be performed shall be determined by Supplier and agreed with the customer, in the following cases:

• failure and repair as decided by Nonconformance Review Board (NRB);
• unplanned disassembly or demating;
• refurbishment, maintenance or design changes;
• changes of requirements after initial verification;
• long duration storage in case of storage duration in excess to the qualified storage duration;
• flight use of qualification hardware. The Verification Control Document (VCD) shall be updated by the supplier to record as open, those requirements subject to re-verification until this is performed and closeout agreed by the customer.

Verification control and close-out documentation

Verification Control Document (VCD)

The content of the completed Verification Control Document (VCD) shall be in conformance with the DRD in Annex B.
The supplier shall update the Verification database after approval of a report in line with the timescale agreed with the customer and stated in the Verification Plan.
The intermediate issues of the Verification Control Document (VCD), reflecting the current status of the verification database, shall be made available to the Verification Control Board (VCB) upon request.
The intermediate issues of the Verification Control Document (VCD), reflecting the current verification and compliance status, shall be delivered at each formal review as agreed with the customer

See ECSS-E-ST-10 Table A-1 for review deliverables.

The final issue of the Verification Control Document (VCD) shall be submitted to the Verification Control Board (VCB) after the approval of the last report, within the time frame agreed with the customer.

Other close-out documents

The supplier shall make available to the customer for consultation the evidences mentioned in the VCD in addition to the deliverable reports.

Pre-tailoring matrix per space product types

The Matrix of Table 61 presents the pre-tailoring of this ECSS Standard per space product type.

For the terminology and definitions of the space product types see ECSS-S-ST-00-01.

• 1    “Ground segment equipment” is not to be confused with “Ground support equipment”.
• 2    Clauses are proposed as applicable to a given decomposition level but not to the level below when they address an element and its constituents at that level, but not what is inside the constituents (at the level below). In particular, no clause is proposed in the pre-tailoring as applicable to the product type “software” understood here as the applicability to the development of software when not installed in hardware.
• 3    Clauses applicability to the product type “launch segment element and sub-system” is proposed in the pre-tailoring on the basis of “launcher” and “launcher element”, covered by this product type, and not of the other elements and sub-systems that this product type also covers.
• 4    Some clauses use the word “system” with a more general meaning than the terminology used for the product types. Therefore some of these clauses could be proposed as applicable to other product types, than “space system” in the pre-tailoring.
  Table 61: Definitions of the columns of Table 62

Column title	Description
Applicability status	There are nine product types, one per column. For each product type the possible values for each requirement are: X    when applicable -    when not applicable //    when pre-tailoring applicability not definable - to be determined during tailoring >>    the requirement is applicable to a lower product type. Responsibility of tailoring (if needed) resides with the customer of this lower product type X#    when requirement is applicable except in a specific case - the criteria for being “not applicable” are defined in the Comments column //#    when pre-tailoring applicability not definable - however supplementary indications regarding applicability in the tailoring are given in the Comments column "#” is a number to uniquely identify every comment in the same row. A requirement is considered applicable for a product type if it is verified on this product type.
Comments	The column “Comments” provides information on the limitation of applicability – it provides clarification on the limited and specific conditions for the applicability of the requirement. is not used to modify a requirement.

Table 62: Pre-tailoring matrix per “Space product types”

ECSS req. #	Space system	Space segment element and sub-system	Space segment equipment	Launch segment element and sub-system	Launch segment equipment	Ground segment element and sub-system	Ground segment equipment	Ground support equipment	Software	Comments
5.1a	X	X	X	X	X	X	X	X
5.2.1a	X	X	X	X	X	X	X	X
5.2.1b	X	X	X	X	X	X	X	X
5.2.1c	X	X	X	X	X	X	X	X
5.2.1d	X	X	X	X	X	X	X	X
5.2.1e	X	X	X	X	X	X	X	X
5.2.2.1a	X	X	X	X	X	X	X	X
5.2.2.1d	X	X	X	X	X	X	X	X
5.2.2.1e	X	X	X	X	X	X	X	X
5.2.2.2a	X	X	X	X	X	X	X	X
5.2.2.3a	X	X	X	X	X	X	X	X
5.2.2.3c	X	X	X	X	X	X	X	X
5.2.2.3d	X	X	X	X	X	X	X	X
5.2.2.3e	X	X	X	X	X	X	X	X
5.2.2.3f	X	X	X	X	X	X	X	X
5.2.2.4a	X	X	X	X	X	X	X	X
5.2.2.4b	X	X	X	X	X	X	X	X
5.2.2.4c	X	X	X	X	X	X	X	X
5.2.2.5a	X	X	X	X	X	X	X	X
5.2.2.5b	X	X	X	X	X	X	X	X
5.2.3a	X	X	X	X	X	X	X	X
5.2.3b	X	X	X	X	X	X	X	X
5.2.3c	X	X	X	X	X	X	X	X
5.2.4.1a	X	X	X	X	X	X	X	X
5.2.4.1b	X	X	X	X	X	X	X	X
5.2.4.1c	X	X	X	X	X	-	-	-
5.2.4.1d	X	X	X	X	X	-	-	-
5.2.4.2a	X	X	X	X	X	X	X	X
5.2.4.2b	X	X	X	X	X	X	X	X
5.2.4.2c	X	X	X	X	X	X	X	X
5.2.4.2d	X	X	X	X	X	X	X	X
5.2.4.3.1a	X	X	X	X	X	X	X	X
5.2.4.3.1b	X	X	X	X	X	X	X	X
5.2.4.3.2a	X	X	X	X	X	X	X	X
5.2.4.3.2b	X	X	X	X	X	X	X	X
5.2.4.4a	X	X	X	X	X	X	X	X
5.2.4.4b	X	X	X	X	X	X	X	X
5.2.4.5a	X	X	X	-	-	X	X	-
5.2.4.5b	X	X	X	-	-	X	X	-
5.2.4.5c	X	X	X	-	-	X	X	-
5.2.4.5d	X	X	X	-	-	X	X	-
5.2.4.6a	X	X	X	-	-	-	-	-
5.2.4.6b	X	X	X	X	X	-	-	-
5.2.5a	X	X	X	X	X	X	X	X
5.2.6.1a	X	X	X	X	X	X	X	X
5.2.6.1b	X	X	X	X	X	X	X	X
5.2.6.1d	X	X	X	X	X	X	X	X
5.2.6.2a	-	-	-	-	-	-	-	X
5.2.6.2b	-	-	-	-	-	-	-	X
5.2.6.2c	-	-	-	-	-	-	-	X
5.2.6.2d	-	-	-	-	-	-	-	X
5.2.6.4a	X	X	X	X	X	X	X	X
5.2.6.5a	X	X	X	X	X	X	X	X
5.2.6.5b	X	X	X	X	X	X	X	X
5.2.6.6a	X	X	X	X	X	X	X	X
5.2.7a	X	X	X	X	X	X	X	X
5.2.7b	X	X	X	X	X	X	X	X
5.2.7c	X	X	X	X	X	X	X	X
5.2.7d	X	X	X	X	X	X	X	X
5.2.7e	X	X	X	X	X	X	X	X
5.2.7f	X	X	X	X	X	X	X	X
5.2.7g	X	X	X	X	X	X	X	X
5.2.8.1a	X	X	X	X	X	X	X	X
5.2.8.1b	X	X	X	X	X	X	X	X
5.2.8.2a	X	X	X	X	X	X	X	X
5.2.8.2b	X	X	X	X	X	X	X	X
5.2.8.3a	>>	X	X	X	X	X	X	X
5.2.8.3b	>>	X	X	X	X	X	X	X
5.3.1a	X	X	X	X	X	X	X	X
5.3.1c	X	X	X	X	X	X	X	X
5.3.1d	X	X	X	X	X	X	X	X
5.3.2.1a	X	X	X	X	X	X	X	X
5.3.2.1b	X	X	X	X	X	X	X	X
5.3.2.1c	X	X	X	X	X	X	X	X
5.3.2.1d	X	X	X	X	X	X	X	X
5.3.2.2a	X	X	X	X	X	X	X	X
5.3.2.2b	X	X	X	X	X	X	X	X
5.3.2.2c	X	X	X	X	X	X	X	X
5.3.2.2d	X	X	X	X	X	X	X	X
5.3.2.3a	X	X	X	X	X	X	X	X
5.3.2.3b	X	X	X	X	X	X	X	X
5.3.2.3c	X	X	X	X	X	X	X	X
5.3.2.3d	X	X	X	X	X	X	X	X
5.3.2.4a	X	X	X	X	X	X	X	X
5.3.2.4b	X	X	X	X	X	X	X	X
5.3.2.4c	X	X	X	X	X	X	X	X
5.3.2.4d	X	X	X	X	X	X	X	X
5.3.2.5a	X	X	X	X	X	X	X	X
5.3.2.5b	X	X	X	X	X	X	X	X
5.3.2.5c	X	X	X	X	X	X	X	X
5.3.2.5d	X	X	X	X	X	X	X	X
5.3.2.6e	X	X	X	X	X	X	X	X
5.4.1a	X	X	X	X	X	X	X	X
5.4.1b	X	X	X	X	X	X	X	X
5.4.1c	X	X	X	X	X	X	X	X
5.4.1d	X	X	X	X	X	X	X	X
5.4.2a	X	X	X	X	X	X	X	X
5.4.2b	X	X	X	X	X	X	X	X
5.4.2c	X	X	X	X	X	X	X	X
5.4.2d	X	X	X	X	X	X	X	X
5.4.2e	X	X	X	X	X	X	X	X
5.4.2f	X	X	X	X	X	X	X	X
5.4.2g	X	X	X	X	X	X	X	X
5.4.3a	X	X	X	X	X	X	X	X
5.4.3b	X	X	X	X	X	X	X	X
5.4.4.1a	X	X	X	X	X	X	X	X
5.4.4.1b	X	X	X	X	X	X	X	X
5.4.4.1c	X	X	X	X	X	X	X	X
5.4.4.1d	X	X	X	X	X	X	X	X
5.4.4.1e	X	X	X	X	X	X	X	X
5.4.4.2a	X	X	X	X	X	X	X	X
A.2.1<1>a	X	X	X	X	X	X	X	X
A.2.1<1>b	X	X	X	X	X	X	X	X
A.2.1<2>a	X	X	X	X	X	X	X	X
A.2.1<3>a	X	X	X	X	X	X	X	X
A.2.1<4>a	X	X	X	X	X	X	X	X
A.2.1<5>a	X	X	X	X	X	X	X	X
A.2.1<6>a	X	X	X	X	X	X	X	X
A.2.1<7>a	X	X	X	X	X	X	X	X
A.2.1<7>b	X	X	X	X	X	X	X	X
A.2.1<8>a	X	X	X	X	X	X	X	X
A.2.1<8>b	X	X	X	X	X	X	X	X
A.2.1<9>a	X	X	X	X	X	X	X	X
A.2.1<10>a	X	X	X	X	X	X	X	X
A.2.1<11>a	X	X	X	X	X	X	X	X
A.2.1<12>a	X	X	X	X	X	X	X	X
A.2.1<12>b	X	X	X	X	X	X	X	X
A.2.1<12>c	X	X	X	X	X	X	X	X
A.2.2a	X	X	X	X	X	X	X	X
B.2.1<1>a	X	X	X	X	X	X	X	X
B.2.1<1>b	X	X	X	X	X	X	X	X
B.2.1<1>c	X	X	X	X	X	X	X	X
B.2.1<2>a	X	X	X	X	X	X	X	X
B.2.1<3>a	X	X	X	X	X	X	X	X
B.2.1<4>a	X	X	X	X	X	X	X	X
B.2.1<4>b	X	X	X	X	X	X	X	X
B.2.1<5>a	X	X	X	X	X	X	X	X
B.2.1<6>a	X	X	X	X	X	X	X	X
B.2.1<6>b	X	X	X	X	X	X	X	X
C.2.1<1>a	X	X	X	X	X	X	X	X
C.2.1<1>b	X	X	X	X	X	X	X	X
C.2.1<2>a	X	X	X	X	X	X	X	X
C.2.1<2>b	X	X	X	X	X	X	X	X
C.2.1<3>a	X	X	X	X	X	X	X	X
C.2.1<4>a	X	X	X	X	X	X	X	X
C.2.1<4>b	X	X	X	X	X	X	X	X
C.2.1<4>c	X	X	X	X	X	X	X	X
C.2.1<5>a	X	X	X	X	X	X	X	X
C.2.1<6>a	X	X	X	X	X	X	X	X
C.2.1<6>b	X	X	X	X	X	X	X	X
C.2.1<6>c	X	X	X	X	X	X	X	X
D.2.1<1>a	X	X	X	X	X	X	X	X
D.2.1<1>b	X	X	X	X	X	X	X	X
D.2.1<2>a	X	X	X	X	X	X	X	X
D.2.1<3>a	X	X	X	X	X	X	X	X
D.2.1<4>a	X	X	X	X	X	X	X	X
D.2.1<5>a	X	X	X	X	X	X	X	X
D.2.1<5>b	X	X	X	X	X	X	X	X
E.2.1<1>a	X	X	X	X	X	X	X	X
E.2.1<1>b	X	X	X	X	X	X	X	X
E.2.1<2>a	X	X	X	X	X	X	X	X
E.2.1<3>a	X	X	X	X	X	X	X	X
E.2.1<4>a	X	X	X	X	X	X	X	X
E.2.1<5>a	X	X	X	X	X	X	X	X
E.2.1<5>b	X	X	X	X	X	X	X	X
F.2.1<1>a	X	X	X	X	X	X	X	X
F.2.1<1>b	X	X	X	X	X	X	X	X
F.2.1<2>a	X	X	X	X	X	X	X	X
F.2.1<3>a	X	X	X	X	X	X	X	X
F.2.1<4>a	X	X	X	X	X	X	X	X
F.2.1<4>b	X	X	X	X	X	X	X	X
F.2.1<5>a	X	X	X	X	X	X	X	X
F.2.1<5>b	X	X	X	X	X	X	X	X
F.2.1<5>c	X	X	X	X	X	X	X	X

ANNEX (normative)Verification plan (VP) - DRD

DRD identification

Requirement identification and source document

This DRD is called up from ECSS-E-ST-10-02, requirement 5.2.8.1b.

Purpose and objective

The Verification Plan contains the overall verification approach, the model philosophy, the product matrix, the verification strategies for the requirements (the interrelation between different methods/levels/stages of verification to be used to demonstrate status of compliance to requirements), the test, inspection, analysis and review-of-design programme with the relevant activity sheets and planning, the verification tools, the verification control methodology, the involved documentation, the verification management and organization.

Expected response

Scope and content

Introduction

The VP shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Open issues, assumptions and constraints relevant to this document shall be stated and described.
Applicable and reference documents

The VP shall list the applicable and reference documents in support to the generation of the document.
Definitions and abbreviations

The VP shall list the applicable dictionary or glossary and the meaning of specific terms or abbreviations utilized in the document.
Verification subject

The VP shall briefly describe the subject of the verification process.
Verification approach

The VP shall describe the basic verification concepts and definitions (methods, levels and stages).
Model philosophy

The VP shall describe the selected models and the associated model philosophy, product matrix.
Verification Strategy

The VP shall describe the selected combination of the different verification methods at the applicable verification levels and stages, in general and for each requirement type/group (including software).
The allocation of the requirements to the specific verification tasks shall be given.
Verification programme

The VP shall document the verification activities and associated planning in the applicable verification stages.
Analysis, review­of­design, inspection and test programmes should be detailed through dedicated activity sheets, or through reference to the AIT Plan.
Verification tools

The VP shall describe high level definitions of the verification tools to be used, such as S/W facilities, special tools, simulators, analytical tools.
Verification control methodology

The VP shall describe the proposed methodology to be utilized for verification monitoring and control including the use of a verification data base.
Documentation

The VP shall list the involved verification documents and describe their content.
Organization and management

The VP shall describe the responsibility and management tools applicable to the described verification process.
It shall describe the responsibilities within the project team, the relation to product assurance, quality control and configuration control (including anomaly handling and change control) as well as the responsibility sharing with external partners.
The relevant reviews shall be planned and responsibilities described.

Special remarks

The Verification Plan may be combined with the AIT Plan in one single AIV Plan.

In this case VP and AIT plans do not exist anymore as single entities.

ANNEX(normative)Verification control document (VCD) - DRD

DRD identification

Requirement identification and source document

This DRD is called up from ECSS-ST-E-10-02, requirement 5.2.8.2b and 5.4.4.1b.

Purpose and objective

The Verification Control Document lists the requirements to be verified with the selected methods in the applicable stages at the defined levels.

It includes the Verification Matrix. The VCD is a living document and provides traceability during the phase C, D and E, how and when each requirement is planned to be verified and is actually verified.

The VCD becomes part of the EIDP, as detailed in ECSS-Q-ST-20.

Expected response

Scope and content

Introduction

The VCD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Open issues, assumptions and constraints relevant to this document shall be stated and described.
The VCD content shall be phased with the product life-cycle such that the initial issue contains the verification matrix, intermediate issues cover the planned on-ground verifications and their executions evidence (in particular for qualification and acceptance completion), the in-orbit and post landing activities; final issue provides evidence of the close-out of the overall verification process.
Applicable and reference documents

The VCD shall list the applicable and reference documents in support to the generation of the document.
Definitions and abbreviations

The VCD shall list the applicable dictionary or glossary and the meaning of specific terms or abbreviations utilized in the document.
Verification subject

The VCD shall describe the verification control approach applied to the product, the involved documentation and the computerized tool used to support the process.
The VCD shall include the requirements to be verified (with reference to the specifications involved), call up the verification methods, levels and stages definitions and explain the verification close­out criteria..
Verification summary status

Each issue of the VCD shall summarize the current Verification Close-out status.
Verification control data

The VCD shall collect in the form of a matrix, for each requirement, the following verification information:

• Requirement identifier,
• Requirement text
• traceability between requirement,
• Levels and stages of verification,
• methods,
• link to the relevant section of the verification plan and any planning document,
• References to any documentation that demonstrates compliance to the requirements,
• Status of Compliance (yes, no, partial),
• Close-out status (open / closed),
• Reasons of the close-out status,
• 1    to item 6: For example, test specification.
• 2    to item 7: For example, report, analysis, waivers, RFD, NCR, NRB, customer closeout records.
  The initial issue of the VCD shall contain a verification matrix limited to:
• Requirement identifier,
• Requirement text,
• traceability between requirement,
• Levels and stages of verification,
• methods,
• link to the relevant section of the verification plan.

Special remarks

None.

ANNEX(normative)Test report - DRD

DRD identification

Requirement identification and source document

This DRD is called up from ECSS-E-ST-10-02, requirement 5.3.2.1b.

Purpose and objective

The test report describes test execution, test and engineering assessment of results and conclusions in the light of the test requirements (including pass-fail criteria).

The test report contains the scope of the test, the test description, the test article and set-up configuration, and the test results including the as­run test procedures, the considerations and conclusions with particular emphasis on the close­out of the relevant verification requirements including deviations.

Expected response

Scope and content

Introduction

The Test Report shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Open issues, assumptions and constraints relevant to this document shall be stated and described.
Applicable and reference documents

The Test Report shall list the applicable and reference documents in support to the generation of the document.
The Test Report shall include as applicable reference documents the corresponding test procedure and test specification as specified in the DRDs in ECSS-E-ST-10-03.
Definitions and abbreviations

The Test Report shall list the applicable dictionary or glossary and the meaning of specific terms or abbreviations utilized in the document
Test results

The Test Report shall contain the test results with supporting data (including the test execution dates, the as run procedure, and the test facility results).
The Test Report shall contain the analysis of test data and the relevant assessment.
The Test Report shall provide a synthesis of the test results.
Anomalies

The Test Report shall include the list of deviations to the test procedure, the nonconformance including failures and the problems.
Conclusions

The Test Report shall summarize:

• the test results, including:
  • the list of the requirements to be verified (in correlation with the VCD),
  • traceability to used documentation,
  • conformance or deviation including references and signature and date),
• the comparison with the requirements and
• the verification close-out judgment. Open issues shall be clearly stated and described.
  Separate test analyses shall be cross-referenced.

Special remarks

None.

ANNEX(normative)Review-of-design report - DRD

DRD identification

Requirement identification and source document

This DRD is called up from ECSS-E-ST-10-02, requirement 5.3.2.3b.

Purpose and objective

The review­of­design report describes each verification activity performed for reviewing documentation.

The review­of­design report contains proper evidence that the relevant requirements are verified and the indication of deviations.

Expected response

Scope and content

Introduction

The Review-of-Design Report shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Open issues, assumptions and constraints relevant to this document shall be stated and described.
Applicable and reference documents

The Review-of-Design Report shall list the applicable and reference documents in support to the generation of the document.
Definitions and abbreviations

The Review-of-Design Report shall list the applicable dictionary or glossary and the meaning of specific terms or abbreviations utilized in the document with the relevant meaning.
Review-of-design summary

The Review-of-Design Report shall describe the review-of-design activity in terms of method and procedures used.
Conclusions

The Review-of-Design Report shall summarize

• the review-of-design results, including
  • the list of the requirements to be verified (in correlation with the VCD),
  • traceability to used documentation,
  • conformance or deviation including references and signature and date,
• the comparison with the requirements and
• the verification close-out judgment. Open issues shall be clearly stated and described.

Special remarks

None.

ANNEX(normative)Inspection report - DRD

DRD identification

Requirement identification and source document

This DRD is called up from ECSS-E-ST-10-02, requirement 5.3.2.4b.

Purpose and objective

The inspection report describes each verification activity performed for inspecting hardware or software.

The inspection report contains proper evidence that the relevant requirements are verified and the indication of deviations.

The inspection report may be embedded in the Test Report if the verification by Inspection is carried-out in combination with Testing.

Expected response

Scope and content

Introduction

The Inspection Report shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Open issues, assumptions and constraints relevant to this document shall be stated and described.
Applicable and reference documents

The Inspection Report shall list the applicable and reference documents in support to the generation of the document.
Definitions and abbreviations

The Inspection Report shall list the applicable dictionary or glossary and the meaning of specific terms or abbreviations utilized in the document with the relevant meaning.
Inspection summary

The Inspection Report shall describe the product configuration data of the inspected item.
Conclusions

The Inspection Report shall summarize the:

• inspection results, including:
  • the list of the requirements to be verified (in correlation with the VCD),
  • traceability to used documentation,
  • inspection event location and date,
  • expected finding,
  • conformance or deviation including proper references and signature and date,
• comparison with the requirements, and
• verification close-out judgement. Open issues shall be clearly stated and described.

Special remarks

None.

ANNEX(normative)Verification report - DRD

DRD identification

Requirement identification and source document

This DRD is called up from ECSS-E-ST-10-02, requirement 5.3.2.5b.

Purpose and objective

The Verification Report is prepared when more than one of the defined verification methods are utilized to verify a requirement or a specific set of requirements.

It reports the approach followed and how the verification methods were combined to achieve the verification objectives.

The positive achievement constitutes the completion of verification for the particular requirement.

Expected response

Scope and content

Introduction

The Verification Report shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Open issues, assumptions and constraints relevant to this document shall be stated and described.
Applicable and reference documents

The Verification Report shall list the applicable and reference documents in support to the generation of the document.
Definitions and Abbreviations

The Verification Report shall list the applicable dictionary or glossary and the meaning of specific terms or abbreviations utilized in the document with the relevant meaning Verification subject.
Verification results

The Verification Report shall describe the verification approach, the associated problems and results with reference to the relevant test, analysis, review­of­design and inspection reports.
The Verification Report shall identify the deviations from the verification plan.
Conclusions

The Verification Report shall list the requirements to be verified (in correlation with the VCD).
The Verification Report shall summarize verification results, the comparison with the requirements and the verification close­out judgement.
Open issues shall be clearly stated and described.

Special remarks

None.

ANNEX<<deleted>>

Bibliography

ECSS-S-ST-00	ECSS system — Description, implementation and general requirements
ECSS-E-ST-10-06	Space engineering — Technical specification
ECSS-Q-ST-20-07	Space product assurance – Quality assurance for test centres
ECSS-Q-ST-40	Space product assurance – Safety
ECSS-E-HB-10-02	Space engineering — Verification guidelines