ISO 23135:2022

INTERNATIONAL ISO
STANDARD 23135
First edition
2022-03
Space systems — Verification
programme and management process
Reference number
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Requirements for space system verification management processes .3
4.1 General . 3
4.2 VM process 1: requirement flow-down and establishment of specification . 3
4.2.1 General . 3
4.2.2 Specification requirements and review . 4
4.2.3 Data supporting verification method and approach . 5
4.3 VM process 2: verification cross-reference matrix (VCRM) . 5
4.3.1 Cross-reference of specification requirements and verification method . 5
4.3.2 VCRM for the space system and lower level systems . 5
4.3.3 Verification by analysis . 5
4.3.4 Verification by test. 5
4.3.5 Verification by inspection and demonstration . 6
4.4 VM process 3: integration and test (I&T) process . 6
4.4.1 General . 6
4.4.2 Review of I&T plans for the space system and lower level systems . 6
4.4.3 Space system and lower-level I&T sequence and test environments . 6
4.4.4 Operational tests for space system . 6
4.4.5 Test readiness review (TRR) and entry/exit criteria . 6
4.4.6 Test discrepancy resolution and retest . 7
4.4.7 Test summary and “as tested” data review . 7
4.4.8 I&T plans for launch site operations for each element . 7
4.4.9 I&T plans for launch site operations for integrated system . 7
4.5 VM process 4: specification verification ledger (SVL) process . 7
4.5.1 General . 7
4.5.2 SVL content . 7
4.5.3 SVL documentation . 8
4.5.4 Subcontractor/vendor SVL plans for the space system element including
subsystems, and units . 8
4.6 VM process 5: acceptance and delivery review process. 8
4.6.1 General . 8
4.6.2 Space system and lower level systems acceptance and delivery review data
package . 8
4.6.3 Acceptance and delivery review plans for the systems developed by
subcontractors/vendors . 8
4.6.4 FCA and PCA summary as a part of acceptance package . 8
4.6.5 Acceptance/delivery review entry/exit criteria . 9
4.7 VM process 6: verification-related risk and issue/watch list management process . 9
4.7.1 General . 9
4.7.2 Status tracking of verification-related issue and concern items . 9
4.7.3 Reporting of verification-related issues to the programme risk
management board . 9
4.7.4 Verification-related risk and issue/watch list management plans for
the space system and lower level systems including those developed by
subcontractors/vendors . 9
5 Requirements for space systems verification programme management .9
iii
5.1 General . 9
5.2 Verification programme managed by each WBS element . 9
5.3 Integration of distributed verification programme . 10
5.4 Verification programme review . 10
5.5 Verification programme flow-down to subcontractors and vendors . 10
5.6 Verification activities coordinated with other review boards . 10
5.7 Validation of the verification process . 10
5.7.1 General . 10
5.7.2 DT&E and OT&E support . 10
5.7.3 Independent readiness review (IRR) and launch readiness review (LRR)
support . 10
5.8 Verification plan . 11
5.8.1 General . 11
5.8.2 Review of verification plans . 11
6 Use of verification management for late changes and heritage/commercial systems .11
6.1 General . 11
6.2 Late change verification management . 11
6.2.1 Verification of late changes utilizing VM processes 1 through 6 . 11
6.2.2 Late change categories .12
6.3 Heritage/commercial systems verification management .12
6.3.1 General .12
6.3.2 Heritage/commercial hardware and software applications .12
6.3.3 Verification of heritage hardware and software .13
Annex A (informative) Exemplar space system and an example of WBS-based verification
management structure .14
Annex B (informative) Review of verification plans for space system and lower system
level, including those developed by subcontractors/vendors .15
Annex C (informative) Deliverable/review documents associated with each verification
management rrocess .20
Annex D (informative) Contents of specification verification ledger (SVL) .22
Annex E (normative) Recommended Check List for Planning and Executing Late Changes,
Heritage, or Commercial System Applications .24
Bibliography .28
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 20, Aircraft and space vehicles,
Subcommittee SC 14, Space systems and operations.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
This verification programme document provides top-tier and overarching requirements in space
programmes. Implementation will ensure thoroughly verified space systems in a timely and cost-
effective manner for verification distributed among all participating organizations (see AIAA S-117).
Many space programmes are very complex systems consisting of numerous elements (such as
spacecraft, launch and ground segments, systems, subsystems, units, interfaces). It is common for
these elements to be distributed across many international/domestic contractors, subcontractors,
and suppliers with little room for failure/mistakes in any part of a space system. This is what is
meant as a distributed program in the context of this document. A critical function of any distributed
verification programme is to ensure that a thorough and solid specification is established for each level
of a system being developed. This is accomplished if the system developer for each level contractually
takes responsibility/ownership of developing their specifications in coordination with their systems
engineering organization. This approach ensures that requirements establishment and associated
verification activities are well integrated. Additionally, cost constraints often require avoidance of
additional verification due to late changes. Lack of detailed descriptions in specifications can cause
costly late changes and/or post-launch failures. Mission success does not allow unrecoverable post-
launch failures; as such, verification of space systems requires technical communication of verification
means, data and data aggregation among all involved (system contractors, subcontractors and vendors).
This document ensures that requirements associated with space system missions, concept of operation
(mission operation concept), contractual agreed normative references as well as each contractor’s
command media are thoroughly verified with the use of a distributed verification programme. It
defines a standardized set of verification management processes for each element of a space system
from the earliest to the latest phase and from the lowest to the highest level of their developments in
order to acquire/deliver thoroughly verified systems.
The need for a distributed verification programme was identified based on the evaluation of over
130 space systems failures associated with international, commercial, and government space
programmes (see INCOSE Journal).
Every element of a space system can be verified and tracked by each work breakdown structure
based working group (WBS-WG; see ISO 21349) utilizing standardized verification management (VM)
processes as follows:
a) VM process 1: requirements flow-down and establishment of specification;
b) VM process 2: verification cross-reference matrix (VCRM);
c) VM process 3: integration and test (I&T);
d) VM process 4: use of a specification verification ledger (SVL);
e) VM process 5: acceptance/delivery reviews
f) VM process 6: verification-related risk and issue/watch list management
This document also helps each space programme to integrate any heritage/commercial systems
to new programmes by examining whether the applicability of these systems has been thoroughly
verified. Appropriate modifications of any heritage/commercial systems for new/modified systems
are systematically identified and verification accomplished by applying these uniform six verification
management processes.
vi
INTERNATIONAL STANDARD ISO 23135:2022(E)
Space systems — Verification programme and management
process
1 Scope
This document establishes a set of requirements for planning and executing verification programmes
for commercial/non-commercial manned and unmanned space systems.
This document defines a distributed verification programme for each contractor that engages in the
development of any element of a space system, starting from the lowest level (i.e. unit/piece part level)
and the earliest phase (i.e. requirement phase) to the acceptance and the delivery review of a system’s
development as well as the launch site activities.
This document primarily addresses verification associated with space, launch, and ground segment
acquisitions. Space support segments including range safety, ground support equipment, and launch
operation facilities, which are not otherwise addressed in this document, can also benefit from the
described verification programme and management processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
heritage system
system/item with from the original supplier that has maintained the great majority of the original
service, design, performance and manufacturing and has already flown in space
3.1.2
late change
change to the space, launch, ground segments, or their interfaces, procedures or processes, which
compromise or potentially invalidate previously executed verification approved at each system level
preliminary design review (PDR) and/or critical design review (CDR)
3.1.3
mission critical failure
condition that meets one or more of the following criteria:
a) failure leading to inability to meet/achieve mission objective (e.g. payload or spacecraft bus is no
longer capable of supporting the mission objectives);
b) inability to meet minimum performance specifications for primary mission;
c) degrading condition whose trend indicates a loss of mission before mean mission duration or
design life;
d) repetitive transient condition(s) that, uncorrected, would lead to an unacceptable loss of mission
performance, data or services (e.g. satellite with processor susceptibility to single event upsets in
orbit with mean time to upset much less than mean time to recovery from upset)
3.1.4
operational test and evaluation
test and evaluation that represents the mission in terms of phase, transitions, environments, personnel
and events in an end-to-end system configuration (i.e. combination of hardware/software and data
when functioning as an integrated system), accepting mission inputs, executing mission functions
and producing mission outputs according to the typical operational rhythm, timelines, and sequences
resulting in end-user goals (products, services, and timeliness)
3.1.5
specification verification ledger
digital database for verification information of the space system specification
3.1.6
subject matter expert
person with substantial knowledge of, and experience with, the topic at hand, including terms,
technology and methods
3.1.7
verification cross-reference matrix
matrix, usually electronic database of some type, maintained to correlate all verification needs within
an assigned portion of a program, up to and including a complete program matrix
Note 1 to entry: The matrix does not replace other verification plans or requirements, but is a summary of them.
3.1.8
verification method
method including test, analysis, demonstration, or inspection
Note 1 to entry: See ISO 9000.
3.1.9
verification record
record of requirement conformity or compliance based on the assigned verification method(s) (3.1.8)
3.2 Abbreviated terms
AIAA American Institute of Aeronautics and Astronautics
CDR critical design review
CDRL contract data requirements list
COTS commercial, off-the-shelf
CM configuration management
DT&E development test and evaluation
EM engineering module
EMC electro-magnetic compatibility
EMI electro-magnetic interference
FCA functional configuration audit
I&T integration and test
IF interface
LRR launch readiness review
MRR manufacturing readiness review
NRB non-conformance review board
OT&E operational test and evaluation
PCA physical configuration audit
PDR preliminary design review
PMPCB parts, materials, and processes control board
QA quality assurance
SC spacecraft
SVL specification verification ledger
SDR system design review
SRR system requirements review
TPRD test parameters requirements document
TRR test readiness review
VCRM verification cross-reference matrix
VM verification management
WC worst-case
WBS work breakdown structure
WBS-WG WBS-based working group
4 Requirements for space system verification management processes
4.1 General
Each space system and lower-level systems developer shall implement the verification processes
detailed in 4.2 through 4.7. To better support a specific programme or project, the processes defined in
this document may be tailored to match the actual requirements or needs of the programme.
4.2 VM process 1: requirement flow-down and establishment of specification
4.2.1 General
The developers of each level of the system, in coordination with their systems engineering organizations,
develop a system-level specification with both performance and verification requirements for their
system. They capture the requirements that are flowed down from the top-level space system to
WBS elements, external interface specifications, and concept of operations (CONOPS) of their system.
They capture all the derived and specific requirements including those of normative references that
are necessary to design and develop their system. They also capture/modify all the heritage system
requirements that are compatible with the top-level requirements determined by the requirements
flow-up process.
Each specification shall include sections relating to:
a) the function, performance, constraints, and normative references for the product;
b) a detailed statement of how verification will be made for each separate requirement.
This includes verification methods and associated verification approaches.
NOTE 1 Specifications are defined in ISO 9000.
NOTE 2 See ISO/IEC/IEEE 15288 for flow-down and flow-up in the systems engineering “V”.
NOTE 3 See ISO 16404 for general requirement management process including those associated with support
to systems engineering activities such as those associated with verification and configuration management.
NOTE 4 See ISO 14711 for CONOPS-related documents.
4.2.2 Specification requirements and review
4.2.2.1 General
Specifications shall be delivered for review at each corresponding system level’s review from the top
system level to the lowest unit level specification [e.g. system requirements review (SRR), system
design review (SDR), preliminary design review (PDR), critical design review (CDR)].
NOTE See ISO 14300-1 for project phasing and reviews.
4.2.2.2 Top-level requirements flowed-down/up documented traceability
Each of the top space system level requirements flowed down/up shall have documented traceability in
the verification record to the lowest level of the work breakdown structure (WBS).
4.2.2.3 Verification of non-derived requirements specific to each system
Verification requirements shall capture all the non-derived requirements that are specific to each of
the elements being developed.
NOTE Non-derived requirements are requirements which do not have a parent requirement in the next
higher level, such as those that are needed to satisfy heritage systems.
4.2.2.4 Verification of compatibility of heritage systems requirements
When heritage systems are used, verification requirements shall ensure that each of the requirements
in the heritage system specification is compatible with and supports the higher- and lower-level system
requirements. If not, they need to modify any noncompliant requirements accordingly (see ISO 16290).
4.2.2.5 Requirement verifiability
Each of the requirements shall be verifiable by analysis, test, inspection or demonstration or a
combination of them (see ISO 9000).
4.2.2.6 Normative references flow-down
Each of the normative references listed at any system level shall also be flowed down from the
appropriate level specification to any of the applicable lower level specifications.
4.2.2.7 Configuration management (CM)
The system level requirements shall be under CM control upon completion of SRR.
Lower level requirements shall be under CM control upon completion of PDR.
The requirements flow-down and flow-up efforts should be accomplished by utilizing data management
software in order to effectively manage any part of system level requirements flowed down/up to/from
any other system levels.
Validation of the developed specification may be considered as completed after independent subject
matter experts from external organizations have reviewed the specification and their comments are
incorporated into the specification.
4.2.3 Data supporting verification method and approach
Each specification verification implementation shall include data and processed data (information)
which establishes the satisfaction of the requirement as well as the associated upper level requirements.
This includes a synopsis and rationale for the actual implementation approach for each requirement.
4.3 VM process 2: verification cross-reference matrix (VCRM)
4.3.1 Cross-reference of specification requirements and verification method
The VCRM shall cross-reference specification requirements, their verification methods, verification
level and milestones.
4.3.2 VCRM for the space system and lower level systems
Verification plans for the space system and all the lower-level systems, including external and internal
IFs, are delivered at major reviews (See Clause 5). These plans shall include the VCRM for each level.
4.3.3 Verification by analysis
a) Design and analysis documents shall be developed for each level of the system being developed
(system, subsystem, unit, etc.) and ensure that all the “verify by analysis” requirements in the
corresponding specification are documented and satisfied.
NOTE A list of analyses along with the approaches and methods, and a set of design reference cases that
defines reasonable worst-case conditions and other conditions for each analysis used for “verification by
analysis” are identified and documented.
b) Design analyses sometimes require the support from test results. In these cases, a list of “verify
by test” requirements that require development test to support the design analysis shall also be
included in the design and analysis list.
c) When a space safety-critical design or function is only satisfied by “verify by analysis” requirements
in the corresponding specification and determined as one of the pass/failure criteria for the
associated PDR and CDR, then a risk assessment shall be conducted and included of the contribution
to residual risk on people, the space environment, and the mission, because of the space safety-
critical design or function in question.
4.3.4 Verification by test
“Verification by test” is accomplished using such tests as development test, prototype test, life test,
pre-flight brass board/engineering modules tests, actual flight system integration and acceptance/
qualification test, and operational test depending on the nature of the requirements being verified.
A list of tests, approaches (such as with the use of flight units, engineering units, breadboard, coupons,
software/hardware-in-the-loop test), and test conditions for “verification by test” shall be included in
the VCRM and reviewed at the corresponding system’s PDR, CDR and TRR.
a) “Verification by test" based on development hardware/software or breadboard testing may be
required to substantiate related analyses or vice versa. These development test lists, approaches,
conditions and results are normally reviewed along with the associated analyses.
b) “Verification by test" requirements under the acceptance/qualification tests, shall be listed in a test
parameters requirement document (TPRD) and incorporated into the corresponding test plan that
is developed based on VM process 3, explained in 4.4.
4.3.5 Verification by inspection and demonstration
A list of and detailed approaches for “verification by inspection” and “verify by demonstration”
requirements shall be developed for each of the applicable space system and lower level system
specifications.
4.4 VM process 3: integration and test (I&T) process
4.4.1 General
In preparation for the I&T life cycle phase, system I&T plans shall be developed for the space system and
each of the lower-level systems to ensure that the “as built” system is rigorously tested for acceptance
tests,qualification tests or tests related to the mitigation of potential mission critical failures.
NOTE See ISO 17566, ISO 17401, ISO 14303, and ISO 15864 which define test documentation, spacecraft
interface requirements document, launch-vehicle-to-spacecraft interfaces, and general test methods respectively.
4.4.2 Review of I&T plans for the space system and lower level systems
I&T plans for each of the spacecraft, launch vehicle, ground system and each of the internal and external
interfaces including those developed by subcontractors and vendors shall be delivered for review and
approval at each corresponding PDR, CDR, and TRR.
4.4.3 Space system and lower-level I&T sequence and test environments
A test sequence, environment types/levels, duration, and test monitoring approaches/methods,
with documented rationales for selecting the acceptance, proto-qualification, or qualification test
programme shall be established and documented for each of the space system and lower-level systems
including those developed by subcontractors and vendors.
4.4.4 Operational tests for space system
An operational test plan shall be developed and executed prior to launch/operations to verify critical
mission characteristics including the planned mission sequences, events, transitions, timelines,
processes, configurations, command operations, data/telemetry downlinks and processing, and
deployment functions.
NOTE An operational test is based on effectiveness (can the system perform the mission) and suitability (can
the system perform the mission in a manner that is affordable and sustainable) without artificial constraints to
the fullest extent possible.
4.4.5 Test readiness review (TRR) and entry/exit criteria
TRR shall be conducted prior to each of the space system and lower level systems I&T based on the
entry and exit criteria that are reviewed and approved at PDR, CDR, and/or pre-TRR.
The entry/exit criteria to hold TRR for each space system and lower level systems shall be planned
and updated throughout its PDR, CDR, and pre-TRR to ensure all the “verify by test” requirements are
satisfied.
4.4.6 Test discrepancy resolution and retest
Test discrepancies at any level of flight hardware/software system integration and test shall be
reported, investigated and resolved.
As an example, a non-conformance review board (NRB) may coordinate the failure investigation and
resolution such as with the parts, materials, and processes control board (PMPCB); quality assurance
(QA), if required along with the appropriate WBS lead; and the programme management for their
approval. ISO 23461 contains further information for this example.
4.4.7 Test summary and “as tested” data review
Each test level shall include a list of discrepancies, their disposition, and retest history which have been
well documented, reviewed and approved.
To continue the example above, by QA, the NRB, the PMPCB, the appropriate WBS lead, and space system
verification programme management at the conclusion of the test and before the item is transferred to
the next level of integration and test phase.
4.4.8 I&T plans for launch site operations for each element
The launch site I&T plan and procedures shall be developed for each of the flight space vehicle, launch
vehicle, ground elements, and ground test equipment to ensure that each element is functioning and
ready for launch throughout the pre-launch count and the launch count procedures.
4.4.9 I&T plans for launch site operations for integrated system
The launch site I&T plan and detailed test procedures shall be developed for the integration and testing
of all combined spacecraft, launch, ground, ground test equipment, and range safety systems.
4.5 VM process 4: specification verification ledger (SVL) process
4.5.1 General
The SVL process shall be implemented for the space system from the unit through system levels,
including associated IFs and normative references, using a form that summarizes information for
verification traceability. Referencing the VCRM, the SVL shall contain data and processed data
(information) which confirms the satisfaction of the requirement as well as the associated upper level
requirements.
NOTE All of the SVL columns help to expedite the acceptance, latent troubleshooting, or independent
readiness review process, since the data can be easily tracked down and obtained when required. Also, it helps to
ensure the applicability of the system to other programmes such as an upgraded or a brand new programme.
4.5.2 SVL content
The SVL for each of space system and lower level systems shall include, but is not limited to, a requirement
description/ID number in the specification, a synopsis of the verification method/approach, the
organization responsible for verification, and the verification product ID such as the analysis or test
report. An example of a set of minimally required contents for SVL is provided in Annex D. The order of
information (columns) is not prescriptive, as long as the hierarchy of information is maintained.
4.5.3 SVL documentation
The content of SVLs for the space system and lower-level items shall be stored electronically by the
programme to assure that the proof of full requirements’ verification is complete for all the elements
and also to ensure configuration management of the contents.
4.5.4 Subcontractor/vendor SVL plans for the space system element including subsystems, and
units
SVL plans and results for each element including those developed by subcontractors/vendors shall be
delivered for review and approval at SRR, SDR, PDR, CDR, and acceptance/delivery review.
4.6 VM process 5: acceptance and delivery review process
4.6.1 General
A set of entry and exit criteria and a standardized set of review data packages shall be developed for
each of the space system and lower level systems’ acceptance/delivery review activities.
NOTE 1 When each element completed VM process 5 is ready to be delivered to the next step of integration
activities (acceptance activities) or to the launch site (delivery review activities), these processes ensure these
elements have been verified (and validated if the customer is involved with these efforts).
NOTE 2 Entry/exit criteria for the acceptance and delivery reviews are not necessarily the same because the
completion of a space system acceptance/delivery review sometimes requires the results of higher-level I&T
results.
4.6.2 Space system and lower level systems acceptance and delivery review data package
A data package for each of the space system and lower level systems’ acceptance and delivery review
shall include the approval statement as follows:
a) SVL;
b) as-tested test report;
c) test summary, including environment test history, test anomaly, and disposition summary;
d) NRB/PMPCB summary, including approved/waived part lists;
e) deviations/waivers summary;
f) disposition status of action items generated at associated system’s PDR, CDR, TRR, and test data
review;
g) disposition status of all the issue/concern items associated with each of the space system and lower
level systems;
h) summary of functional configuration audit (FCA) and physical configuration audit (PCA).
4.6.3 Acceptance and delivery review plans for the systems developed by subcontractors/
vendors
Acceptance and delivery review plans and the results for space system and lower level systems
including those developed by subcontractors/vendors shall be delivered for review and approval at
SRR, SDR, PDR, CDR, and acceptance/delivery review milestones.
4.6.4 FCA and PCA summary as a part of acceptance package
An FCA and PCA shall be conducted; and their results are provided as a part of acceptance activities.
4.6.5 Acceptance/delivery review entry/exit criteria
The entry/exit criteria to conduct successful acceptance/delivery reviews for each space system
and lower level systems shall be planned and updated to ensure throughout its PDR, CDR, and pre-
acceptance/delivery reviews to shipping to ensure the completion of documented and traceable proof
of verification as explained in 4.6.2 through 4.6.4.
NOTE Inclusion or non-inclusion of shipping is determined by program.
4.7 VM process 6: verification-related risk and issue/watch list management process
4.7.1 General
Verification-related issue-and-concern items shall be identified, resolved, and documented for each
verification activity throughout the requirements flow-down, design, manufacturing, test, and
acceptance/delivery review and launch site I&T phases of the programme.
ISO 17666 should be used to determine which concerns/problems should remain on issue/watch lists
and which concerns should be reported to the overall programme level risk items.
4.7.2 Status tracking of verification-related issue and concern items
Each of the verification-related issue and concern items shall be documented, including the problem
description, responsible organization/engineers, problem identification and required resolution date,
its resolution status and tracked by the corresponding WBS-WG.
4.7.3 Reporting of verification-related issues to the programme risk management board
All verification-related concerns that can impact the cost, performance, and/or schedule of the
programme shall promptly be reported to the programme-level risk management board so that the
board can determine whether the concern needs to be elevated to a programme risk
4.7.4 Verification-related risk and issue/watch list management plans for the space system
and lower level systems including those developed by subcontractors/vendors
A verification-related issue/watch list management plan and the status for each of the space system
and the lower level systems including those developed by subcontractors/vendors shall be delivered for
review at SRR, SDR, PDR, CDR, and acceptance/delivery review.
5 Requirements for space systems verification programme management
5.1 General
Each space programme shall establish a space system verification programme in order to manage
verification processes by implementing a standard set of verification management activities at each
level and phase of system development as specified in Clause 4.
NOTE Verification processes apply to planning and executing activities starting at the requirements
definition phase and extending through the launch, post-launch phase.
5.2 Verification programme managed by each WBS element
The verification programme shall utilize subject matter experts under each WBS element to plan
and execute verification of their space system element(s) by following the requirements specified in
Clause 4.
NOTE 1 See ISO 21349.
NOTE 2 See Annex A.
This g
...