Space engineering - System engineering general requirements

This standard specifies the system engineering implementation requirements for space systems and space products development.
Specific objectives of this standard are:
•   to implement the system engineering requirements to ensure a firm technical basis and to minimize technical risk and cost for space systems and space products development;
•   to specify the essential system engineering tasks, their objectives and outputs;
•   to implement integration and control of engineering disciplines and lower level system engineering work;
•   to implement the “customer-system-supplier model” through the development of systems and products for space applications.
This Standard is intended to apply to all space systems and product, at any level of the system decomposition, including hardware, software, procedures, man-in-the-loop, facilities and services. Through the document and its annexes the requirements however apply as they are to complex systems only; for lower level elements tailoring is necessary.
Specific requirements related to system engineering, like technical specification, verification, and testing are specified in dedicated documents and standards within the set of ECSS system engineering standards ECSS-E-ST-10-XX.
Discipline or element specific engineering implementation requirements are covered in dedicated ECSS standards. 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.
ECSS-E-HB-10 “System engineering guidelines” contains guidelines related to this standard, including a description of the reference system engineering process for a space system and its products.
NOTE 1   The term “Discipline” is defined in ECSS-M-ST-10, as “a specific area of expertise within a general subject”. The name of the discipline normally indicates the type of expertise, e.g. in the ECSS system mechanical engineering, software and communications are disciplines within the engineering domain.
NOTE 2   The requirements on the system engineering process are gathered in this standard; specific aspects of the SE process are further elaborated in dedicated standards.
This standard may be tailored for the specific characteristic and constrains of a space project in conformance with ECSS-S-ST-00.

Raumfahrttechnik - Grundsätze und Verfahrensweise

Ingénierie spatiale - Exigences générales d'ingénierie système

La présente Norme expose les exigences de mise en oeuvre de l’ingénierie système pour le développement des systèmes et des produits spatiaux.
Les objectifs précis de la présente Norme sont les suivants :
-   appliquer les exigences d’ingénierie système pour créer une base technique solide et minimiser les coûts et les risques techniques pour le développement des systèmes et des produits spatiaux ;
-   définir les principales tâches d’ingénierie système, leurs objectifs et leurs résultats ;
-   mettre en oeuvre l’intégration et le contrôle des disciplines d’ingénierie, ainsi que les travaux d’ingénierie système de niveau inférieur ;
-   mettre en oeuvre le « modèle client-système-fournisseur » à travers le développement de systèmes et de produits pour les applications spatiales.
En fonction de la catégorie de produit, il faut vérifier si la présente norme doit être appliquée et si besoin adaptée. Le tableau de préadaptation de l’article 7 présente l’applicabilité des exigences du présent document et de ses annexes selon le type de produit. Les exigences spécifiques relatives à l’ingénierie système, telles que les spécifications techniques, la vérification et les essais, sont spécifiées dans des documents et normes dédiés de la série ECSS-E-ST-10-XX, relative à l’ingénierie système de l’ECSS.
Les exigences de mise en oeuvre de l’ingénierie propres à chaque discipline ou à chaque élément sont décrites dans les normes ECSS associées. Ces normes se fondent sur les mêmes principes, les mêmes processus et le même modèle de documentation. L’applicabilité de chacune de ces normes ne peut donc être envisagée de manière indépendante.
NOTE 1   Le terme « Discipline » est défini dans l’ECSS-M-ST-10 comme étant une « spécialité entrant dans le cadre d’un sujet général ». Le nom de la discipline indique généralement le type d’expertise auquel elle est associée ; par exemple, dans le système ECSS, l’ingénierie mécanique, les logiciels et les communications sont des disciplines du domaine de l’ingénierie.
NOTE 2   Les exigences relatives au processus d’ingénierie système sont réunies dans cette norme ; les aspects spécifiques au processus d’ES sont décrits de façon plus détaillée dans des normes dédiées.
En matière de processus d’ingénierie relatif aux logiciels ainsi qu’au segment sol et aux opérations, les normes suivantes sont considérées comme étant amplement suffisantes pour le développement de ces articles :
-   ECSS-E-ST-70 Ingénierie spatiale - Systèmes sol et opérations
-   ECSS-E-ST-40 Ingénierie spatiale - Logiciels
-   ECSS-Q-ST-80 Assurance produit des projets spatiaux - Assurance produit logiciel
La présente Norme peut être adaptée aux caractéristiques et contraintes spécifiques d’un projet spatial, conformément à l’ECSS-S-ST-00.

Vesoljska tehnika - Sistemskotehnične splošne zahteve

Ta standard določa zahteve za izvajanje sistemskega inženiringa za vesoljske sisteme in razvoj vesoljskih izdelkov. Namen tega standarda je zlasti: • izvajanje zahtev za sistemski inženiring z namenom zagotavljanja trdne tehnične podlage in zmanjševanja tehničnih tveganj in stroškov vesoljskih sistemov ter razvoja vesoljskih izdelkov; • določanje bistvenih nalog sistemskega inženiringa ter njihovih ciljev in rezultatov; • izvajanje povezovanja in nadzora nad različnimi inženirskimi disciplinami in dela v zvezi s sistemskim inženiringom na nižji ravni; • izvajanje »modela odjemalec-sistem-dobavitelj« s pomočjo razvoja sistemov in izdelkov za vesoljske aplikacije. Ta standard je namenjen za uporabo pri vseh vesoljskih sistemih in izdelkih, na kateri koli ravni razstavljanja sistema, vključno s strojno opremo, programsko opremo, postopki, modeli z vključitvijo človeka, objekti in storitvami. V celotnem dokumentu in njegovih dodatkih zahteve kot take veljajo samo za kompleksne sisteme; za elemente nižje ravni je potrebna prilagoditev. Posebne zahteve v zvezi s sistemskim inženiringom, kot so tehnične specifikacije, preverjanje in preskušanje, določajo namenski dokumenti in standardi v sklopu standardov ECSS za sistemski inženiring ECSS-E-ST-10-XX. Zahteve za izvajanje inženiringa, vezanega na discipline ali elemente, so zajete namenskih standardih ECSS. Navedeni standardi temeljijo na enakih načelih, procesu in modelu dokumentiranja. Zato uporabnosti posameznega standarda ni mogoče presojati ločeno od ostalih standardov. Dokument ECSS-E-HB-10 »Smernice za sistemski inženiring« vsebuje smernice, ki se navezujejo na ta standard, vključno z opisom postopka inženiringa za vesoljski sistem in njegove izdelke. OPOMBA 1: izraz »disciplina« je v standardu ECSS-M-ST-10 opredeljen kot »določeno strokovno področje v okviru splošne tematike«. Iz imena discipline je običajno razvidna vrsta strokovnega znanja, npr. v okviru mehanskega inženiringa sistema ECSS sta programska oprema in komunikacije disciplini s področja inženiringa. OPOMBA 2: v tem standardu so zajete zahteve za postopek sistemskega inženiringa; posebni vidiki postopka sistemskega inženiringa so natančneje določeni v namenskih standardih.  Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS-S-ST-00.

General Information

Status
Published
Public Enquiry End Date
30-Nov-2016
Publication Date
10-May-2018
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
07-May-2018
Due Date
12-Jul-2018
Completion Date
11-May-2018

Relations

Buy Standard

Standard
EN 16603-10:2018 - BARVE
English language
115 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Draft
k FprEN 16603-10:2016
English language
112 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST EN 16603-10:2018
01-julij-2018
1DGRPHãþD
SIST EN 13292:2000
SIST EN 14514:2005
SIST EN 14607-7:2005
9HVROMVNDWHKQLND6LVWHPVNRWHKQLþQHVSORãQH]DKWHYH
Space engineering - System engineering general requirements
Raumfahrttechnik - Grundsätze und Verfahrensweise
Ta slovenski standard je istoveten z: EN 16603-10:2018
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
SIST EN 16603-10:2018 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST EN 16603-10:2018

---------------------- Page: 2 ----------------------

SIST EN 16603-10:2018


EUROPEAN STANDARD
EN 16603-10

NORME EUROPÉENNE

EUROPÄISCHE NORM
April 2018
ICS 49.140
Supersedes EN 13292:1999, EN 14514:2004, EN
14607-7:2004
English version

Space engineering - System engineering general
requirements
Ingénierie spatiale - Exigences générales d'ingénierie Raumfahrttechnik - Grundsätze und Verfahrensweise
système
This European Standard was approved by CEN on 21 August 2017.

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:2018 E
reserved worldwide for CEN national Members and for
CENELEC Members.

---------------------- Page: 3 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
Table of contents
European Foreword . 5
1 Scope . 7
2 Normative references . 9
3 Terms, definitions and abbreviated terms . 10
3.1 Terms from other standards . 10
3.2 Terms specific to the present standard . 10
3.3 Abbreviated terms. 11
4 Overview of system engineering . 14
4.1 The system engineering discipline . 14
4.2 The system engineering process . 18
4.3 Overview of system engineering tasks per project phase. 19
4.3.1 Overview . 19
4.3.2 General . 19
4.3.3 Phase 0 Overview: Mission analysis-need identification . 20
4.3.4 Phase A Overview: Feasibility . 20
4.3.5 Phase B Overview: Preliminary definition . 20
4.3.6 Phase C Overview: Detailed definition . 21
4.3.7 Phase D Overview : Qualification and production . 21
4.3.8 Phase E Overview: Operations / utilization . 21
4.3.9 Phase F Overview: Disposal . 21
5 General requirements. 23
5.1 System engineering plan . 23
5.2 Requirement engineering . 24
5.2.1 General . 24
5.2.2 Requirement traceability. 24
5.2.3 Requirement engineering process . 25
5.3 Analysis . 27
5.3.1 System analysis . 27
5.3.2 System environments and design and test factors . 28
2

---------------------- Page: 4 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
5.3.3 Trade-off analyses . 28
5.3.4 Analysis methods, tools and models . 29
5.4 Design and configuration . 30
5.4.1 Design . 30
5.4.2 Configuration . 31
5.5 Verification . 32
5.5.1 General . 32
5.5.2 Product verification. 32
5.6 System engineering integration and control . 33
5.6.1 Management of system engineering activities . 33
5.6.2 Planning . 33
5.6.3 Engineering data . 33
5.6.4 Interface control . 34
5.6.5 Coordinate systems and units . 34
5.6.6 Technical budgets and margin policy . 34
5.6.7 Technology . 34
5.6.8 Risk management . 35
5.6.9 Changes and nonconformances control . 35
6 <> . 36
7 Pre-tailoring matrix per space product types . 37
Annex A (informative) System engineering documents delivery per review . 51
Annex B (normative) Mission description document (MDD) – DRD . 55
Annex C (normative) System concept report – DRD . 59
Annex D (normative) System engineering plan (SEP) – DRD . 60
Annex E (normative) Technology plan (TP) – DRD . 69
Annex F (normative) Technology matrix - DRD . 73
Annex G (normative) Design definition file (DDF) - DRD . 75
Annex H (normative) Function tree - DRD . 80
Annex I (normative) Technical budget - DRD . 82
Annex J (normative) Specification tree - DRD . 84
Annex K (normative) Design justification file (DJF) - DRD . 86
Annex L (normative) Trade-off report - DRD . 93
3

---------------------- Page: 5 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
Annex M (normative) <> . 96
Annex N (normative) Requirements traceability matrix (RTM) - DRD . 97
Annex O (normative) Requirements justification file (RJF) - DRD . 99
Annex P (normative) Product user manual (PUM or UM) - DRD . 102
Annex Q <> . 110
Annex R (informative) Mapping of typical DDP to ECSS documents . 111
Annex S (informative) Guideline content of Analysis Report . 113
Bibliography . 115

Figures
Figure 4-1: System engineering, sub-functions and boundaries . 16
Figure 4-2: System engineering sub-functions inter-relationships . 17

Figure B-1 : Relationship between documents . 56
Figure E-1 : TRSL template . 72

Tables
Table A-1 : System engineering deliverable documents . 52


4

---------------------- Page: 6 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
European Foreword
This document (EN 16603-10:2018) has been prepared by Technical Committee CEN-CENELEC/JTC 5
“Space”, the secretariat of which is held by DIN.
This standard (EN 16603-10:2018) originates from ECSS-E-ST-10C 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 October 2018, and conflicting national standards shall
be withdrawn at the latest by October 2018.
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 13292:1999, EN 14514:2004 and EN 14607-7:2004.
The main changes with respect to EN 13292:1999, EN 14514:2004 and EN 14607-7:2004 are:
• The main driver for the changes in this issue of the standard comes from the intention to include in
this document only requirements and remove all informative material related to the process for
inclusion in a future handbook.
• Inclusion of EN 16603-11 (ECSS-E-AS-11) "Adoption Notice of ISO 16290, Space systems -
Definition of the Technology Readiness Levels (TRLs) and their criteria of assessment" as
Normative Reference.
• Former clause 5 “System engineering process”, replaced by a brief overview of the project phases
and related system engineering tasks in the current clause 4.3 “Overview of system engineering
tasks per project phase”.
• Former Clause 4 split into an introductory clause 4 “Overview of Systems engineering” and clause
5 “General Requirements”.
• Clause 7 "Pre-tailoring matrix per space product types" added
• The remaining requ irements have been reworded for readability and consistency. Repetition of
requirements included in other related standards have been eliminated.
• Regarding the documentation model, the only significant modification originates in the
simplification of the concept of Functional Specification and Technical Specification. In EN 16603-
10-06 only one specification, the technical requirements specification (customer specification), is
considered. This is reflected in this standard, as explained in clause 5.2.3.1
• Annex A: System engineering documents delivery per review: This annex replaces and expands
old Annex B. It includes the listing of the main documents per phase of the project development
indicating when the document needs to be available.
• Document Requirements Descriptions (DRD) added in several Annexes that include all the project
documents pertinent to this standard. In the previous issue the DRDs were not included.
5

---------------------- Page: 7 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
• Annex R: Mapping of typical DDP to ECSS documents: This is an addition with respect to the
previous issue. It presents where specific subjects contained in the previously used Design and
Development Plan are located in the new set of ECSS documents.
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 organisations 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.
6

---------------------- Page: 8 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
1
Scope
This standard specifies the system engineering implementation requirements
for space systems and space products development.
Specific objectives of this standard are:
• to implement the system engineering requirements to establish a firm
technical basis and to minimize technical risk and cost for space systems
and space products development;
• to specify the essential system engineering tasks, their objectives and
outputs;
• to implement integration and control of engineering disciplines and
lower level system engineering work;
• to implement the “customer-system-supplier model” through the
development of systems and products for space applications.
Depending of the product category, the application of this standard needs to be
checked and if needed tailored. The pre-tailoring table in clause 7 contains the
applicability of the requirements of this document and its annexes according to
product type. Specific requirements related to system engineering, like technical
specification, verification, and testing are specified in dedicated documents and
standards within the set of ECSS system engineering standards ECSS-E-ST-10-XX.
Discipline or element specific engineering implementation requirements are
covered in dedicated ECSS standards. 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.
NOTE 1 The term “Discipline” is defined in ECSS-M-ST-10, as “a
specific area of expertise within a general subject”. The
name of the discipline normally indicates the type of
expertise, e.g. in the ECSS system mechanical
engineering, software and communications are
disciplines within the engineering domain.
NOTE 2 The requirements on the system engineering process are
gathered in this standard; specific aspects of the SE
process are further elaborated in dedicated standards.
For engineering process both for SW and for Ground Segment and Operations
the following standards are considered fully sufficient for development of these
items:
• ECSS-E-ST-70 Space engineering - Ground systems and operations
• ECSS-E-ST-40 Space engineering - Software
7

---------------------- Page: 9 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
• ECSS-Q-ST-80 Space product assurance - Software product assurance
This standard may be tailored for the specific characteristic and constrains of a
space project in conformance with ECSS-S-ST-00.
8

---------------------- Page: 10 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
2
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-11 ECSS-E-AS-11 Adoption Notice of ISO 16290, Space systems - Definition
of the Technology Readiness Levels (TRLs) and their
criteria of assessment
EN 16603-10-02 ECSS-E-ST-10-02 Space engineering – Verification
EN 16603-10-06 ECSS-E-ST-10-06 Space engineering – Technical requirements specification
EN 16603-10-09 ECSS-E-ST-10-09 Space engineering – Reference coordinate system
EN 16603-10-24 ECSS-E-ST-10-24 Space engineering – Interface control
EN 16601-10 ECSS-M-ST-10 Space project management – Project planning and
implementation
EN 16601-40 ECSS-M-ST-40 Space project management – Configuration and
information management
EN 16602-10 ECSS-Q-ST-10 Space product assurance - Product assurance
management
EN 16602-10-09 ECSS-Q-ST-10-09 Space product assurance - Nonconformance control
system
EN 16602-20-10 ECSS-Q-ST-20-10 Off-the-shelf items utilization in space systems

9

---------------------- Page: 11 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
3
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. approval
3. configuration baseline
4. critical
5. development
6. equipment
7. inspection
8. integration
9. mission statement
10. product tree
11. requirement
12. specification
13. subsystem
14. system
15. test
16. verification
b. For the purpose of this Standard, the terms and definitions from ECSS-E-
AS-11 apply, in particular for the following terms:
1. technology readiness level
3.2 Terms specific to the present standard
3.2.1 requirement traceability
requirement attribute that links each single requirement to its higher level
requirements inside the requirement set
10

---------------------- Page: 12 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
1 to entry: This enables the derivation of a requirement
tree, which demonstrates the coherent flow-down of the
requirements.
3.2.2 recurring product
product which conforms to a qualified design and is produced according to the
corresponding production master file
3.2.3 system engineering
interdisciplinary approach governing the total technical effort required to
transform requirements into a system solution
1 to entry: From IEEE P1220.
3.2.4 verification matrix
initial issue of the VCD which contains for each requirement to be verified the
methods, levels and stages of product verification
1 to entry: See ECSS-E-ST-10-02 for a more detailed
definition of the VCD.
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:

Abbreviation Meaning
assembly, integration and test
AIT
assembly, integration and verification plan
AIV plan
attitude and orbit control sub-system
AOCS
acceptance review
AR
critical design review
CDR
commercial off-the-shelf
COTS
commissioning results review
CRR
NOTE For space vehicles (e.g. launcher, transfer vehicle,
crew transport vehicle) the CRR can be replaced or
complemented by a flight qualification review
(FQR).
design definition file
DDF
design development plan
DDP
design justification file
DJF
document requirements definition
DRD
European Cooperation for Space Standardization
ECSS
end-of-life review
ELR
failure, detection, isolation, recovery
FDIR
11

---------------------- Page: 13 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
Abbreviation Meaning
flight model
FM
failure modes, effects, and criticality analysis
FMECA
flight operations manual
FOM
flight readiness review
FRR
fault tree analysis
FTA
ground support equipment
GSE
human-in-the-loop
HITL
interface control document
ICD
integrated logistic support
ILS
interface requirement document
IRD
launch readiness review
LRR
mission closed-out review
MCR
mission description document
MDD
mission definition review
MDR
mission operations plan
MOP
mission statement
MS
operational readiness review
ORR
preliminary design review
PDR
project management plan
PMP
parts materials and processes
PM&P
preliminary requirement review
PRR
product user manual
PUM
qualification review
QR
reliability, availability, maintainability, safety
RAMS
risk assessment report
RAR
radio frequency
RF
requirement justification file
RJF
review of design
ROD
read only memory / random access memory
ROM/RAM
requirement traceability matrix
RTM
research and development
R&D
system engineering
SE
system engineering plan
SEP
system functional test
SFT
system requirement review
SRR
system validation test
SVT
12

---------------------- Page: 14 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
Abbreviation Meaning
technology plan
TP
technology readiness assessment
TRA
technology readiness level
TRL
technology readiness status list
TRSL
technical requirements specification
TS
user manual
UM
verification control document
VCD
verification plan
VP
with respect to
w.r.t.

13

---------------------- Page: 15 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
4
Overview of system engineering
4.1 The system engineering discipline
System engineering is an interdisciplinary approach governing the total
technical effort to transform requirements into a system solution.
A system is an integrated set of elements to accomplish a defined objective.
These elements include hardware, software, firmware, human resources,
information, techniques, facilities services, and other support elements.
In this standard the concept of “system” is used in a wide sense. The highest
level, often called “mission level” or “space system”, consists usually of one (or
more) space segment(s), of a ground segment, and of a user segment. Elements
of system decomposition are also considered a system. For the purpose of this
standard the system can be any element at any level of decomposition as
defined by the function tree (see Annex H) or the product tree (see ECSS-M-ST-
10 Annex B). The scope of an element can include hardware, software,
procedures, man-in-the-loop, facilities and services.
From the perspective of the considered system, requirements originate from the
next upper level (the customer) and elements are procured from the next lower
level (the suppliers).
NOTE 1 The customer-supplier model is described in
ECSS-S-ST-00.
NOTE 2 Through this standard the notion of customer
refers to several actors ,in relation to the project
phase. In fact a customer can be e.g. a scientific
community in phase 0, a commercial user in
phase A or an Agency in phase B. A supplier can
on the other hand be an Agency in both phase 0
and phase A.
Figure 4-1 shows the boundaries of system engineering (for which the indicated
interactions between the identified major disciplines is not exhaustive but
indicative), its relationship with production, operations, product assurance and
management disciplines (and their cross-interaction is indicated as “interface
areas” in the figure) and its internal partition into the following system
engineering sub-functions:
• requirement engineering, which consist on requirement analysis and
validation, requirement allocation, and requirement maintenance;
• analysis, which is performed for the purpose of resolving requirements
conflicts, decomposing and allocating requirements during functional
14

---------------------- Page: 16 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
analysis, assessing system effectiveness (including analysing risk factors);
and complementing testing evaluation and providing trade studies for
assessing effectiveness, risk, cost and planning;
• design and configuration which results in a physical architecture, and its
complete system functional, physical and software characteristics;
• verification, which objective is to demonstrate that the deliverables
conform to the specified requirements, including qualification and
acceptance;
• system engineering integration and control, coordinating the various
engineering disciplines and participants throughout all the project
phases.
Figure 4-2 shows system engineering sub-functions, their inter-relationships
and their main activities during the system engineering process.
System engineering sub-functions are applied in an iterative mode during
implementation of the system engineering process described in clause 4.2.
Within the frame of a project, the system engineering function is generally
implemented by a system engineering organisation of the supplier which is in
charge of transforming the requirements of the customer into a system solution
delivered by the supplier. For the purpose of this standard, the ‘system
engineering function’ only is referred to in the normative statements,
independent of whether the supplier has a formal ‘system engineering
organisation’ or not.
NOTE With respect to the next lower level, the
supplier plays the role of the customer.
15

---------------------- Page: 17 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)


Figure 4-1: System engineering, sub-functions and boundaries
16
Management
- Cost
- Planning
- Configuration control
- Procurement
- Information
- Documentation
- Schedule
SYSTEM ENGINEERING INTEGRATION AND CONTROL
- Product
 assurance
- Dependability
- Verification
ANALYSIS
- Procurement
- Development
- Criticality
- AIT
 analysis
REQUIREMENTS
DESIGN AND
- PM&P
ENGINEERING
CONFIGURATION
- Safety
- EEE component
- SW PA
VERIFICATION & VALIDATION
SYSTEM
ENGINEERING
- Operations Engineering
- Operations Verification
- Logistic Analysis
Production
Product
Assurance
Operations and Logistics
= Interface Area
= System Engineering Scope = Other Programme Disciplines
AIT = assembly, integration and test   SW PA = Software Product Assurance
PM&P = parts, materials and processes

---------------------- Page: 18 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
Plans and Data
Plans and Data
Plans and Data

Figure 4-2: System engineering sub-functions inter-relationships

17
System Engineering Data Base
Technical Plans
System Engineering Tools and Models
Integration and Control
System Analysis
System Analysis
System Analysis
Analysis
Requirement Functional Analysis Design and
Engineering and allocation configuration
Customer input
Requirement Engineering
Design and configuration
Functional Product Qualified product design
Requirements
Verification Verification
Verification
Verification

---------------------- Page: 19 ----------------------

SIST EN 16603-10:2018
EN 16603-10:2018 (E)
4.2 The system engineering process
The system engineering activities of a project are conducted by an entity or
resources within the project team of a supplier. This entity or the resources that
perform this function is called in this document “system engineering function”.
The system engineering process is in turn applied by each system engineering
function of each supplier of the elements of the product decomposition.
The system engineering process consists of activities to be performed by the
system engineering function within each project phase according to the
designated lifecycle model. The objective is to obtain a product which satisfies
the customer technical requirements within pre-e
...

SLOVENSKI STANDARD
kSIST FprEN 16603-10:2016
01-oktober-2016
9HVROMVNDWHKQLND6LVWHPVNRWHKQLþQHVSORãQH]DKWHYH
Space engineering - System engineering general requirements
Raumfahrttechnik - Grundsätze und Verfahrensweise
Ta slovenski standard je istoveten z: FprEN 16603-10
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
kSIST FprEN 16603-10:2016 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
kSIST FprEN 16603-10:2016

---------------------- Page: 2 ----------------------
kSIST FprEN 16603-10:2016


EUROPEAN STANDARD
FINAL DRAFT
FprEN 16603-10
NORME EUROPÉENNE

EUROPÄISCHE NORM

July 2016
ICS 49.140
Will supersede EN 13292:1999, EN 14514:2004, EN
14607-7:2004
English version

Space engineering - System engineering general
requirements
 Raumfahrttechnik - Grundsätze und Verfahrensweise
This draft European Standard is submitted to CEN members for unique acceptance procedure. It has been drawn up by the
Technical Committee CEN/CLC/TC 5.

If this draft becomes a European Standard, 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.

This draft European Standard was established by CEN and CENELEC 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,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.















CEN-CENELEC Management Centre:
Avenue Marnix 17, B-1000 Brussels
© 2016 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. FprEN 16603-10:2016 E
reserved worldwide for CEN national Members and for
CENELEC Members.

---------------------- Page: 3 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
Table of contents
Foreword . 5
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
4 Overview of system engineering . 12
4.1 The system engineering discipline . 12
4.2 The system engineering process . 16
4.3 Overview of system engineering tasks per project phase. 17
4.3.1 Overview . 17
4.3.2 General . 17
4.3.3 Phase 0 Overview: Mission analysis-need identification . 17
4.3.4 Phase A Overview: Feasibility . 18
4.3.5 Phase B Overview: Preliminary definition . 18
4.3.6 Phase C Overview: Detailed definition . 18
4.3.7 Phase D Overview : Qualification and production . 19
4.3.8 Phase E Overview: Operations / utilization . 19
4.3.9 Phase F Overview: Disposal . 19
5 General requirements. 20
5.1 System engineering plan . 20
5.2 Requirement engineering . 21
5.2.1 General . 21
5.2.2 Requirement traceability. 21
5.2.3 Requirement engineering process . 22
5.3 Analysis . 24
5.3.1 System analysis . 24
5.3.2 System environments and design and test factors . 25
2

---------------------- Page: 4 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
5.3.3 Trade-off analyses . 25
5.3.4 Analysis methods, tools and models . 26
5.4 Design and configuration . 27
5.4.1 Design . 27
5.4.2 Configuration . 28
5.5 Verification . 29
5.5.1 General . 29
5.5.2 Product verification. 29
5.6 System engineering integration and control . 30
5.6.1 Management of system engineering activities . 30
5.6.2 Planning . 30
5.6.3 Engineering data . 30
5.6.4 Interface control . 31
5.6.5 Coordinate systems and units . 31
5.6.6 Technical budgets and margin policy . 31
5.6.7 Technology . 31
5.6.8 Risk management . 32
5.6.9 Changes and nonconformances control . 32
6 Overview of system engineering tasks per project phase . 33
6.1 Overview . 33
6.2 General . 33
6.3 Phase 0: Mission analysis-need identification . 33
6.4 Phase A: Feasibility . 33
6.5 Phase B: Preliminary definition . 33
6.6 Phase C: Detailed definition . 34
6.7 Phase D: Qualification and production . 34
6.8 Phase E: Operations / utilization . 34
6.9 Phase F: Disposal. 34
7 Pre-tailoring matrix per space product types . 35
Annex A (informative) System engineering documents delivery per review . 49
Annex B (normative) Mission description document (MDD) – DRD . 53
Annex C (normative) System concept report – DRD . 57
Annex D (normative) System engineering plan (SEP) – DRD . 58
Annex E (normative) Technology plan (TP) – DRD . 67
3

---------------------- Page: 5 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
Annex F (normative) Technology matrix - DRD . 71
Annex G (normative) Design definition file (DDF) - DRD . 73
Annex H (normative) Function tree - DRD . 78
Annex I (normative) Technical budget - DRD . 80
Annex J (normative) Specification tree - DRD . 82
Annex K (normative) Design justification file (DJF) - DRD . 84
Annex L (normative) Trade-off report - DRD . 91
Annex M (normative) <> . 94
Annex N (normative) Requirements traceability matrix (RTM) - DRD . 95
Annex O (normative) Requirements justification file (RJF) - DRD . 97
Annex P (normative) Product user manual (PUM or UM) - DRD . 100
Annex Q (informative) Guideline content of Analysis Report . 108
Annex R (informative) Mapping of typical DDP to ECSS documents . 110
Bibliography . 112

Figures
Figure 4-1: System engineering, sub-functions and boundaries . 14
Figure 4-2: System engineering sub-functions inter-relationships . 15
Figure B-1 : Relationship between documents . 54
Figure E-1 : TRSL template . 70

Tables
Table A-1 : System engineering deliverable documents . 50


4

---------------------- Page: 6 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
Foreword
This document (FprEN 16603-10:2016) has been prepared by Technical Committee CEN/CLC/TC 5
“Space”, the secretariat of which is held by DIN (Germany).
This document (FprEN 16603-10:2016) originates from ECSS-E-ST-10C Rev.1 DIR1.
This document is currently submitted to the UAP.
This document will supersede EN 13292:1999, EN 14514:2004 and EN 14607-7:2004.
This document has been developed to cover specifically space systems and will the-refore have
precedence over any EN covering the same scope but with a wider do-main of applicability (e.g.:
aerospace).
5

---------------------- Page: 7 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
1
Scope
This standard specifies the system engineering implementation requirements
for space systems and space products development.
Specific objectives of this standard are:
• to implement the system engineering requirements to establish a firm
technical basis and to minimize technical risk and cost for space systems
and space products development;
• to specify the essential system engineering tasks, their objectives and
outputs;
• to implement integration and control of engineering disciplines and
lower level system engineering work;
• to implement the “customer-system-supplier model” through the
development of systems and products for space applications.
Generally, System Engineering is a discipline that can find beneficial application
to the development and production of a wide variety of systems and throughout
the product decomposition hierarchy. However the requirements in this Standard
were developed to be appropriate for application as they are to complex space
systems and products only; for lower level elements tailoring is necessary. The
pre-tailoring table in Section 7 contains the applicability of the requirements of
this document and its annexes according to product type.Specific requirements
related to system engineering, like technical specification, verification, and testing
are specified in dedicated documents and standards within the set of ECSS
system engineering standards ECSS-E-ST-10-XX.
Discipline or element specific engineering implementation requirements are
covered in dedicated ECSS standards. 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.
NOTE 1 The term “Discipline” is defined in ECSS-M-ST-10, as “a
specific area of expertise within a general subject”. The
name of the discipline normally indicates the type of
expertise, e.g. in the ECSS system mechanical
engineering, software and communications are
disciplines within the engineering domain.
NOTE 2 The requirements on the system engineering process are
gathered in this standard; specific aspects of the SE
process are further elaborated in dedicated standards.
This standard may be tailored for the specific characteristic and constrains of a
space project in conformance with ECSS-S-ST-00.
6

---------------------- Page: 8 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
2
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-11 ECSS-E-AS-11 Adoption Notice of ISO 16290, Space systems - Definition
of the Technology Readiness Levels (TRLs) and their
criteria of assessment
EN 16603-10-02 ECSS-E-ST-10-02 Space engineering – Verification
EN 16603-10-06 ECSS-E-ST-10-06 Space engineering – Technical requirements specification
EN 16603-10-09 ECSS-E-ST-10-09 Space engineering – Reference coordinate system
EN 16603-10-24 ECSS-E-ST-10-24 Space engineering – Interface control
EN 16601-10 ECSS-M-ST-10 Space project management – Project planning and
implementation
EN 16601-40 ECSS-M-ST-40 Space project management – Configuration and
information management
EN 16602-20-10 ECSS-Q-ST-20-10 Off-the-shelf items utilization in space systems

7

---------------------- Page: 9 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
3
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. approval
3. configuration baseline
4. critical
5. development
6. equipment
7. inspection
8. integration
9. product tree
10. requirement
11. specification
12. subsystem
13. system
14. test
15. verification
b. For the purpose of this Standard, the terms and definitions from ECSS-E-
AS-11C apply, in particular for the following terms:
1. technology readiness level
3.2 Terms specific to the present standard
3.2.1 requirement traceability
requirement attribute that links each single requirement to its higher level
requirements inside the requirement set
8

---------------------- Page: 10 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
Note 1 to entry: This enables the derivation of a
requirement tree, which demonstrates the coherent flow-
down of the requirements.
3.2.2 recurring product
product which conforms to a qualified design and is produced according to the
corresponding production master file
3.2.3 system engineering
interdisciplinary approach governing the total technical effort required to
transform a requirement into a system solution
Note 1 to entry: From IEEE P1220.
3.2.4 verification matrix
initial issue of the VCD which contains for each requirement to be verified the
methods, levels and stages of product verification
Note 1 to entry: See ECSS-E-ST-10-02 for a more
detailed definition of the VCD.
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:

Abbreviation Meaning
assembly, integration and test
AIT
assembly, integration and verification plan
AIV plan
attitude and orbit control sub-system
AOCS
acceptance review
AR
critical design review
CDR
commercial off-the-shelf
COTS
commissioning results review
CRR
NOTE For space vehicles (e.g. launcher, transfer vehicle,
crew transport vehicle) the CRR can be replaced or
complemented by a flight qualification review
(FQR).
design definition file
DDF
design development plan
DDP
design justification file
DJF
document requirements definition
DRD
European Cooperation for Space Standardization
ECSS
end-of-life review
ELR
9

---------------------- Page: 11 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
failure, detection, isolation, recovery
FDIR
flight model
FM
failure modes, effects, and criticality analysis
FMECA
flight readiness review
FRR
fault tree analysis
FTA
ground support equipment
GSE
interface control document
ICD
integrated logistic support
ILS
interface requirement document
IRD
launch readiness review
LRR
mission closed-out review
MCR
mission description document
MDD
mission definition review
MDR
mission operations plan
MOP
mission statement
MS
operational readiness review
ORR
preliminary design review
PDR
project management plan
PMP
preliminary requirement review
PRR
product user manual
PUM
qualification review
QR
reliability, availability, maintainability, safety
RAMS
radio frequency
RF
requirement justification file
RJF
review of design
ROD
read only memory / random access memory
ROM/RAM
requirement traceability matrix
RTM
research and development
R&D
system engineering
SE
system engineering plan
SEP
system functional test
SFT
system requirement review
SRR
system validation test
SVT
technology plan
TP
technology readiness level
TRL
technical requirements specification
TS
user manual
UM
10

---------------------- Page: 12 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
verification control document
VCD
verification plan
VP
with respect to
w.r.t.

11

---------------------- Page: 13 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
4
Overview of system engineering
4.1 The system engineering discipline
System engineering is defined as an interdisciplinary approach governing the
total technical effort to transform requirements into a system solution.
A system is defined as an integrated set of elements to accomplish a defined
objective. These elements include hardware, software, firmware, human
resources, information, techniques, facilities services, and other support
elements.
In this standard the concept of “system” is used in a wide sense. The highest
level, often called “mission level” or “space system”, consists usually of one (or
more) space segment(s), of a ground segment, and of a user segment. Elements
of system decomposition are also considered a system. For the purpose of this
standard the system can be any element at any level of decomposition as
defined by the function tree (see Annex H) or the product tree (see ECSS-M-ST-
10 Annex B). The scope of an element can include hardware, software,
procedures, man-in-the-loop, facilities and services.
From the perspective of the considered system, requirements originate from the
next upper level (the customer) and elements are procured from the next lower
level (the suppliers).
NOTE 1 The customer-supplier model is described in
ECSS-S-ST-00.
NOTE 2 Through this standard the notion of customer
refers to several actors ,in relation to the project
phase. In fact a customer can be e.g. a scientific
community in phase 0, a commercial user in
phase A or an Agency in phase B. A supplier can
on the other hand be an Agency in both phase 0
and phase A.
Figure 4-1 shows the boundaries of system engineering, its relationship with
production, operations, product assurance and management disciplines and its
internal partition into the following system engineering sub-functions:
• requirement engineering, which consist on requirement analysis and
validation, requirement allocation, and requirement maintenance;
• analysis, which is performed for the purpose of resolving requirements
conflicts, decomposing and allocating requirements during functional
analysis, assessing system effectiveness (including analysing risk factors);
12

---------------------- Page: 14 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
and complementing testing evaluation and providing trade studies for
assessing effectiveness, risk, cost and planning;
• design and configuration which results in a physical architecture, and its
complete system functional, physical and software characteristics;
• verification, which objective is to demonstrate that the deliverables
conform to the specified requirements, including qualification and
acceptance;
• system engineering integration and control, coordinating the various
engineering disciplines and participants throughout all the project
phases.
Figure 4-2 shows system engineering sub-functions, their inter-relationships
and their main activities during the system engineering process.
System engineering sub-functions are applied in an iterative mode during
implementation of the system engineering process described in clause 4.2.
Within the frame of a project, the system engineering function is generally
implemented by a system engineering organisation of the supplier which is in
charge of transforming the requirements of the customer into a system solution
delivered by the supplier. For the purpose of this standard, the ‘system
engineering function’ only is referred to in the normative statements,
independent of whether the supplier has a formal ‘system engineering
organisation’ or not.
NOTE With respect to the next lower level, the
supplier plays the role of the customer.
13

---------------------- Page: 15 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)


Figure 4-1: System engineering, sub-functions and boundaries
14
Management
- Cost
- Planning
- Configuation control
- Procurement
- Information
- Documentation
SYSTEM ENGINEERING INTEGRATION AND CONTROL
- Product
 assurance
- Dependability
- Verification
ANALYSIS
- Development
- Procurement
- M.A.I.T
- Criticality
REQUIREMENTS analysis
DESIGN AND
- PM&P
ENGINEERING
CONFIGURATION
- Safety
- EEE component
VERIFICATION
SYSTEM
ENGINEERING
- Operations Engineering
- Operations Verification
- Logistic Analysis
Production
Product
Assurance
Operations and Logistics
= Interface Area
= System Engineering Scope = Other Programme Disciplines
MAIT = manufacturing, assembly, integration and test
PM&P = parts, materials and processes

---------------------- Page: 16 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
Plans and Data
Plans and Data
Plans and Data

Figure 4-2: System engineering sub-functions inter-relationships

15
System Engineering Data Base
Technical Plans
System Engineering Tools and Models
Integration and Control
System Analysis
System Analysis
System Analysis
Analysis
Requirement Functional Analysis Design and
Engineering and allocation configuration
Customer input
Requirement Engineering
Design and configuration
Functional Product
Qualified product design
Requirements
Verification Verification
Verification
Verification

---------------------- Page: 17 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
4.2 The system engineering process
The system engineering activities of a project are conducted by an entity or
resources within the project team of a supplier. This entity or the resources that
perform this function is called in this document “system engineering function”.
The system engineering process is in turn applied by each system engineering
function of each supplier of the elements of the product decomposition.
The system engineering process consists of activities to be performed by the
system engineering function within each project phase. The objective is to
obtain a product which satisfies the customer technical requirements within
pre-established objectives of cost and time. The requirements for these activities
are described in clause 5.
The system engineering process is intrinsically iterative across the whole life of
a project, in particular in the initial phases (i.e. 0, A, and B) of the development
of a complex system (e.g. a spacecraft), procured through a multi-layered set of
suppliers.
During these phases, the system engineering function derives design oriented
technical solutions using as an input to the design-independent customer
requirements contained in a technical requirements specification (TS). This is
achieved through an iterative top-down process by trading off several design
solutions at an increasing level of detail.
NOTE For definition and requirements for a technical
requirements specification see ECSS-E-ST-10-06.
Through this process the system engineering function performs a
multidisciplinary functional decomposition to obtain logical lower level
products (both hardware and software). At the same time the system
engineering function decides on balanced allocations, throughout the system, of
resources allocated by the customer and respects agreed margin philosophies as
a function of the relevant technology readiness levels.
The functional decomposition defines, for each level of the system, the technical
requirements for the procurement of subassemblies or lower level products as
well as the requirements for the verification of the final characteristics of each
product.
The system engineering process uses the results of these lower level verification
activities to build a bottom-up multi-layered evidence that the customer
requirements have been met.
The system engineering process is applied with various degrees of depth
depending on the level of maturity of the product (e.g. new development or off-
the-shelf).
The system engineering process can be applied with different level of tailoring
as agreed between customer and supplier in their business agreement.
The system engineering function has interfaces with those other functions in
charge of management, product assurance, engineering disciplines, production,
and operations and logistics.
NOTE The project phases are defined in ECSS-M-ST-
10.
16

---------------------- Page: 18 ----------------------
kSIST FprEN 16603-10:2016
FprEN 16603-10:2016 (E)
4.3 Overview of system engineering tasks per project
phase
4.3.1 Overview
The allocation of specific system engineering requirements per phase depends
strongly on the type of business agreement established between customer and
supplier and the nature and level of complexity of the system subject of the
agreement. The breakdown and the details of the tasks are defined in the
business agreement specific documents.
NOTE Some projects define them in a Statement of
work (SoW).
The actors in the customer-s
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.