SIST-TP CEN/CLC/TR 17602-80-12:2021

SLOVENSKI STANDARD
01-december-2021
Zagotavljanje kakovosti proizvodov v vesoljski tehniki - Ocenjevanje in izboljšanje
programske opreme - 2. del: Instrument ocenjevalca
Space product assurance - Software process assessment and improvement - Part 2:
Assessor instrument
Raumfahrtproduktsicherung - Software - Prozessüberprüfung und -verbesserung - Teil 2:
Gutachter
Assurance produit des projets spatiaux - Evaluation et amélioration des processus
logiciel - Partie 2: Elément d’évaluation
Ta slovenski standard je istoveten z: CEN/CLC/TR 17602-80-12:2021
ICS:
03.120.99 Drugi standardi v zvezi s Other standards related to
kakovostjo quality
35.080 Programska oprema Software
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.

TECHNICAL REPORT
CEN/CLC/TR 17602-80-
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
October 2021
ICS 49.140; 35.240.99
English version
Space product assurance - Software process assessment
and improvement - Part 2: Assessor instrument
Assurance produit des projets spatiaux - Evaluation et Raumfahrtproduktsicherung - Software -
amélioration des processus logiciel - Partie 2: Elément Prozessüberprüfung und -verbesserung - Teil 2:
d'évaluation Gutachter
This Technical Report was approved by CEN on 13 September 2021. It has been drawn up by the Technical Committee
CEN/CLC/JTC 5.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2021 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. CEN/CLC/TR 17602-80-12:2021 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 4
Introduction . 5
1 Scope . 6
2 References . 7
3 Terms, definitions and abbreviated terms . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms. 9
4 Process Assessment Model . 10
4.1 Process dimension . 10
4.1.1 Introduction . 10
4.1.2 Process definitions . 12
4.1.2.1 Acquisition process group (ACQ) .13
4.1.2.1.1 ACQ.1 Acquisition Preparation .13
4.1.2.1.2 ACQ.2 Supplier Selection .14
4.1.2.1.3 ACQ.3 Contract Agreement .15
4.1.2.1.4 ACQ.4 Supplier Monitoring .16
4.1.2.1.5 ACQ.5 Customer Acceptance.18
4.1.2.1.6 ACQ.6 Contract Maintenance .19
4.1.2.2 Supply process group (SPL) .20
4.1.2.2.1 SPL.1 Supplier Tendering .20
4.1.2.2.2 SPL.2 Product Release .22
4.1.2.2.3 SPL.3 Product Acceptance Support .24
4.1.2.3 Operation process group (OPE) .25
4.1.2.3.1 OPE.1 Operational Use .25
4.1.2.3.2 OPE.2 Customer Support .26
4.1.2.4 Engineering process group (ENG) .28
4.1.2.4.1 ENG.1 Requirements Elicitation .28
4.1.2.4.2 ENG.2 System Requirements Analysis .29
4.1.2.4.3 ENG.3 System Architectural Design .30
4.1.2.4.4 ENG.4 Software Requirements Analysis .32
4.1.2.4.5 ENG.5 Software Design .34
4.1.2.4.6 ENG.6 Software Construction.36
4.1.2.4.7 ENG.7 Software Integration .38
4.1.2.4.8 ENG.8 Software Testing .40
4.1.2.4.9 ENG.9 System Integration .41
4.1.2.4.10 ENG.10 System Testing .42
4.1.2.4.11 ENG.11 Software Installation.43
4.1.2.4.12 ENG.12 Software and System Maintenance .44
4.1.2.5 Supporting process group (SUP) .47
4.1.2.5.1 SUP.1 Quality Assurance .47
4.1.2.5.2 SUP.2 Verification .48
4.1.2.5.3 SUP.3 Validation .51
4.1.2.5.4 SUP.4 Joint Review .52
4.1.2.5.5 SUP.5 Audit .54
4.1.2.5.6 SUP.6 Product Evaluation .55
4.1.2.5.7 SUP.7 Documentation .57
4.1.2.5.8 SUP.8 Configuration Management .59
4.1.2.5.9 SUP.9 Problem Resolution Management .61
4.1.2.5.10 SUP.10 Change Request Management .63
4.1.2.5.11 SUP.11 Safety and Dependability Assurance .64
4.1.2.5.12 SUP.12 Independent Software Verification and Validation .66
4.1.2.6 Management process group (MAN) .67
4.1.2.6.1 MAN.1 Organizational Alignment .67
4.1.2.6.2 MAN.2 Organization Management .70
4.1.2.6.3 MAN.3 Project Management.71
4.1.2.6.4 MAN.4 Quality Management.73
4.1.2.6.5 MAN.5 Risk Management .76
4.1.2.6.6 MAN.6 Measurement .77
4.1.2.6.7 MAN.7 Information Management .79
4.1.2.7 Process improvement process group (PIM) .81
4.1.2.7.1 PIM.1 Process Establishment .81
4.1.2.7.2 PIM.2 Process Assessment .82
4.1.2.7.3 PIM.3 Process Improvement .83
4.1.2.8 Resource and infrastructure process group (RIN) .84
4.1.2.8.1 RIN.1 Human Resource Management .84
4.1.2.8.2 RIN.2 Training .87
4.1.2.8.3 RIN.3 Knowledge Management .88
4.1.2.8.4 RIN.4 Infrastructure .89
4.1.2.9 Reuse process group (REU) .90
4.1.2.9.1 REU.1 Asset Management .90
4.1.2.9.2 REU.2 Reuse Program Management .92
4.1.2.9.3 REU.3 Domain Engineering .93
4.2 Work product characteristics . 95
4.3 Capability dimension . 95
4.4 Related processes for process attributes . 96
Annex A Conformance with ISO/IEC 15504 . 97
Annex B Links between WP and ECSS expected outputs . 98
Annex C Traceability between BP and ECSS . 114

Tables
Table 4-1: ECSS-Q-HB-80-02 set of processes. 10
Table 4-2: Related processes for process attributes . 96

European Foreword
This document (CEN/CLC/TR 17602-80-12:2021) has been prepared by Technical Committee
CEN/CLC/JTC 5 “Space”, the secretariat of which is held by DIN.
It is highlighted that this technical report does not contain any requirement but only collection of data
or descriptions and guidelines about how to organize and perform the work in support of EN 16602-
80.
This Technical report (CEN/CLC/TR 17602-80-12:2021) originates from ECSS-Q-HB-80-02 Part 2A.
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 has been prepared under a mandate 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 TR covering the same scope but with a wider domain of applicability (e.g.: aerospace).
Introduction
This Standard provides the instruments needed by competent assessors to perform assessments and to
support improvement initiatives based on the framework described in TR 17603-80-11 (equivalent to
ECSS-Q-HB-80-02 Part 1).
The ECSS-Q-HB-80-02 assessment method is a space specific instantiation of ISO/IEC 15504-5. In turn,
ISO/IEC 15504 provides a common internationally recognized framework for the terminology and
reference process assessment description.
The instruments provided in this handbook, when applied by competent assessors, support
application of the methods described in Part 1 and allow claiming conformance to those methods and
to requirements in ECSS-Q-ST-80. Specific instruments are also provided to enable claiming
conformance to the requirements in ISO/IEC 15504 for process assessments as an additional advantage
of the application of this Standard.
While the instruments provided in this handbook may be provide useful information to participants
in process assessment and improvement in general, their use is intended specifically for competent
assessors. This handbook does not pose any requirements on the organisations being assessed or
carrying out process improvement programmes whether using the methods described in Part 1 or not.
Scope
This handbook provides assessors with a number of instruments needed to perform software process
capability assessments using the assessment method described in Part 1. It also provides instruments
that help assessors to carry out their activities when performing assessments and supporting the
implementation of software process improvement initiatives using the method for process
improvement described in Part 1.
The instruments provided are:
• The Process Assessment Model (PAM) required to perform ECSS-Q-HB-80-02 assessments
including process descriptions and process attribute indicators
• Conformance statement to the requirements in ISO/IEC 15504 Part 2
• A definition of the Process Reference Model (PRM) on which the ECSS-Q-HB-80-02 PAM is
based (defined in ECSS-Q-HB-80-02 Part 1)
• Detailed traces from base practices in the ECSS-Q-HB-80-02 PAM to ECSS standards clauses
and from ECSS-Q-HB-80-02 work products to ECSS expected outputs

References
EN Reference EN in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS System - Glossary of terms
EN 16601-10 ECSS-M-ST-10C rev.1 Space project management - Project planning and
implementation
EN 16601-10-01 ECSS-M-ST-10-01C Space project management - Organization and conduct
of reviews
EN 16601-40 ECSS-M-ST-40C rev.1 Space project management - Configuration and
information management
EN 16601-60 ECSS-M-ST-60C Space project management - Cost and schedule
management
EN 16601-80 ECSS-M-ST-80C Space project management - Risk management
EN 16602-10 ECSS-Q-ST-10C Space product assurance - Product assurance
management
EN 16602-10-04 ECSS-Q-ST-10-04C Space product assurance - Critical-item control
EN 16602-10-09 ECSS-Q-ST-10-09C Space product assurance - Nonconformance control
system
EN 16602-20 ECSS-Q-ST-20C Space product assurance - Quality assurance
EN 16602-20-07 ECSS-Q-20-07A Space product assurance - Quality assurance for test
centres
EN 16602-30 ECSS-Q-ST-30C Space product assurance - Dependability
EN 16602-40 ECSS-Q-ST-40C Space product assurance - Safety
EN 16602-80 ECSS-Q-ST-80C Space product assurance – Software product assurance
EN 16603-10 ECSS-E-ST-10C System engineering general requirements
EN 16603-10-02 ECSS-E-ST-10-02C Space engineering - Verification
EN 16603-10-03 ECSS-E-10-03A Space engineering - Testing
EN 16603-40 ECSS-E-ST-40C Space engineering – Software
ISO/IEC 15504: 2003- Information technology – Process assessment
Part 1: Concepts and vocabulary (normative)
Part 2: Performing an assessment (normative)
Part 3: Guidance on performing an assessment
(informative)
Part 4: Guidance on use for process improvement and
process capability determination (informative)
Part 5: An exemplar process assessment model
(informative)
ISO/IEC 12207:2004 Information Technology – Software life cycle processes
Amd 1/Amd 2
Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purpose of this document, the terms and definitions from ECSS-S-ST-00-01 and ECSS-Q-HB-
80-02 Part 1 apply.
3.2 Abbreviated terms
For the purpose of this document, the abbreviated terms from ECSS-S-ST-00-01, ECSS-Q-HB-80-02
part 1 and the following apply:

Abbreviation Meaning
Independent Software Verification and Validation
ISVV
Process Assessment Model
PAM
Process Reference Model
PRM
Process Assessment Model
4.1 Process dimension
4.1.1 Introduction
This clause defines the process dimension of the process assessment model (PAM). The process
dimension is directly mapped to the process list defined in the Process Reference Model (PRM) which
is based on ISO/IEC 12207 Amendment 1+Amendment 2 and adds a number of space specific
processes to it.
The PRM is defined in ECSS-Q-HB-80-02 Part 1.
The process dimension contains three categories organized in the groups of processes listed in Table
4-1. Processes added in this Standard over the ones in ISO/IEC 15504 Part 5 are marked in bold.

Table 4-1: ECSS-Q-HB-80-02 set of processes
Primary life cycle processes
Acquisition process group(ACQ) ACQ.1 Acquisition preparation
ACQ.2 Supplier selection
ACQ.3 Contract agreement
ACQ.4 Supplier monitoring
ACQ.5 Customer acceptance
(*)
ACQ.6 Contract maintenance
Supply process group (SPL) SPL.1 Supplier tendering
SPL.2 Product release
SPL.3 Product acceptance support
Operation process group (OPE) OPE.1 Operational use
OPE.2 Customer support
Engineering process group (ENG) ENG.1 Requirements elicitation
ENG.2 System requirements analysis
ENG.3 System architecture design
ENG.4 Software requirements analysis
ENG.5 Software Design
ENG.6 Software construction
ENG.7 Software integration
ENG.8 Software testing
ENG.9 System integration
ENG.10 System testing
ENG.11 Software installation
ENG.12 Software and system maintenance
Supporting life cycle processes
Supporting process (SUP) SUP.1 Quality assurance
SUP.2 Verification
SUP.3 Validation
SUP.4 Joint review
SUP.5 Audit
SUP.6 Product evaluation
SUP.7 Documentation
SUP.8 Configuration management
SUP.9 Problem resolution management
SUP.10 Change request management
(*)
SUP.11 Safety and dependability assurance
(*)
SUP.12 Independent software verification and
validation
Organizational life cycle processes
Management process group (MAN) MAN.1 Organizational alignment
MAN.2 Organization management
MAN.3 Project management
MAN.4 Quality management
MAN.5 Risk management
MAN.6 Measurement
(*)
MAN.7 Information management
Process improvement process group PIM.1 Process establishment
(PIM)
PIM.2 Process assessment
PIM.3 Process Improvement
Resource and infrastructure process RIN.1 Human resource management
group (RIN)
RIN.2 Training
RIN.3 Knowledge management
RIN.4 Infrastructure
Reuse process group (REU) REU.1 Asset Management
REU.2 Reuse program management
REU.3 Domain engineering
(*)
: processes added in this handbook w.r.t the ones in ISO/IEC 15504 Part 5
These categories and basic processes correspond to all processes involved for the development of
software for space. Requirements applied for their performance are mostly described in ECSS-Q-ST-
80C and ECSS-E-ST-40C but also in other Management, Engineering and Quality ECSS Standards. The
links between Base Practices of S4S PAM and ECSS requirements are provided in this document.
4.1.2 Process definitions
This clause provides definitions for all the processes in the PAM. The definitions provided here are
mostly based on those in ISO/IEC 15504 Part 5. The definitions are an instrument for competent
assessors when measuring the capability of processes in an organization. Other parties may use them
as a source of information but they do not construe requirements for the implementation of processes.
The definition of each process consists of:
• A process identifier consisting of a code for the process group and a process number within that
group
• The process name
• The process purpose
• The process outcomes
The definition of each process is supported by a number of indicators to help assessors in rating the
process:
• A set of base practices mapped to the process outcomes. These base practices are the activities
and tasks that should be present in implementing the process. Some of these base practices are
of special relevance for specific software criticality classes. This is reflected by specifying where
relevant the classes to which the base practice is most relevant. The definition used here for
those criticality classes is the same one used in the example target capability profiles proposed
in Part 1 of this standard.
• Where relevant, notes that clarify the meaning, or show possible implementations of specific
base practices either per se or in relation to ECSS. Notes originating from ISO/IEC 15504 are
assigned a sequential number. Space or ECSS specific notes are assigned an uppercase letter.
These notes are not intended to represent requirements but to provide assessors with additional
information in interpreting the process definition in the context of space projects. The notes
describe common practice in space projects. In some instances the notes give an indication that
ECSS standards do impose specific requirements. Note that short references like ECSS-Q-80
refers to ECSS-Q-ST-80C as identified in chapter 2.
• Input and output work products associated to the process. Most work products originate in the
ISO/IEC 15504-5 definition of the process but slight differences may have been introduced to
better match to the ECSS PRM. A few of them have been added specifically to the PAM and are
space specific.
Components of the process definitions taken from ISO/IEC 15504 are shown in normal text while
ECSS-Q-HB-80-02 specific additions are shown in italics.
Please note that the material taken from ISO/IEC 15504 (normal text) may not always comply with
standard terminology and conventions applicable to ECSS standards. The space specific material (in
italics) in the process definitions has been written with the ECSS conventions in mind but sometimes
these are not followed to keep the uniformity and consistency between ISO/IEC 15504 material and
ECSS-Q-HB-80-02 specific material.
4.1.2.1 Acquisition process group (ACQ)
4.1.2.1.1 ACQ.1 Acquisition Preparation

ACQ.1
Process ID
Acquisition Preparation
Process Name
The purpose of the Acquisition Preparation process is to establish the needs and goals of
Process Purpose
the acquisition and to communicate these with the potential suppliers.
Process Outcomes As a result of successful implementation of the Acquisition Preparation process:
1) the concept or the need for the acquisition, development, or enhancement is
established;
2) the needed acquisition requirements defining the project needs are defined and
validated;
3) the customer’s known requirements are defined and validated;
4) an acquisition strategy is developed; and
5) supplier selection criteria are defined.
Base Practices ACQ.1.BP1: Establish the need.
Establish a need to acquire, develop, or enhance a system, software product or service.
[Outcomes: 1]
ACQ.1.BP2: Define the requirements.
Identify the customer/stakeholder requirements for a system and/or software product or
service. [Outcomes: 2, 3]
NOTE A: Establish requirements for each supplier.
Project Requirements Documents (= Requests for proposal) are issued by
the customer to all of his subordinate suppliers. The Project Requirements
Documents includes requirements for all aspects of the project and not be
limited to technical requirements.
The customer releases the Functional Specification for the product.
The customer should specify the technical budget target and margin
philosophy. Here technical budgets refer to those associated with
computer resources (CPU load, maximum memory size) and performance
requirements.
NOTE B: For space segment software, the criticality levels of the software elements
are determined at the functional state of the project.
For space segment software, the requirements of in-flight modification
capabilities of the software elements are determined at this stage .
The customer’s need for a MMI mock-up is defined at this stage, and if so,
general MMI standards and guidelines applicable to the project are
established.
ACQ.1.BP3: Review requirements.
Analyze and validate the defined requirements against the identified needs. Validate the
requirements to reduce risk of misunderstanding by the potential suppliers. [Outcomes:3]
ACQ.1.BP4: Develop acquisition strategy.
Develop a strategy for the acquisition of the product according to the acquisition needs.
[Outcomes: 4]
NOTE 1: The strategy may include reference to the lifecycle model, schedule,
budget and selection criteria.

NOTE C: ECSS-Q-20 defines requirements for procurement.

NOTE D: When necessary, engage in assessment work or technology qualification,
as well as starting long-lead procurements and Support System
development.
NOTE E: Note that when purchasing COTS products, the acquisition process should
be tailored. See PIM.1.BP.5.
ACQ.1.BP5: Define selection criteria.
Establish and agree on supplier selection criteria and the means of evaluation to be used
[Outcomes: 4, 5].
ACQ.1.BP6: Communicate the need.
Communicate the need for acquisition to interest parties through the identified channels.
[Outcomes: 1]
ACQ.1.BP7: Tailor the standard requirements.
Tailor requirements according to the project context, needs and objectives.
[Outcomes:3]
Work Products
Input Work Products Output Work Products
WP15-04 Market analysis report [Outcomes: 2] WP08-02 Acquisition plan [Outcomes: 4]
WP15-19 Product needs assessment [Outcomes: 1, 3, 4] WP12-01 Request for proposal [Outcomes: 4, 5]
WP18-00 Standard [Outcomes: 7] WP13-19 Review records [Outcomes: 3]
WP15-01 Analysis report [Outcomes: 1, 2]
WP15-19 Product needs assessment [Outcomes: 2, 3]
WP17-03 Customer requirements [Outcomes: 3]
WP17-09 Product requirements [Outcomes: 3]
WP18-01 Acceptance criteria [Outcomes: 2]
WP18-08 Supplier selection criteria [Outcomes: 5]
WP50-01 Software system specification [Outcomes: 3]
WP50-02 Software requirements specification [Outcomes: 3]
WP18-00 Standard [Outcomes: 7]

4.1.2.1.2 ACQ.2 Supplier Selection

Process ID ACQ.2
Process Name Supplier Selection
Process Purpose The purpose of the Supplier Selection process is to choose the organization that is to be
responsible for the delivery of the requirements of the project.
Process Outcomes As a result of successful implementation of the Supplier Selection process:
1) the supplier selection criteria are established and used to evaluate potential suppliers;
2) the supplier is selected based upon the evaluation of the supplier’s proposals, process
capabilities, and other factors; and
3) an agreement is established and negotiated between the customer and the supplier.
Base Practices ACQ.2.BP1: Evaluate stated or perceived supplier capability.
Evaluate stated or perceived supplier capability against the stated requirements,
according to the supplier selection criteria. [Outcomes: 1]
NOTE 1: See Acquisition Preparation process (ACQ.1) for definition of supplier
selection criteria.
NOTE A: The assessment of the supplier's continuous capability to furnish software
product and services of the type and quality level being procured may be
performed based on internationally recognised approaches such as those
based on ISO/IEC 155504 (e.g. this standard).
ACQ.2.BP2: Evaluate supplier’s proposal.
Evaluate supplier’s proposal against the stated requirements, according to the supplier
selection criteria. [Outcomes: 2]
ACQ.2.BP3: Prepare and negotiate agreement.
Negotiate a supplier agreement that clearly expresses the customer expectations and the
relative responsibilities of the supplier and customer. [Outcomes: 3]
NOTE B: All work necessary for completing the project is covered by a contract /
agreement.
NOTE C: The customer approves the supplier's Implementation Document (=
Supplier proposal response).
NOTE D: Although this is not normal practice in the space domain, in other domains
a preliminary agreement is established at this stage that is different from
the one referred to in ACQ.3.BP1.

Work Products
Input Work Products Output Work Products
WP09-04 Supplier selection policy [Outcomes: 2] WP02-01 Commitment / agreement [Outcomes: 1, 3]
WP12-01 Request for proposal [Outcomes: 2] WP08-02 Acquisition plan [Outcomes: 1]
WP12-04 Supplier proposal response [Outcomes: 3] WP09-04 Supplier selection policy [Outcomes: 1]
WP13-09 Meeting support record [Outcomes: 3] WP13-04 Communication record [Outcomes: 3]
WP15-13 Assessment / audit report [Outcomes: 2] WP13-05 Contract Review records [Outcomes: 3]
WP17-09 Product requirements [Outcomes: 2] WP13-09 Meeting support record [Outcomes: 3]
WP17-10 Service requirements [Outcomes: 2] WP13-19 Review records [Outcomes: 2]
WP18-08 Supplier selection criteria [Outcomes: 2] WP14-05 Preferred suppliers register [Outcomes: 2]
WP15-01 Analysis report [Outcomes: 2]
WP15-13 Assessment / audit report [Outcomes: 1]
WP15-21 Supplier evaluation report [Outcomes: 1, 2]
WP18-08 Supplier selection criteria [Outcomes: 1]

4.1.2.1.3 ACQ.3 Contract Agreement

Process ID ACQ.3
Process Name Contract Agreement
Process Purpose The purpose of the Contract Agreement process is to negotiate and approve a contract /
agreement that clearly and unambiguously specifies the expectations, responsibilities,
work products / deliverables and liabilities of both the supplier(s) and the acquirer.
Process Outcomes
As a result of successful implementation of the Contract Agreement process:
1) a contract or agreement is negotiated, reviewed, approved and awarded to the
supplier(s);
2) mechanisms for monitoring the capability and performance of the supplier(s) and for
mitigation of identified risks are reviewed and considered for inclusion in the
contract conditions; and
3) proposers / tenderers are notified of the result of proposal/tender selection.
Base Practices ACQ.3.BP1: Negotiate the contract/agreement.
Negotiate all relevant aspects of the contract/agreement with the supplier. [Outcomes: 1]
NOTE 1: Clarify intellectual right relationship. In the contract, address patent,
copyright, confidentiality, proprietary, usage, ownership, warranty and
licensing rights associated with the developed products and the reusable
off-the-shelf software products.

NOTE A: An aspect of negotiation is the level of control on work breakdown
structure.
NOTE B: Implementation Documents are often part of the contract.

NOTE C: Although this is not normal practice in the space domain, in other domains
a preliminary agreement is established after supplier selection (see
ACQ.2.BP3) that is different from the one referred to here.
ACQ.3.BP2: Approve contract.
The contract is approved by relevant stakeholders. [Outcomes: 1]
ACQ.3.BP3: Review contract for supplier capability monitoring.
Review and consider a mechanism for monitoring the capability and performance of the
supplier in the contract conditions [Outcomes: 2].
ACQ.3.BP4: Review contract for risk mitigation actions.
Review and consider a mechanism for the mitigation of identified risk in the contract
conditions. [Outcomes: 2]
ACQ.3.BP5: Award contract.
The contract is awarded to the successful proposer / tenderer [Outcomes: 1]
ACQ.3.BP6: Communicate results to tenderers.
Notify the results of the proposal/ tender selection to proposers/tenders. After contract
award inform all tenderers of the decision [Outcomes: 3].
Work Products
Input Work Products Output Work Products
WP08-19 Risk management plan [Outcomes: 2] WP02-00 Contract [Outcomes: 1]
WP12-01 Request for proposal [Outcomes: 1] WP02-01 Commitment / agreement [Outcomes: 1, 3]
WP12-04 Supplier proposal response [Outcomes: 1] WP13-04 Communication record [Outcomes: 1, 3]
WP15-18 Process performance report [Outcomes: 2] WP13-05 Contract Review records [Outcomes: 1]
WP17-09 Product requirements [Outcomes: 1] WP15-08 Risk analysis report [Outcomes: 2]
WP17-10 Service requirements [Outcomes: 1]
WP50-02 Software requirements specification
[Outcomes: 1]
WP50-11 Software development plan [Outcomes: 2]

4.1.2.1.4 ACQ.4 Supplier Monitoring

ACQ.4
Process ID
Supplier Monitoring
Process Name
The purpose of the Supplier Monitoring process is to track and assess performance of the
Process Purpose
supplier against agreed requirements.
Process Outcomes As a result of successful implementation of the Supplier Monitoring process:
1) joint activities between the customer and the supplier are performed as needed;
2) information on technical progress is exchanged regularly with the supplier;
3) performance of the supplier is monitored against the agreed requirements; and
4) agreement changes, if needed, are negotiated between the acquirer and the supplier
and documented in the agreement.
Base Practices ACQ.4. BP1: Establish and maintain communications.
Establish and maintain communications between customer and supplier (i.e. define
interfaces, schedule, messages, documents, meetings, joint review). [Outcomes: 1, 2]
ACQ.4.BP2: Exchange information on technical progress.
Use the communication link to exchange information on technical progress of the supply,
also covering costs and risks to successful completion. [Outcomes: 1, 2]
ACQ.4.BP3: Review development with supplier.
Review the aspects of the development (technical, quality, cost and schedule) on a
regular basis with the supplier, against the agreed requirements. [Outcomes: 3]
NOTE A: The customer should ensure the coherence of design, testing, verification,
and acceptance plans provided by multiple suppliers.
ACQ.4.BP4: Monitor the acquisition.
Monitor the acquisition against the agreed acquisition documentation so that progress can
be reviewed and audited to ensure that specified constraints such as cost, schedule, and
quality are met. [Outcomes: 3]
NOTE B: Examples of monitoring means include assessment and audits.

NOTE C: One specific aspect of monitoring is ensuring compliance with product
assurance requirements.
NOTE D: One specific aspect of monitoring is ensuring that subcontracted software
is correctly classified for dependability and safety criticality.
ACQ.4.BP5: Agree on changes.
Changes proposed by either party are negotiated and the results are documented in the
agreement. [Outcomes: 4]
NOTE E: This Base Practice is further detailed in the Contract Maintenance process
(ACQ.6).
Work Products
Input Work Products Output Work Products
WP02-00 Contract [Outcomes: 1] WP02-01 Commitment / agreement [Outcomes: 4]
WP02-01 Commitment / agreement [Outcomes: 3, 4] WP13-01 Acceptance record [Outcomes: 3]
WP12-04 Supplier proposal response [Outcomes: 1] WP13-04 Communication record [Outcomes: 1]
WP13-09 Meeting support record [Outcomes: 1] WP13-08 Installation record [Outcomes: 3]
WP13-14 Progress Status record [Outcomes: 2] WP13-09 Meeting support record [Outcomes: 1]
WP13-17 Customer request [Outcomes: 4] WP13-14 Progress status record [Outcomes: 2]
WP14-08 Tracking system [Outcomes: 3] WP13-17 Customer request [Outcomes: 3]
WP13-19 Review records [Outcomes: 2]
WP15-01 Analysis report [Outcomes: 3]

4.1.2.1.5 ACQ.5 Customer Acceptance

ACQ.5
Process ID
Customer Acceptance
Process Name
The purpose of the Customer Acceptance process it to approve the supplier's deliverable
Process Purpose
when all acceptance criteria are satisfied.
Process Outcomes As a result of successful implementation of the Customer Acceptance process:
1) the delivered software product and/or service are evaluated with regard to the
agreement;
2) the customer’s acceptance is based on the agreed acceptance criteria; and
3) the software product and/or service are accepted by the customer.
Base Practices ACQ.5.BP1: Define acceptance criteria.
Acceptance criteria are defined on the basis of agreed requirements. [Outcomes: 2]
NOTE A: E.g. ECSS-E-40 requires verification of the generation of software from
configured code.
NOTE 1: Refer to the Software Testing process (ENG.8) and the System Testing
process (ENG.10) to complete acceptance criteria with software/system
test definition and execution activities.
ACQ.5.BP2: Evaluate the delivered product.
Carry out the evaluation of the product and/or service using the defined acceptance
criteria. [Outcomes: 1, 2]
NOTE B: This evaluation includes the acceptance test reports.

ACQ.5.BP3: Compliance with agreement.
Resolve any acceptance issues in accordance with the procedures
established in the agreement and confirm that the delivered product or
service complies with the agreement. [Outcomes: 2]
ACQ.5.BP4: Accept product.
Accept the delivered product or service and communicate acceptance to the supplier.
[Outcomes: 3]
NOTE C: Purchased commercial software should be inspected at reception.

Work Products
Input Work Products Output Work Products
WP02-00 Contract [Outcomes: 1] WP13-01 Acceptance record [Outcomes: 3]
WP02-01 Commitment / agreement [Outcomes: 1] WP13-07 Problem report [Outcomes: 1]
WP08-01 Acceptance test plan [Outcomes: 1, 2] WP15-10 Test incident report [Outcomes: 2]
WP08-02 Acquisition plan [Outcomes: 1] WP18-01 Acceptance criteria [Outcomes: 2]
WP11-00 Product [Outcomes: 3]
WP12-04 Supplier proposal response [Outcomes: 1]
WP17-03 Customer requirements [Outcomes: 2]
WP50-01 Software system specification [Outcomes: 2]

4.1.2.1.6 ACQ.6 Contract Maintenance

ACQ.6
Process ID
Contract Maintenance
Process Name
The purpose of the Contract Maintenance process is to maintain and change the business
Process Purpose
agreements during the development process. Either the customer or the supplier may
propose contract modifications, while the complementary actor responds to the proposal.
Process Outcomes As a result of successful implementation of the Contract Maintenance process:
1) each business agreement is clearly identified and accomplished;
2) the need for a contract change is identified, with the reason and scope defined;
3) a contract change is proposed;
4) the impact of the change on all aspects of the product is assessed; and
5) the customer and supplier negotiate the contract modification reflecting the agreed
requirements.
Base Practices ACQ.6.BP1: Propose contract modifications.
Identify the need, scope and impact of modification of the original contract. [Outcomes:
1, 2, 3]
NOTE A: ECSS-M-40 requires that for an evolution requested by the customer, the
corresponding change proposal include the description of the change to
the requirement documents, when they are affected, derived from the
customer’s request and as a result from the changes of requirements

NOTE B: ECSS-M-40 requires that for an evolution proposed by a supplier, the
corresponding change proposal contains:
• The change descriptions related to the desired change
• Description of any modification to business agreement provisions (e.g.
cost, schedule, special clauses, data requirements, etc.)
ACQ.6.BP2: Respond to contract modification request.
Review the reason and scope and conduct an impact assessment on all products,
including contractual, technical, quality, dependability and safety aspects. [Outcomes: 4]
ACQ.6.BP3: Agree on contract modification.
Review reply to change request. Negotiate and incorporate changes into new contractual
agreement. [Outcomes: 5]
Work Products
Input Work Products Output Work Products
WP02-01 Commitment / agreement [Outcomes: 1, 5] WP02-01 Commitment / agreement [Outcomes: 5]
WP13-16 Change request [Outcomes: 3] WP13-16 Change request [Outcomes: 3]
WP17-00 Requirements specification [Outcomes: all] WP15-01 Analysis report [Outcomes: 4]
WP60-01 Request for waiver [Outcomes: 2, 3]

4.1.2.2 Supply process group (SPL)
4.1.2.2.1 SPL.1 Supplier Tendering

SPL.1
Process ID
Supplier Tendering
Process Name
The purpose of the Supplier Tendering process is to establish an interface to respond to
Process Purpose
the customer inquires and requests for proposal, prepare and submit proposals, and
confirm assignments through the establishing of a relevant agreement / contract.
As a result of successful implementation of the Supplier Tendering process:
Process Outcomes
1) a communication interface is established and maintained in order to respond to
customer inquires and requests for proposal;
2) requests for proposal are evaluated according to defined criteria to determine
whether or not to submit a proposal;
3) the need to undertake preliminary surveys of feasibility studies is determined;
4) suitable resources are identified to perform the proposed work;
5) a supplier proposal is prepared and submitted in response to the customer request;
and
6) formal confirmation of agreement is obtained.
Base Practices SPL.1.BP1: Establish communication interface.
A communication interface is established and maintained in order to respond to customer
inquires or requests for proposal. [Outcomes: 1].
SPL.1.BP2: Perform customer enquiry screening.
Perform customer enquiry screening to ensure source of lead is genuine, the nature of
type of product or service is clearly established, and the right person is quickly identified
to progress the lead. [Outcomes: 1]
SPL.1.BP3: Establish customer proposal evaluation criteria.
Establish evaluation criteria to determine whether or not to submit a proposal based on
appropriate criteria. [Outcomes: 2]
SPL.1.BP4: Evaluate customer request for proposal.
Requests for Proposal are evaluated according to appropriate criteria. [Outcome 2]
SPL.1.BP5: Determine need for preliminary evaluations or feasibility studies.
Determine need for preliminary evaluations or feasibility studies to ensure that a firm
quotation can be made based on available requirements. [Outcomes: 3]
SPL.1.BP6: Identify and nominate staff.
Identify and nominate staff with appropriate competency for the assignment.
[Outcomes: 4]
SPL.1.BP7: Perform preliminary overall estimation.
Estimate total costs, resources and needed delivery date. [Outcomes: 4]
SPL.1.BP8: Prepare supplier proposal or tender response.
A supplier proposal or tender is prepared in response to the customer request.
[Outcomes: 5]
NOTE 1: This may involve the selection of an appropriate solution (organisational or
technical) amongst several alternatives in order to best meet requirements.

NOTE A: ECSS-M-10 requires the supplier to produce, based on customer inputs:
• Function tree
• Product tre
...