SIST EN 16603-10-02:2019

SLOVENSKI STANDARD
01-februar-2019
1DGRPHãþD
SIST EN 14725:2004
Vesoljska tehnika - Preverjanje
Space engineering - Verification
Raumfahrttechnik - Verifikation
Ingénierie spatiale - Vérification
Ta slovenski standard je istoveten z: EN 16603-10-02:2018
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 16603-10-02
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2018
ICS 49.140
Supersedes EN 14725:2003
English version
Space engineering - Verification
Ingénierie spatiale - Vérification Raumfahrttechnik - Verifikation
This European Standard was approved by CEN on 28 September 2018.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2018 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16603-10-02:2018 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 4
1 Scope . 6
2 Normative references . 7
3 Terms, definitions and abbreviated terms . 8
3.1 Terms from other standards . 8
3.2 Terms specific to the present standard . 8
3.3 Abbreviated terms. 9
3.4 Nomenclature . 9
4 Verification principles . 10
4.1 Verification process . 10
4.1.1 Verification objectives . 10
4.1.2 Verification activities . 10
4.1.3 Verification documentation . 11
4.2 Verification planning . 12
4.2.1 Verification approach . 12
4.2.2 Verification methods . 12
4.2.3 Verification levels . 12
4.2.4 Verification stages . 13
4.2.5 Model philosophy . 13
4.2.6 Verification tools . 13
4.3 Verification execution and reporting . 13
4.4 Verification control and closeout . 13
5 Verification requirements . 14
5.1 Verification process . 14
5.2 Verification planning . 14
5.2.1 Verification approach . 14
5.2.2 Verification methods . 15
5.2.3 Verification levels . 17
5.2.4 Verification stages . 17
5.2.5 Models . 19
5.2.6 Verification tools . 19
5.2.7 Verification process phasing . 20
5.2.8 Verification planning documents. 21
5.3 Verification execution and reporting . 22
5.3.1 General . 22
5.3.2 Verification execution and reporting documentation . 22
5.4 Verification control and close-out . 24
5.4.1 General . 24
5.4.2 Verification control board (VCB) . 24
5.4.3 Re-verification . 25
5.4.4 Verification control and close-out documentation . 26
6 Pre-tailoring matrix per space product types . 27
Annex A (normative) Verification plan (VP) - DRD . 36
Annex B (normative) Verification control document (VCD) - DRD . 39
Annex C (normative) Test report - DRD . 42
Annex D (normative) Review-of-design report - DRD . 44
Annex E (normative) Inspection report - DRD . 46
Annex F (normative) Verification report - DRD . 48
Bibliography . 50

Figures
Figure 4-1: Verification process and activities . 11

Tables
Table 5-1: Product categories according to heritage . 18
Table 6-1: Definitions of the columns of Table 6-2 . 28
Table 6-2: Pre-tailoring matrix per “Space product types” . 29

European Foreword
This document (EN 16603-10-02:2018) has been prepared by Technical Committee CEN/CLC/TC 5
“Space”, the secretariat of which is held by DIN (Germany).
This document (EN 16603-10-02:2018) originates from ECSS-E-ST-10-02C Rev.1.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by May 2019, and conflicting national standards shall be
withdrawn at the latest by May 2019.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such
patent rights.
This document supersedes EN 14725:2003.
The main differences between EN 14725:2003 (that was based on ECSS-E-10-02A) and this standard
are:
• Restructuring of the document following, in particular: moving of the guidelines in the
associated Handbook, inclusion of an introductive clause on the Verification principles,
structuring of the requirement clauses in line with the verification process flow as
summarized in the principles.
• Clarification on standard applicability to different types of products (e.g. launcher,
transportation system, ground segment, GSE).
• Clarification of the verification vs. validation coverage.
• Moving of detailed test requirements to EN 16603-1003 (based on ECSS-E-ST-10-03C)
“Testing” including AIT Plan, Test Specification and Test Procedure DRDs.
• Introduction of risk assessment and mitigation plan concerning those requirements not
verified by test.
• Clarification on the applicability of verification by similarity as analysis method in
relationship to different types of products (requirement 5.2.2.3c)
• Clarification on product categories vs. heritage and relevant qualification requirements (clause
5.2.4.2)
• Clarification on in-orbit stage verification activities, in particular the relationship with the
commissioning (clause 5.2.4.5)
• Inclusion of a requirement concerning the verification database delivery in electronic form
(requirement 5.4.1c)
• Introduction of “status of compliance” in the VCD data (VCD DRD)
• Simplification of DRD’s number and content
This document has been prepared under a standardization request given to CEN by the European
Commission and the European Free Trade Association.
This document has been developed to cover specifically space systems and has therefore precedence
over any EN covering the same scope but with a wider domain of applicability (e.g. : aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of
Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia,
Spain, Sweden, Switzerland, Turkey and the United Kingdom.
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.

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

Terms, definitions and abbreviated terms
3.1 Terms from other standards
a. For the purpose of this Standard, the terms and definitions from ECSS-S-
ST-00-01 apply, in particular for the following terms:
1. acceptance
2. analysis
3. commissioning
4. inspection
5. qualification
6. test
7. validation
8. verification
3.2 Terms specific to the present standard
3.2.1 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
3.2.2 review-of-design
verification method using approved records or evidence that unambiguously
show that the requirement is met
NOTE design documents, design reports, technical
descriptions, engineering drawings
3.2.3 Verification Control Board (VCB)
board composed of customer and supplier representatives that monitors the
verification process and assesses the requirements verification close-out.
3.2.4 verification level
product architectural level at which the relevant verification is performed
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
apply.
3.4 Nomenclature
The following nomenclature applies throughout this document:
a. The word “shall” is used in this Standard to express requirements. All
the requirements are expressed with the word “shall”.
b. The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring,
recommendations in this document are either
converted into requirements or tailored out.
c. 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”.
d. 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.
NOTE In ECSS “may” and “can” have completely
different meanings: “may” is normative
(permission), and “can” is descriptive.
e. The present and past tenses are used in this Standard to express
statements of fact, and therefore they imply descriptive text.
Verification principles
4.1 Verification process
4.1.1 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;
4.1.2 Verification activities
The verification process activities consist of planning, execution, reporting,
control and closeout as summarized in Figure 4-1.
Initial Verification
Product Control Document
requirements Verification Verification
planningplanning
Verification
Plan
Supplier Customer
Verification
Execution &
Additional technical
reporting
documentation to support
Verification
Final Verification
Supplier
Verification
Control Document
Control &
Closeout
Verification
Control Board
Figure 4-1: Verification process and activities
4.1.3 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.
NOTE 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.
4.2 Verification planning
4.2.1 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.
4.2.2 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.
4.2.3 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.
4.2.4 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.
4.2.5 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.
4.2.6 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.
4.3 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.
4.4 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
5.1 Verification process
a. The verification process shall demonstrate that the deliverable product
meets the specified customer requirements and is capable of sustaining
its operational role through:
1. Verification planning;
2. Verification execution and reporting;
3. Verification control and close-out.
5.2 Verification planning
5.2.1 Verification approach
a. 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.
NOTE 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”.
b. The requirements specified in 5.2.1a shall always include those of the
technical specification.
c. The supplier shall define the verification approach by conducting the
following steps:
1. Identify and agree with the customer the set of requirements to be
subject of the verification process.
2. Select the methods and the levels of verification, the associated
model philosophy and the verification tools.
3. Identify the stages and events in which the verification is
implemented.
d. The verification approach shall be defined by the supplier in the
Verification Plan (VP) for approval by the customer prior to
implementation.
e. 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.
5.2.2 Verification methods
5.2.2.1 General
a. Verification shall be accomplished by one or more of the following
verification methods:
1. test (including demonstration);
2. analysis (including similarity);
3. review-of-design;
4. inspection.
b. <>
c. <>
d. 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.
e. 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.
5.2.2.2 Test
a. Verification by test shall consist of measuring product performance and
functions under representative simulated environments.
b. <>
c. <>
d. <>
e. <>
f. <>
g. <>
5.2.2.3 Analysis
a. Verification by analysis shall consist of performing theoretical or
empirical evaluation using techniques agreed with the Customer.
NOTE Techniques comprise systematic, statistical and
qualitative design analysis, modelling and
computational simulation.
b. <>
c. Analysis to demonstrate qualification of a product by similarity with an
already qualified product shall fulfil the following criteria:
1. The already qualified product was not qualified by similarity.
2. The product to be verified belongs to category A or to category B
(defined in Table 5-1) but no testing is required to achieve
qualification.
NOTE Implicitly the product to be verified cannot
belong to categories C and D equipment
(defined in Table 5-1).
d. Similarity analysis shall define differences that can dictate additional
verification activities.
e. An analysis programme shall be defined in the Verification Plan (VP).
f. An analysis programme shall be applicable to qualification and in-orbit
stages only.
5.2.2.4 Review-of-design (ROD)
a. Verification by Review-of design (ROD) shall consist of using approved
records or evidence that unambiguously show that the requirement is
met.
NOTE Examples of such approved records are design
documents and reports, technical descriptions,
and engineering drawings.
b. A review-of-design programme shall be defined in the Verification Plan
(VP).
c. A review-of-design programme shall only be applicable in the
qualification stage or in the in-orbit stage.
5.2.2.5 Inspection
a. Verification by inspection shall consist of visual determination of
physical characteristics.
NOTE Physical characteristics include constructional
features, hardware conformance to document
drawing or workmanship requirements,
physical conditions, software source code
conformance with coding standards.
b. An inspection programme shall be defined in the Verification Plan (VP).
5.2.3 Verification levels
a. Verification shall be accomplished through the verification levels in
conformance with those defined with the Annex A Verification Plan
DRD.
NOTE Usual levels are defined in 4.2.3.
b. When a requirement is fully verified at lower level, the traceability to
lower level verification evidence shall be identified.
c. Formal close-out of qualification and acceptance at lower levels shall be
performed prior to close-out at higher level.
5.2.4 Verification stages
5.2.4.1 General
a. The Verification Plan shall state which verification activities are to be
accomplished in each of relevant verification stages.
b. Qualification, acceptance and pre-launch stages shall be completed
before launch.
c. When the verification programme includes an in-orbit stage, the
verification shall not rely only on in-orbit activities.
d. When the verification programme includes a post landing stage, the
verification shall not rely only on in-orbit activities or post landing
activities.
5.2.4.2 Qualification
a. In the qualification stage the supplier shall demonstrate that the design,
including margins, meets the applicable requirements.
b. 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.
c. The qualification programme shall be prepared considering the product
category according to heritage as defined in Table 5-1.
d. For product categories A, B and C, the supplier shall state the
qualification status at the EQSR (Equipment Qualification Status
Review).
Table 5-1: Product categories according to heritage
Category Description Qualification programme
Off-the-shelf product without modifications and None
A
• 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
Off-the-shelf product without modifications. Delta qualification programme,
B
decided on a case by case basis.
However:
It has been subjected to a qualification test
programme less severe or different to that
imposed by the actual project specifications
(including environment).
Off-the-shelf product with modifications. Delta or full qualification
C
programme (including testing),
Modification includes changes to design, parts,
decided on a case by case basis
materials, tools, processes, procedures, supplier,
depending on the impact of the
or manufacturer.
modification.
Newly designed and developed product. Full qualification programme.
D
5.2.4.3 Acceptance
5.2.4.3.1 General
a. 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.
b. Acceptance shall be carried-out on the product which is declared as the
acceptance article with a defined configuration of hardware and
software.
5.2.4.3.2 Acceptance article
a. The acceptance article shall be manufactured in agreement with the
qualified design.
b. The acceptance article shall perform as the qualified product.
5.2.4.4 Pre-launch
a. In the pre-launch stage the verification shall demonstrate that the
product is properly configured for launch activities and early operations.
b. In the pre-launch stage the verification shall confirm that the product is
capable of functioning as planned during launch and early operations.
5.2.4.5 In-orbit
a. In the in-orbit stage the verification shall address the minimum set of
requirements that cannot be verified on ground.
b. 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.
c. 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.
d. In the in-orbit stage the verification shall confirm that the space and
ground elements are compatible with each other.
NOTE 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).
e. <>
5.2.4.6 Post-landing
a. The verification in the post-landing stage shall address the product
integrity and performance after the mission.
b. In case the product is intended to be re-launched the verification shall
address:
1. a health check, at periodical intervals agreed with the customer,
during storage periods;
2. the product performance after modification, repair or replacement;
3. the readiness for reuse.
5.2.5 Models
a. The model philosophy shall be defined as part of the overall verification
planning.
5.2.6 Verification tools
5.2.6.1 General
a. Tools to be used to support the implementation of the verification
process shall be identified.
b. All verification tools shall be validated and maintained for their intended
use.
c. <>
d. Formal verification procedures shall be established and applied to tools
which are specified as deliverable items.
5.2.6.2 Ground support equipment (GSE)
a. All ground support equipment (GSE) shall be verified under expected
environmental conditions and operational constraints.
b. The compatibility of the interfaces of the ground support equipment
(GSE) with flight products and facilities shall be verified.
c. The prevention of damage on the flight product due to ground support
equipment (GSE) failure shall be verified.
NOTE For hazards to personnel, flight hardware,
facilities and environments related to GSE, see
ECSS-Q-ST-40.
d. Ground support equipment (GSE) that is modified or used in a new
application shall be re-verified or re-validated.
5.2.6.3 <>
a. <>
b. <>
5.2.6.4 Simulators
a. 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.
5.2.6.5 Software tools for verification by analysis
a. Suitability of previously validated analytical software tools shall be
assessed for the intended application.
b. Non-validated analytical software tools shall be subjected to a validation
process prior to their use.
5.2.6.6 Integration and test facilities and test tools
a. 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.
NOTE See ECSS-Q-ST-20-07 for test facilities.
5.2.7 Verification process phasing
a. The verification process shall be phased with the project life cycle, in
accordance with ECSS-M-ST-10.
b. Verification planning to assess feasibility and support development
planning shall start during phase A.
c. The preliminary verification planning shall cover all products and
requirements by the end of phase B.
d. Verification planning shall be completed by the end of Phase C.
NOTE Covering all verification stages e.g. pre-launch,
in-orbit (including commissioning) and post
landing.
e. Verification execution and reporting shall be incrementally carried out
through the project life cycle starting from phase C.
NOTE 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.
f. Verification control shall start with the initial issue of the verification
control document (VCD) during phase B.
g. The supplier shall provide the Verification close out status for each
product at the end of each stage to the customer for approval.
NOTE E.g. qualification close out status at the end of
the qualification stage during the Qualification
Review (QR).
5.2.8 Verification planning documents
5.2.8.1 Verification plan (VP)
a. The supplier shall provide a Verification plan (VP) for the reviews as
agreed with the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
b. The contents of the Verification plan (VP) shall be in conformance with
the DRD in Annex A.
5.2.8.2 Verification Control Document (VCD)
a. The supplier shall provide a Verification Control Document (VCD) for
the reviews as agreed with the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
b. The Verification Control Document (VCD) shall be in conformance with
the DRD in Annex B.
5.2.8.3 Other verification planning Document
a. The supplier shall provide the AIT Plan for the reviews as agreed with
the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
b. The AIT plan shall be in accordance with the DRD in ECSS-E-ST-10-03
Annex A.
5.3 Verification execution and reporting
5.3.1 General
a. The supplier shall identify those responsible for the implementation of
the verification activities.
b. <>
c. 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.
d. The verification results shall be recorded by the supplier in verification
reports and provided to the Verification Control Board (VCB) for review.
5.3.2 Verification execution and reporting
documentation
5.3.2.1 Test report
a. 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.
b. The supplier shall provide Test reports for the reviews in conformance
with the DRD in Annex C.
c. The supplier shall provide the Test reports for the reviews as agreed with
the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
d. A Test report shall be provided for each Test verification task as
identified in the VP or AIT Plan.
5.3.2.2 Analysis report
a. 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.
b. <>
c. The supplier shall provide an Analysis report for the reviews as agreed
with the customer.
NOTE 1 See ECSS-E-ST-10 Table A-1 for review
deliverables.
NOTE 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.
d. An Analysis report shall be provided for each Analysis verification task
identified in the Verification Plan.
5.3.2.3 Review-of-design report
a. 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.
b. The supplier shall provide the Review-of-design report in conformance
with the DRD in Annex D.
c. The supplier shall provide a Review-of-design for the reviews as agreed
with the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
d. A Review-of-design report shall be provided for each Review-of-design
verification task identified in the Verification Plan.
5.3.2.4 Inspection report
a. 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.
b. The supplier shall provide the Inspection report in conformance with the
DRD in Annex E.
c. The supplier shall provide an Inspection report for the reviews as agreed
with the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
d. An Inspection report shall be provided for each Inspection verification
task identified in the Verification Plan.
5.3.2.5 Verification report
a. 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.
b. The supplier shall provide the Verification report in conformance with
the DRD in Annex F.
c. 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.
d. The supplier shall provide a Verification report for the reviews as agreed
with the customer
NOTE See ECSS-E-ST-10 Table A-1 for review
deliverables.
5.3.2.6 Other verification execution and reporting
Document
a. <>
b. <>
c. <>
d. <>
e. The rules for the analysis, inspection and review of design shall be
defined in writing before their execution.
NOTE 1 For example, analysis, inspection or review of
design procedures.
NOTE 2 The rules for Test are as detailed in ECSS-E-ST-
10-03.
5.4 Verification control and close-out
5.4.1 General
a. The implementation of the verification process shall be monitored by the
Verification Control Board (VCB).
b. The supplier shall provide a computer based verification database to
support the verification process control.
c. The supplier shall deliver the verification database to the customer in an
electronic form to be agreed with the customer.
d. The supplier shall capture and provide verification close-out evidence in
the verification database for those customers requirements agreed to be
verified.
5.4.2 Verification control board (VCB)
a. A Ver
...