ecss-e-10a system engineering (19 april 1996)
TRANSCRIPT
FOR SPACE STANDARDIZATION
EUROPEAN COOPERATION
ECSS
Space Engineering
System Engineering
ECSS SecretariatESA–ESTEC
Requirements & Standards DivisionNoordwijk, The Netherlands
ECSS–E–10A19 April 1996
ECSS19 April 1996ECSS–E–10A
2
Printed in the Netherlands
Copyright 1996 � by the European Space Agency for the members of ECSS
Published by: ESA Publications Division,ESTEC, P.O. Box 299,2200AG Noordwijk,The Netherlands.
Price: 35 Dutch Guilders
ECSS 19 April 1996
ECSS–E–10A
3
Foreword
This standard is one of the series of ECSS Standards intended to be applied to-gether for the management, engineering and product assurance in space projectsand applications. ECSS is a cooperative effort of the European Space Agency,National Space Agencies and European industry associations for the purpose ofdeveloping and maintaining common standards.
Requirements in this standard are defined in terms of what must be accom-plished, rather than in terms of how to organise and perform the necessary work.This allows existing organisational structures and methods to be applied wherethey are effective, and for the structures and methods to evolve as necessary with-out rewriting the standards.
The formulation of this standard takes into account the existing ISO 9000 familyof documents.
This standard has been prepared by the ECSS Standards Working Group, re-viewed by the ECSS Technical Panel and approved by the ECSS Steering Board.
ECSS19 April 1996ECSS–E–10A
4
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
5
Contents List
Foreword 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Scope 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Introduction 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Relationship with other standards 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 References 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Normative references 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Definitions and abbreviations 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Definitions 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Abbreviations 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 General requirements 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 System engineering management plan 19. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 System engineering & control 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Requirement engineering 23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Analysis 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Design & configuration 32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Verification 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 System engineering interfaces 39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ECSS19 April 1996ECSS–E–10A
6
5 Specific requirements 43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 System Engineering required inputs 43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 System engineering integration & control 45. . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Requirement engineering 47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Analysis 49. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Design and configuration 52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Verification 53. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex A (informative) DRD: system engineering management
plan 57. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex B (informative) Organization of system engineering
Level 3 standards 61. . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex C (informative) System engineering documentation
definitions 65. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures
Figure 1: System Engineering Functions 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2: System Engineering Process 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3: Space System Requirements 25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 4: Sample Specification Tree 27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 5: Basic Verification Approach 35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 6: Model Philosophy Definition Process 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables
Table 1: Typical Inputs for System Engineering 44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table B–1: Level 3 System Engineering Standards 61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ECSS 19 April 1996
ECSS–E–10A
7
1
Scope
1.1 IntroductionThis standard is intended to guide the development of Systems (including hard-ware, software, man–in–the–loop, facilities and services) for space applications.It specifies implementation requirements for the responsible System Engineeringorganisation consistent with the assumption that the System Engineering processdefined in Standard ECSS–E–10–01 is to be applied.
Specific objectives of this standard are to :
a. Assist in defining, performing, managing, and evaluating System Engineer-ing efforts to ensure that the programme has a firm organisational basis, ablein principle to minimise technical risk due to uncertain understanding ofscope.
b. Facilitate minimisation of cost through avoidance of repeated organisationalwork, conversion between different practices and dispersions due to conflictsof interpretation of approaches to System Engineering tasks.
c. Capture the key aspects of the Space Standardization initiatives to : betterintegrate requirements; implement multidisciplinary teamwork includingsuppliers; establish the requirements early; establish clear measurements ofsystem responsiveness; focus on process control rather than inspection; en-courage risk management rather than risk avoidance; increase teamwork andcooperation.
This Standard covers specifically each conventional phase of development of aSpace System, from analysis and assembly of the user’s requirements to oper-ations and disposal.
The requirements of this Standard may be tailored for each specific space applica-tion, in line with the overall ECSS tailoring guidelines (Ref. .....).
For the definition of “System Engineering” see Clause 3 below. System Engineer-ing has an integration role for the Engineering disciplines defined in StandardECSS–E–00.
For the definition of System lower levels of decomposition, this Standard, in linewith other ECSS standards, does not assume a unique terminology in the assump-tion that each programme may optimise its breakdown choosing from the termsdefined in ECSS–E–00.
ECSS19 April 1996ECSS–E–10A
8
In this respect it is important to note that the guidelines herein formulated for aspace “System” indeed apply, with appropriate tailoring, to a lower level of decom-position, on the grounds that products of practically any level are:
a. the final result of an interdisciplinary process starting with the operationalrequirements analysis and concluding with the delivery of the verified andcertified product;
b. the result of the design integration of different parts and functions.
Figure 1 shows the boundaries of the System Engineering discipline, its relation-ship with Production, Operations, Product Assurance and Management disci-plines and its internal partition into “Functions”:
� System Engineering Integration & Control� Requirements Engineering� Analysis� Design and Configuration� VerificationFunctions do not represent a compulsory organisation requirement, but rather auseful conceptual partition of the System Engineering discipline, whereby each el-ement (“function”) embraces tasks which are homogeneous in objective and na-ture, and all elements together encompass the totality of the discipline’s scope.
The organisation of requirements per functions, as in this Standard, permits thedefinition of clear–cut, homogeneous sets that can be easily mapped on the func-tional diagram of the Systems Engineering process defined in standard ECSS–E–10–01 (Figure 2), and external to which only requirements for System Engin-eering Interface tasks at the boundary with other disciplines remain to be defined.
The dynamic properties of this process, namely its applicability in an iterative andnested pattern across the complete span of a system life cycle, are described in de-tail in Standard ECSS–E–10–01 “Systems Engineering Process”.
For each function, General (i.e. principle, structural) and Specific (i.e. in the formof a discrete, verifiable task or product for a given life cycle phase) requirementsare given, covering all the System Engineering activities as a means of obtaininga beneficial, nonoverburdening, programme–independent recommendation orguideline.
ECSS 19 April 1996
ECSS–E–10A
9
ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ
SY
ST
EM
EN
GIN
EE
RIN
G IN
TE
GR
ATIO
N &
CO
NT
RO
L
AN
ALY
SIS
VE
RIF
ICAT
ION
DE
SIG
N &
CO
NF
IGU
RAT
ION
Ma
na
ge
me
nt
Op
era
tion
s &
Lo
gis
tics
Pro
du
ctA
ssu
ran
ce
= O
ther
Pro
gram
me
Dis
cipl
ines
= I
nter
face
Are
a
– C
ost
– P
lann
ing
– C
onfig
urat
ion
Con
trol
– P
rocu
rem
ent
– O
pera
tions
Eng
inee
ring
– O
pera
tions
Verif
icat
ion
– Lo
gist
ic A
naly
sis
– D
evel
opm
ent
– M
.A.I.
T.
– D
epen
dabi
lity
– Ve
rific
atio
n–
Pro
cure
men
t–
Crit
ical
ity
Ana
lysi
s–
PM
PR
EQ
UIR
EM
EN
TS
Pro
du
ctio
n
= S
yste
m E
ngin
eerin
g S
cope
SY
ST
EM
EN
GIN
EE
RIN
G
NOTE MAIT = Manufacturing, Assembly, Integration and TestPMP = Parts, Materials, Processes
Figure 1: System Engineering Functions
ECSS19 April 1996ECSS–E–10A
10
CO
NTR
OL
System
Eng
ine
erin
g D
ata
Base
Tec
hn
ica
l Pla
ns
System
Eng
ine
erin
g To
ols a
nd
Mo
de
ls
SYSTEM
AN
ALY
SISSY
STEMA
NA
LYSIS
SYSTEM
AN
ALY
SIS
REQ
UIR
EMEN
TSA
NA
LYSIS
DESIG
N
Re
qu
irem
en
tsTra
de
–Offs &
Imp
ac
ts
De
co
mp
. & R
eq
ts.A
lloc
atio
nA
ltern
ative
s
Re
qu
irem
en
ts&
Co
nstra
ints
Co
nflic
ts
De
co
mp
. & R
eq
ts.Tra
de
–Offs &
Imp
ac
ts
De
sign
Solu
tion
Re
qu
irem
en
ts&
Alte
rna
tives
De
sign
Solu
tion
Trad
e–O
ffsIm
pa
cts
REQ
UIR
EMEN
TSVA
LIDA
TION
FUN
CTIO
NA
LVA
LIDA
TION
PH
YSIC
AL
VER
IFICA
TION
FUN
CTIO
NA
LA
NA
LYSIS &
ALLO
CA
TION
Va
lida
ted
Re
qu
irem
en
tsBa
selin
e
Re
qu
irem
en
tsBa
selin
eFu
nc
tion
al
Arc
hite
ctu
re
Va
lida
ted
Fun
ctio
na
lA
rch
itec
ture
Ph
ysica
lC
on
figu
ratio
n
Ve
rified
Ph
ysica
lC
on
figu
ratio
n
Co
nflic
ts an
d V
aria
nc
es
Plans & Data
Plans & Data
Plans & DataSystem
Engineering
INPUT
OUTPUT
Figure 2: System Engineering Process
ECSS 19 April 1996
ECSS–E–10A
11
1.2 Relationship with other standardsFor the overall definition of “System Engineering” as a discipline of Engineeringin Space projects this Standard refers to Standard ECSS–E–00 (Engineering ofSpace Programmes), while for the theory of System Engineering this Standardrefers to Standard ECSS–E–10–01 (Systems Engineering Process).
It is in ECSS–E–10–01 that “System Engineering” is explained as a mechanismfor proceeding from interpretation of the customer’s requirements to an optimisedproduct by steadily applying a wide–ranging attention to product requirements,extending to all details of the user’s needs, produceability constraints and life cycleaspects, essentially through an organised concurrent engineering practice. Thistakes place through iteration and nesting of a proper routine of analysis/synthesis,typical of a comprehensive system approach, within and across all levels of in-tegration and all phases of a system life cycle.
Standard ECSS–E–10–01 defines and describes this routine in a high–level, prod-uct–independent, phase–independent and essentially intellectual way.
This standard instead aims at providing a practical, space–focused implementa-tion of the above, developing it into a set of discrete definitions and requirements.These constitute a common reference or “checklist” of maximum utility for organis-ing and conducting, with respect of the above principles, the engineering activitiesof a space system project or for participating as customer or supplier at any levelof decomposition.
The System Engineering activities addressed in ECSS–E–10
� integrate specifically the activities of other Engineering disciplines covered byECSS–E–xx standards (ECSS–E–20 Electrical and Electronic, ECSS–E–30Mechanical, ECSS–E–40 Software, ECSS–E–50 Communications,ECSS–E–60 Control Systems, ECSS–E–70 Ground Systems and Operations);
� ensure a functional interfacing with Management and Quality activities cov-ered by ECSS–M–xx and ECSS–Q–xx standards, in particular:� System Engineering is submitted to ECSS–M–10 Project Breakdown Struc-
ture, ECSS–M–20 Project organisation (it is part of it), ECSS–M–30 ProjectPhasing;
� System Engineering is fully interfaced with and complies with the require-ments of ECSS ECSS–M–40 Configuration Management, ECSS–M–50 In-formation/ Documentation, ECSS–M–60 Cost and Schedule Management,and ECSS–M–70 Integrated Logistics Support;
� System Engineering integrates in the product design and implementationprocess the inputs of the Product Assurance organisation, namely Depend-ability, Safety, Component Control, Materials, Mechanical Parts and Pro-cesses provisions.
� System Engineering contributes to the implementation of the Product As-surance organisation by integrating the ECSS–Q–xx requirements andfacilities within the system engineering activities.
ECSS19 April 1996ECSS–E–10A
12
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
13
2
References
2.1 Normative referencesThis ECSS Standard incorporates, by dated or undated reference, provisionsfrom other publications. These normative references are cited at the appropriateplace in the text and publications are listed hereafter. For dated references,subsequent revisions of any of these apply to this ECSS standard only when incor-porated in it by revision. For undated references the latest edition of the publica-tion referred to applies.
ECSS–E–00 Space Engineering – Policy and Principles
ECSS–E–10–01 Space Engineering – System Engineering Process
ECSS–M–00 Space Project Management – Policy and Principles
ECSS–M–30 Space Project Management – Project Phasing and Planning
ECSS–M–40 Space Project Management – Configuration Management
ECSS–M–70 Space Project Management – Integrated Logistic Support
ECSS–P–001 Glossary of Terms
ECSS19 April 1996ECSS–E–10A
14
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
15
3
Definitions and abbreviations
3.1 DefinitionsFor the purposes of this standard, the definitions given in ECSS–P–001 Issue 1apply. In particular, it should be noted that the following terms have a specific de-finition for use in ECSS standards.
Acceptance
Analysis
Configuration Baseline
Design
Development
Element
Equipment
Inspection
Margin
Product tree
Qualification
Requirements
Specification
Subsystem
System
Test
Verification
For definitions of the following terms refer to ECSS–E–10–01 “System Engineer-ing Process” :
Design–to–Cost
Effectiveness analysis
Integration
System Engineering
ECSS19 April 1996ECSS–E–10A
16
The following terms and definitions are specific to this standard and shall be ap-plied.
“Hybrid Model Philosophy
Model philosophy representing a compromise between prototype and protoflightapproaches. It is based on a protoflight model on which a partial protoflightqualification test campaign is carried out. Specific qualification test in the criticalareas are carried out on dedicated models.”
“Protoflight Model Philosophy
Model philosophy based on a single model (Protoflight Model) to be flown after ithas been subjected to a protoflight qualification and acceptance test campaign.Typical philosophy for projects with no technology critical design and compromisepermitted to reduce cost accepting a medium risk.”
“Requirement Traceability
A requirement attribute that links each single requirement to its higher level re-quirement(s) inside the requirement set.”
This eventually makes possible the derivation of a requirement tree which dem-onstrates the coherent flow–down of the requirements.
“System Engineering
The application of System Engineering theory to a specific system”
“Time line analysis
Analytical task conducted to determine the time sequencing between two or moreevents and to define any resulting time requirements.”
“Test effectiveness
The number of failures per spacecraft found in the test of interest divided by thetotal number of failures which are possible to be found in all the acceptance testcampaign and during the first 45 days of flight.”
3.2 AbbreviationsThe following abbreviations are defined and used within this standard.
Abbreviation Meaning
AIV Assembly, Integration and Verification
AOCS Attitude & Orbit Control System
CAD Computer Aided Design
DJF Design Justification File
ECSS European Cooperation for Space Standardization
EEE Electronic, Electrical, Electromechanical
EGSE Electric Ground Support Equipment
EMC Electro–Magnetic Compatibility
ICD Interface Control Document
ILS Integrated Logistic Support
IRD Interface Requirement Document
LRR Launch Readiness Review
LSA Logistic Support Analysis
PA Product Assurance
PDR Preliminary Design Review
QR Qualification Review
R&D Research and Development
ECSS 19 April 1996
ECSS–E–10A
17
S E System Engineering
SEMP System Engineering Management Plan
SRR System Requirement Review
TBD To Be Defined
TRB Test Review Board
VCD Verification Control Document
ECSS19 April 1996ECSS–E–10A
18
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
19
4
General requirements
4.1 System engineering management planThe system supplier response to this Standard shall be a System EngineeringManagement Plan (SEMP) which describes the approaches, techniques, tools, or-ganisation, planning and scheduling of the technical effort necessary to accom-plish the project objectives. The SEMP demonstrates the implementation of theSystem Engineering functions mentioned hereafter and the logic and consistencyof the development activity planning. The SEMP, usually approved by the cus-tomer, describes all foreseen contributions to the SE effort and shall be updatedduring the course of the project (with the approval of the responsible customerand supplier staff as necessary), to reflect any evolution in the System Engineer-ing implementation.
The requirements for the organisation and presentation of the System Engineer-ing Management Plan are given in Annex A to this standard.
4.2 System engineering & controlSystem Engineering Integration and Control ensures the integration of the vari-ous disciplines and participants throughout all the project phases in order to op-timise the total definition and realisation of the system. It provides correspondinginputs to programme management.
4.2.1 System engineering managementThe System Engineering organisation responsible for the design of the completesystem’s architecture and for the control of the Interfaces shall be capable of :
a. planning and managing a fully integrated technical effort able to achieve thegeneral objectives of the system with minimised risks
b. applying the system engineering process for each level of system decomposi-tion during each phase of the project life from top level project managementdown to the lowest level
c. controlling the achievement at each project milestone through the conduct oftechnical reviews, risk management, data management, interface manage-ment, configuration management and verification
d. generating models and breadboards, carrying out research and development,studies to support trade off analyses and the optimised design of the systemarchitecture
ECSS19 April 1996ECSS–E–10A
20
e. generating a product and process data package which ensures that the com-plete System can be produced, tested, delivered, operated, supported andproperly disposed of
f. coordinating, integrating and harmonising the planning, activities and prod-ucts of all disciplines involved in space project Engineering as addressed inECSS–E–00.
g. ensuring that the methods and means (including software) required for eachactivity are available and validated at the due time
h. ensuring that the experience gained in past and parallel activities is system-atically considered in the process and in the design solutions
4.2.2 Planninga. System Engineering Integration and Control shall establish and maintain in
the SEMP a System Engineering schedule compliant with the project masterschedule.
b. It shall provide inputs based on key events for each discipline to enable themto establish their own planning in a coordinated manner.
4.2.3 Engineering data basea. System Engineering Integration and Control shall set up a data base gather-
ing all engineering data from requirements analysis and validation, func-tional analysis and validation, design, physical verification and system analy-sis.
b. The design files and the corresponding justification files in which all decisionstrade–offs and risk assessments shall be included, shall be set up in com-pliance with the project configuration management rules.
4.2.4 Documentation and data exchangea. System Engineering Integration and Control shall provide their requirements
to the definition and the setting up of the documentation and data exchangesystem in order to ensure the System Engineering interdisciplinary work, thecontrol of the total definition and realisation of the system, the interface man-agement, and configuration control.
b. System Engineering shall establish an Engineering Documentation and DataExchange System, compatible with the overall requirements of ECSS–M–50.
c. The Engineering Documentation and Data Exchange system should be as de-fined in Engineering level 3 standard TBD
4.2.5 Interface managementSystem interfaces can be external (with other, contiguous systems) or internal(between functions within the system).
Both can be part of an original set of requirements (Interface Requirement Docu-ment), or can be defined as outputs from functional studies. They are determinedat the boundary between functions of hardware or software assemblies implem-ented by different engineering responsibility groups, and are normally separatelyspecified.
a. System Engineering Integration and Control shall establish and maintain apositive control of interfaces supported by Interface Control Documents(ICD’S) and interface control procedures.
b. Functional block diagrams and functional interface input/output shall be ex-pressed in the earliest phase of the project and updated throughout its course.
Physical or functional/operational interfaces, characterised by mechanicaland/or functional data/parameters, may be included.
ECSS 19 April 1996
ECSS–E–10A
21
4.2.6 Environmental engineeringa. System Engineering shall perform environmental engineering tasks following
methodologies defined in level 3 ECSS standards to ensure system robustnessunder environmental conditions.
b. All combined natural or induced environmental conditions having an impacton system functions and applied during the system life cycle shall be con-sidered, including the following environment types:
� Climatic
� Mechanical (vibration, shock, microvibration, acoustic)
� EMC
� Thermal
� Contamination
� Radiation
� Atomic oxygen
� Debris, ...
c. Environmental conditions to be considered shall concern all relevant eventsduring the system life cycle including:
� Manufacturing,
� AIV
� Transportation, storage
� Mission operations (launch, in–orbit,...)
� Disposal
d. Environmental engineering activities shall be initiated in the earlier phasesof the programme.
e. Environmental engineering activities shall be carried out within the SystemEngineering organisation by environmental engineering specialists.
Requirements related to environment engineering tasks are described in rel-evant System Engineering function requirement clauses of this standard (re-quirements, analysis, design, verification).
4.2.7 Human factors engineeringa. System Engineering shall perform human factors engineering tasks following
methodologies defined in level 3 standards to ensure system safety, usabilityand efficiency when human beings are interacting with the product.
b. The following key points required to guarantee safety, well–being and effi-ciency for the human presence shall be considered :
� Anthropometry and biomechanics (human body mechanical limitations)
� Human performance capabilities (strength, workload etc.)
� Climate (pressure, atmospheric composition, temperature and humidity)
� Environment (microgravity, acoustic, vibration, radiation, contamination)
� Crew safety (hazards)
� Architecture (workstations, activity centres, health management, house-keeping etc.)
� Human/Machine interfaces (Software & Hardware)
� Extravehicular Activity and related supports
� Procedures development & Training
c. Human Factors engineering activities shall be started in the earliest phasesof space projects.
ECSS19 April 1996ECSS–E–10A
22
d. Human Factors engineers shall be part of the System Engineering organisa-tion, Hardware, Software or Courseware detailed design requirements may beapplied to or may originate from subsystem or equipment level.
4.2.8 Budget and margin philosophya. Necessary design margins for technical budget uncertainties shall be defined
and controlled for each level as appropriate
b. During the life cycle of a space project, the required margins shall be reduceddepending on the ratio of open/solved technical uncertainties, problems or po-tential development and mission risks.
c. For the physical parameters (e.g. mass, size, tolerance, etc. ) a product–oriented element or component budget shall be identified.
d. There shall be a continuing verification of the degree of anticipated and actualachievement for these technical parameters.
4.2.9 Technologya. Wherever applicable systematic trade–offs of proven versus new technologies
applicable shall be conducted to achieve optimised product performances.
b. System Engineering shall take into consideration technologies’ availabilityand sensitivity at various steps of the project.
c. Mainly during the conceptual phase, the necessary techniques shall be as-sessed in terms of availability and feasibility within the defined industrial or-ganisation cost and schedule.
d. Any additional research or tests or any investigation required to reduce uncer-tainties and risks to an acceptable level shall be conducted.
e. Where risks are high, back–ups shall be considered or more resources shall beallocated to improve the situation.
f. Qualification of critical processes and new technologies shall be achieved in acontrolled manner in line with the overall schedule.
g. In the design phase continuous verification of readiness and efficiency of themanufacturing processes and corresponding technologies shall continue inorder to detect any possible deviation from objectives.
4.2.10 Cost effectivenessCost effectiveness is a major driver in the programme decision process and designiteration. It is part of design to objectives, included in System Engineering trade–offs mainly addressing a cost/performance to function parameter. The design–to–cost approach includes any additional cost reduction initiatives, and defines cost–driven incentives.
a. Cost effectiveness based on the project specific cost objective (e.g. develop-ment, or operations, or life cycle cost minimisation), shall be considered as aproduct design parameter, along with performance, effectiveness, capability,accuracy, size, weight, reliability, maintainability, supportability...
Cost effectiveness may be applied to a deliverable item, to total system design, tomanufacturing, to operations, to procurement (acquisition) and to major modifi-cations, in order to control and minimise cost in accordance with project require-ments.
4.2.11 Risk managementa. System Engineering shall contribute to the Risk Management process defined
in ECSS–M–00 by specifically providing, and by assessing, the technical datainvolved in the Risk Management analyses, decision and implementation ac-tivities.
ECSS 19 April 1996
ECSS–E–10A
23
b. This will include support to:
� analysis of the risk causes, consequences and acceptability;
� quantification and categorisation of the risk;
� definition and implementation of a Risk Management Plan;
� verification of the effects of risk–reduction actions;
� residual risk acceptance process;
and execution of the Logistic Support Analysis
c. System Engineering shall consistently implement and control the selectedrisk reduction provisions which are within engineering’s responsibility.
4.2.12 ProcurementSystem Engineering Integration and Control shall:
a. ensure that manufacturing constraints are included in System Engineeringtrade–offs
b. support the Engineering effort in establishing the manufacturing or purchasespecifications
c. support the make or buy decision trade–off
d. support the procurement activities by coordinating Engineering effort.
4.2.13 Change managementa. Change control shall be established and maintained in conformance with
ECSS–M–40.
b. At system level the complete architecture shall be submitted to change control.
c. When a change affects interfaces and involves parties on both sides of the in-terface, the upper level shall ensure the compatibility of newly defined inter-faces and shall take any decision, considering the benefit of the whole.
d. System Engineering shall be the technical authority for changes raised up toproject level and ensure that the same rules are applied at lower levels.
e. System Engineering shall provide the supporting technical documentation.
4.2.14 System engineering capability assessmentThe capability to perform System Engineering tasks or an activity including Sys-tem Engineering studies shall be demonstrated as a minimum by :
a. the evidence of human resources and corresponding organisation, experienceand capacity to manage proposed subcontractors
b. a System Engineering Capability Assessment which can be performed accord-ing to the standard ”quality assessment procedures” and SE capability asses-sment guide as defined in Engineering level 3 standard TBD.
4.3 Requirement engineering
4.3.1 ResponsibilitiesRequirement Engineering shall be part of System Engineering, responsible forthe proper interpretation of the end–customer needs, coherent and appropriategeneration of system and lower assembly level specifications, and day–to–daycontrol of the requirement status and traceability.
ECSS19 April 1996ECSS–E–10A
24
4.3.2 Requirement classification
4.3.2.1 Requirement generationSpace System requirements are typically identified and grouped in relationshipto their primary objective in specifying the system as shown in Figure 3.
a. When space system requirements are generated consideration shall be givento the system’s functional objectives, its characteristics and interfaces, theenvironmental conditions under which it will perform, the quality and oper-ational factors, the necessary support and the verification aspects, this provid-ing operational, functional and physical views of the system and its constitu-ents.
b. System or operational requirements need not all be originated top down, butmay be derived from a lower level, e.g. subsystem.
4.3.2.2 Requirement characteristicsTo facilitate the System Engineering process, in particular the verification acti-vities, each requirement shall be:
a. Traceable with respect to at least one higher level requirement.
b. Unique and associated with a proper identifier (for instance a document andpara number).
c. Single and not a combination of several requirements
d. Verifiable using one or more approved verification methods.
e. Unambiguous
f. Referenced as necessary to other requirements (with applicable document andpara. identification).
g. Possibly associated with a specific title.
4.3.2.3 Requirement verificationThe traceable set of technical requirements forms the basis of the verification pro-cess at each architectural level.
a. Each requirement shall be associated with proper verification requirements.
b. Requirement traceability shall be established and maintained along the sys-tem life cycle
4.3.2.4 Requirement criticalityEach requirement differs in importance for the system development and oper-ation in terms of impact on cost, schedule and risks.
For this reason and to facilitate the System Engineering process:
a. a suitable criticality factor shall be associated with each requirement, to sup-port the requirement management activities;
b. the requirement sensitivity shall be evaluated (i.e. the impact on implementa-tion aspects due to critical requirement modification).
ECSS 19 April 1996
ECSS–E–10A
25
FUN
CTI
ON
ALC
ON
FIG
UR
ATIO
NAL
INTE
RFA
CES
PHYS
ICAL
ENVI
RO
NM
ENTA
LQ
UAL
ITY
FAC
TOR
SSU
PPO
RTVE
RIF
ICAT
ION
MIS
SIO
NSY
STEM
MO
DES
SYST
EM S
TATE
SSY
STEM
FU
NC
TIO
NS
SYS
FNC
TL R
ELAT
ION
SH
/W F
UN
CTI
ON
SH
/W P
ERFO
RM
ANC
ES/
W F
UN
CTI
ON
SS/
W P
ERFO
RM
ANC
EN
UC
LEAR
CO
NTR
OL
PRO
GR
AMM
ING
ETC
.
CO
MPO
SITI
ON
AL–
MAJ
OR
CO
MPO
NEN
TS–
FUR
NIS
HED
ITEM
S–
PART
S–
INTE
RC
HAN
GEA
BILI
TY–
MO
DU
LAR
ITY
– AC
CES
SIBI
LITY
ETC
.
EXTE
RN
AL–
LAU
NC
HER
– G
PS–
CR
EW–
INTE
RN
AL–
BETW
EEN
MO
DU
LES
– G
RO
UN
D S
EGM
ENT
– G
SEET
C.
SIZE
MAS
SC
OG
MO
IVO
LUM
ESH
APE
MAT
ERIA
LSM
ARKI
NG
SOFT
WAR
E C
APAC
ITY
ETC
.
ACC
ELER
ATIO
NAL
TITU
DE
CO
NTA
MIN
ATIO
NFU
NG
US
HU
MID
ITY
MET
EOR
OID
SPL
ASM
APR
ECIP
ITAT
ION
PRES
SUR
ER
ADIA
TIO
N(S
USC
EPTI
BILI
TY)
SHO
CK
SPAC
E D
EBR
ISVI
BRAT
ION
ETC
.
MFG
PR
OC
ESSE
SR
ADIA
TIO
NW
OR
KMAN
SHIP
SYST
EM S
AFET
YSY
S EF
FEC
TIVE
NES
SC
OM
PUTE
R U
TIL
REL
IABI
LITY
MAI
NTA
INAB
ILIT
YFL
EXIB
ILIT
YAV
AILA
BILI
TYC
OR
REC
TNES
SEF
FIC
IEN
CY
INTE
GR
ITY
USA
BILI
TYTE
STAB
ILIT
YFL
EXIB
ILIT
YTR
ANSP
ORT
ABIL
ITY
LIFE
ETC
.
SUPP
ORT
FAC
ILIT
IES
MAI
NTE
NAN
CE
SUPP
LYFA
CIL
ITY
TRAI
NIN
GPE
RSO
NN
ELTR
AIN
ING
PUBL
ICAT
ION
SLO
GIS
TIC
SET
C.
MET
HO
DS
– IN
SPEC
TIO
N–
REV
IEW
OF
DES
IGN
– AN
ALYS
IS–
TEST
LEVE
LS–
SYST
EM–
MO
DU
LE–
SUBS
YSTE
M–
EQU
IPM
ENT
MET
HO
DO
LOG
IES
MAT
RIX
ETC
.
INTE
RFA
CES
BETW
EEN
ITS
PART
S AN
DTO
WAR
DEX
TER
NAL
WO
RLD
THE
PART
SIT
ISC
OM
POSE
DO
F
WH
AT IT
MU
ST D
OPH
YSIC
ALC
HAR
ACTE
RIS
TIC
S
THE
CO
ND
ITIO
NS
UN
DER
WH
ICH
IT H
AS T
OPE
RFO
RM
ITS
FUN
CTI
ON
S
HO
W W
ELL
IT P
ERFO
RM
SIT
S FU
NC
TIO
NS
HO
W M
UST
BE IT
SO
PER
ABIL
ITY
THE
SUPP
ORT
IT N
EED
STO
PER
FOR
MIT
S FU
NC
TIO
NS
THE
MET
HO
DS
USE
D T
O V
ERIF
YIT
S R
EQ’S
REQ
UIR
EMEN
TS
OPE
RAT
ION
AUTO
NO
MY
CO
NTR
OL
FAIL
UR
E–
MAN
AGEM
ENT
ETC
.
Not
es:
H/W
= H
ardw
are,
S/W
= S
oftw
are.
GPS
= G
loba
l Pos
ition
ing
Syst
em,
GSE
= G
roun
d Se
gmen
t Equ
ipm
ent,
CO
G =
Cen
tre o
f Gra
vity
, M
OI =
Mom
ent o
f Ine
rtia
Figure 3: Space System Requirements
ECSS19 April 1996ECSS–E–10A
26
4.3.3 Specificationsa. The system and lower assembly level requirements shall be contained in spec-
ifications organised in a comprehensive specification tree. A sample specifica-tion tree is shown in Figure 4.
b. Specifications should comply with Specification Practice StandardECSS–E–10–TBD.
c. The specifications shall be of different types depending on the characteristicsof the configuration item to which they apply, including its architectural level(e.g. equipment–level specifications shall not contain mission requirements).
Subsets of end item specification requirements (e.g. support requirements) maybe the subject of a dedicated discipline specification.
Interface requirements may be contained in specific Interface RequirementDocuments.
ECSS 19 April 1996
ECSS–E–10A
27
SYST
EMSP
ECIF
ICA
TIO
N
SUP
PO
RT
SPEC
.IR
D
SUBS
YST
EM 1
SPEC
.
SET
ASP
EC.
SET
BSP
EC.
SET
CSP
EC.
EQU
IP. C
1SP
EC.
EQU
IP. C
2SP
EC.
ASS
Y K
1SP
EC.
ASS
Y K
2SP
EC.
SET
DSP
EC.
EQU
IP. D
1SP
EC.
EQU
IP. D
2SP
EC.
SUBS
YST
EM 2
SPEC
.
PAR
TN
UM
BER
PAR
TN
UM
BER
PAR
TN
UM
BER
CP
CI
LEV
EL 2
: SU
BSY
STEM
LEV
EL 1
: SY
STEM
LEV
EL 3
: SET
LEV
EL 4
: EQ
UIP
MEN
T O
R S
W P
RO
DU
CT
LEV
EL 5
: ASS
EMBL
Y
No
tes:
IRD
= In
terf
ac
e R
eq
uire
me
nt
Do
cu
me
nt,
CP
CI =
Co
mp
ute
r Pro
gra
m C
on
figu
ratio
n It
em
Figure 4: Sample Specification Tree
ECSS19 April 1996ECSS–E–10A
28
4.3.4 Requirement engineering process
4.3.4.1 Process contentThe Requirement Engineering process shall consist basically of the following acti-vities: requirement analysis and validation, requirement allocation and require-ment maintenance.
4.3.4.2 Requirement Analysis and Validationa. The customer’s requirements (i.e. needs and objectives) shall be analysed in
order to reach:
1. a satisfactory understanding of the customer’s expectations and agreementwith the customer of a refined requirement baseline; to this effect, possibleincomplete, ambiguous or contradictory requirements shall be identifiedand resolved with authorised customer representatives
2. a satisfactory synthesis of responsive products and services to the require-ments (see clause 4.4.5)
b. Requirement analysis and validation shall include :
1. assessment of different system life–profile situations from manufacturingto disposal with associated combinations of environmental conditions aswell as the applicable number of occurrences and their duration.
2. Identification of design requirements relating to the product, including theapplicable statutory and regulatory requirements.
3. Identification of constraints (e.g. limits of applicability) related to each spe-cific requirement.
c. The results of the requirement analysis and validation activity shall be direct-ly fed into the process of system specification generation
4.3.4.3 Requirement allocationa. The system requirements shall be allocated on the basis of proper functional
and system analyses to the lower level system constituents.
b. The allocation process shall be iteratively carried out in parallel with func-tional and architectural analyses.
c. The requirement flow–down shall be aimed at decreasing the level of complex-ity and increasing the level of detail (e.g. measurable terms, go/no–go criteria)through an added–value exercise.
d. Existing direct requirements (e.g. some design constraints) shall be allocatedto the applicable level without tailoring.
4.3.4.4 Requirement maintenancea. Requirements at all levels shall be maintained during the entire system life
cycle.
b. Any requirement change shall be processed and recorded in order to guaran-tee full visibility and traceability of the current requirement baseline.
c. The actual requirement status shall be reported in accordance withECSS–M–40.
4.3.5 Requirement management toolsRequirement generation, allocation and maintenance may be effectively sup-ported by computerised tools containing a requirement data base and an applica-tion software to support requirement control, traceability and reporting.
These tools should if used be linked to the verification control and configurationcontrol tools.
ECSS 19 April 1996
ECSS–E–10A
29
4.4 Analysis
4.4.1 Scope of analysis effortSystem Engineering analyses are performed at all levels and in all domains forthe purpose of resolving functional and performance requirements and con-straint conflicts during requirement analysis; decomposing functional require-ments and allocation performance requirements during functional analysis;evaluating the effectiveness of alternative physical element solutions and select-ing the best physical solution during synthesis; assessing system effectiveness,identifying and analysing risk factors; selecting appropriate risk handling ap-proaches; managing risk factors throughout the System Engineering effort; com-plementing testing evaluation and providing trade studies for assessing effective-ness, risk, cost and planning.
a. Analysis shall be performed in all domains at all levels and in all operationmodes.
b. Analysis shall present enough information and solutions to allow the decisionmaker to select the best available alternatives.
c. Analysis shall provide information by which to measure progress, evaluate al-ternatives, document data and decisions used and generated.
d. Analysis shall include trade–offs, studies, effectiveness assessment, and de-sign analyses to determine progress in satisfying technical requirements andprogramme objectives.
4.4.2 System analysisa. System analysis shall be performed during all phases of the product life cycle
as necessary
b. System analysis shall integrate mission analysis, requirements analysis,functional analysis, physical analysis and performance analysis.
c. System analysis shall provide a rigorous quantitative basis for performance,functional and system assessments.
d. Cost and schedule shall be analysed at each step of the product life cycle versusthe system technical parameters.
e. Mission, requirements, design, operation and support shall be analysed ver-sus cost and schedule of the final product.
f. The analyst shall develop, document, implement, control and maintain amethod to control analytic relationship and measures of effectiveness.
g. Critical measures of effectiveness used for decision making should be identi-fied for technical performance measurement.
h. System/cost–effectiveness assessments shall be used to support risk impactassessments.
i. The analyst shall assess margins and tolerances.
j. The analyst shall assess budgets (mass, communication links, power, on–board computer memory capacity, etc.)
k. The analyst shall conduct time–line analysis to determine the time sequencingbetween two or more events and to define any resulting time requirements forassessing planning critical paths.
l. For each relevant life cycle event, environmental conditions shall be assessedand quantified from existing standards, existing environmental data bases,laboratory tests, environmental models, or in–service measurement data.
m. Compliance between existing environmental data bases and the project con-straints shall be verified.
ECSS19 April 1996ECSS–E–10A
30
n. Environment types and combinations occurring during the life cycle shall beconsidered on the basis of criticality with respect to System functions.
o. The influence of environments applied during each life profile event on Systemfunction shall be assessed in terms of normal limit and extreme environmentdomains. For each pair of system functions and environment conditions rel-evant criteria qualification of the levels and limits of acceptance shall be de-fined.
p. As soon as possible design induced effects, such as mutual effects and dynamicinteractions between System components or the System and its external envi-ronment, shall be taken into account.
q. Variability or statistical distribution of environmental factors shall be as-sessed and environmental factors applicable for design including margins forsystem robustness shall be derived
r. Environment conditions for verification taking into account modelling andtest accuracy and limitations shall be specified.
4.4.3 Trade studiesA trade study can be:
� Mental: a selection made based on the judgement of the analyst or designerwhich does not require the rigour of a more formal study and for which theconsequences are not too important, one alternative clearly outweighs other,and/or time is not be available for a more formal approach.
� Informal: follows the same methodology as a formal trade study but is not do-cumented as formally since it is of less importance to the customer.
� Formal: formally conducted with results reviewed at technical reviews.The analyst shall conduct or consolidate synthesis trade–off studies to:
a. Support decisions for new products and process developments versus non–de-velopmental product and processes.
b. Establish System and Configuration items.
c. Assist in selecting system concepts, designs and solutions (including people,parts and materials availability).
d. Support material selection and make–or–buy, process, estimation and locationdecisions.
e. Analyse planning critical paths and propose alternatives.
f. Examine alternative technologies to satisfy functional/design requirementsincluding alternatives for moderate to high risk technologies.
g. Evaluate environmental and cost impacts of materials and processes.
h. Evaluate alternative physical architectures to select preferred products andprocesses.
i. Select standard components, techniques, services and facilities that reduceSystem life–cycle cost and meet System effectiveness requirements. Agenciesand commercial data bases should be utilised to provide historical informationused in evaluation decisions.
j. Assess model philosophy demonstrating qualification objectives and verifica-tion goals as well as testability needs.
k. Assess design capacity to evolve.
ECSS 19 April 1996
ECSS–E–10A
31
4.4.4 Functional analysisa. The analyst shall examine each primary System function to:
1. Support the identification and definition of performance and functional re-quirements for the primary system functions to which system solutionsshall be responsive.
2. Support the selection of preferred product and process design requirementsthat satisfy those performance and functional requirements.
3. In performing functional analysis, the analyst shall take project con-straints into account, but shall not consider a design solution.
b. From requirements analyses a validated requirement baseline shall be estab-lished which is translated into functional architecture. The functional archi-tecture describes the functional arrangements and sequencing of subfunctionsresulting from the breaking down of the set of system functions to their sub-functions.
c. Functional analyses shall identify product and subsystem solutions to thefunctional requirements that lead to an optimised functional architecture.
d. Functional analyses shall be conducted iteratively to analyse the functionalrequirements to determine the lower level functions required to accomplishthe higher level requirement.
e. Functional requirements shall be so arranged that lower level functional re-quirements are recognised as part of the higher level requirements.
f. Functional requirements shall be logically sequenced, with input, output andfunctional interface (internal and external) requirements defined, and betraceable from beginning to end conditions and across their interfaces.
4.4.5 Requirement allocation analysisFrom each functional requirement and interface, performance requirements areestablished from the highest to the lowest level. If higher level performance andfunctional requirements cannot be resolved to the lower level, the analyst deter-mines performance requirements for lower level functions and evaluates alterna-tive functional architecture.
a. Allocatable requirements shall be progressively divided to lower level.
b. Allocatable requirements shall be directly or indirectly allocated to subfunc-tions. Directly allocatable requirements such as time to perform or weight, arepartitioned among subfunctions, as appropriate. Requirements which are notdirectly allocatable, such as range, are translated into derived performance re-quirements such as fuel capacity, engine efficiency, and vehicle resistance,through appropriate techniques and analyses.
c. Nonallocatable requirements shall be applied directly to all subfunctions (e.g.constraint, material or process standard).
d. The analyst shall document the allocation of system performance require-ments to subfunctions to provide traceability and facilitate later changes.
e. Trade studies and risk analyses shall be performed to select a balanced set ofsubfunctions and to allocate performance requirements to subfunctions to as-sure requirements balance across subfunctions and to resolve conflicts amongallocated performance requirements and nonallocatable requirements.
f. The analyst shall examine each subfunction and aggregate of subfunctions todetermine the responses (outputs) of the function(s) to stimuli (inputs).
g. Analyses shall be conducted as a means of understanding the functional be-haviour of subfunctions under various conditions and checking the integrityof the functional arrangement logic.
ECSS19 April 1996ECSS–E–10A
32
h. Analyses should involve the simulation or stimulation of functional models,utilising operational scenarios which expose the model to a variety of stressfuland nonstressful situations which reflect anticipated operational usage andenvironments.
4.4.6 Analysis tools and methodsa. The System Engineering Management Plan (SEMP) shall define the analysis
tools and methods to be used during the product life cycle.
b. Existing databases shall be used to evaluate the product (cost, technology, de-sign, test, etc.).
c. New data bases shall be created for the purpose of assessing the product inorbit versus ground assessment and to increase lessons learned from projects.
d. System modelling tools, engineering modelling and simulation tools, designvalidation tools and measure of effectiveness and performance tools shall bepreferably off–the–shelf tools rather than new development tools.
e. Models shall be used in conjunction with analysis tools to increase confidenceand produce pertinent data.
f. Model validation procedures and results should be recorded.
g. Engineering tools of the computer–based systems type should be connected tothe Engineering data base of the programme.
h. Analysis reporting shall include:
1. clear reference of the Configuration Item baseline assumed for the analysis
2. identification of the analysis constraining assumptions (e.g. environ-mental)
3. explicit statement of basic assumptions and of analysis methods adopted
4. description and justification of the mathematical models used
4.5 Design & configuration4.5.1 Design Process
4.5.1.1 Process requirementsa. The design process shall derive a physical architecture and design (including
software), from functional analysis and requirement allocation.
b. Synthesis shall be conducted interactively with analysis and verification tocheck which design output best complies with requirements
c. In fulfilling these tasks Design and Configuration shall :
1. Apply design simplicity concepts, evaluating alternatives with respect tofactors such as ease of access, ready disassembly, common and noncomplextools, decreased part counts, modularity, produceability, standardization,standardization of interfaces and especially cost.
2. Demonstrate design consistency with results from risk reduction efforts.
3. Identify critical parameters, and analyse their variability and solutionsensitivity to the variability.
4. Identify applicable process and material specifications
5. Define product and process alternatives iteratively as well as requiredallowances for tolerances
6. Define tolerance methods that facilitate inspection
7. Adopt design solutions that facilitate fault detection, isolation and recovery(e.g. test points, modularity, built–in test software, feedback loops)
8. Define solutions to a level of detail that enables verification that requiredaccomplishments have been meet.
ECSS 19 April 1996
ECSS–E–10A
33
4.5.1.2 Design trade–offsa. Design is an iterative process whereby various concepts are evolved and evalu-
ated against a set of design requirements. Each iterative process shall be com-mensurate with cost, schedule, performance and risk impacts.
b. Design trade–off studies shall be conducted to (for example) :
� Evaluate alternative physical and software architectures or design to se-lect preferred solutions for products and processes.
� Select standard components, techniques, services and facilities that reducesystem life cycle cost.
� Evaluate environmental and cost impacts of materials and processes.
� Examine alternative technologies which could replace high–risk technol-ogies.
� Carry out material selection and make–or–buy decisions.
4.5.1.3 BudgetsAs a part of the Design and Configuration activity :
a. all applicable system design budgets shall be generated and maintained, re-flecting the as designed status
b. budget requirements for all system levels of decomposition shall be appor-tioned
c. the margin policy defined as part of the clause 4.2.8 activity shall be applied
4.5.2 Configuration
4.5.2.1 Configuration contenta. The output from the design shall describe the complete System functional,
physical and software configuration including the lower assembly levels,budgets, interfaces and relationships between external and internal items.
b. The level of detail of the description shall be a function of the programmephase, and in principle include at all the required assembly levels the follow-ing output :
1. Baseline configuration definition and description throughout the appli-cable life cycle phases (e.g. launch, deployed, end–of–life, etc. . . )
2. Technical input to the Product Tree and the configuration identification.
3. Project drawing at all detail levels, including studies, engineering draw-ings, assembly drawings, interface drawings, manufacturing drawingsetc.
4. Life cycle resource requirements and physical characteristics (budgets :mass, inertia, c.o.g., etc. )
5. Design input to the process documentation, material specifications, com-mercial items, descriptions, drawings and lists, Interface Control Docu-ments, handling procedures;
6. Inputs to derive the operation time lines.
4.5.2.2 Product treeThe Product Tree describes the hierarchical breakdown of a complex system intolower level as necessary to fully define the System.
a. The Product Tree shall be structured as a ”natural” breakdown of the system
b. It shall be strictly product oriented, that is a systematic subdivision of theproduct into discrete and related elements of the product to be provided.
ECSS19 April 1996ECSS–E–10A
34
c. The Product Tree shall provide a complete graphical overview of the entireSystem by its defined product items and their relationships.
4.5.2.3 Configuration baselineA System Configuration Baseline shall be established and placed under controlat defined programme points. This baseline shall record the design, data (draw-ings, budgets), text description and other pertinent information or decision, orclarifications made to System requirements.
4.5.2.4 Drawing treeA drawing tree shall be generated and maintained to reflect the drawings asso-ciated with the elements of the physical architecture, in the correct hierarchicaland assembly relationship.
4.5.2.5 Design definition fileThe designer shall maintain a file that includes all design documents and draw-ings providing a detailed description (functions, interfaces, architecture) and thefunctional and operational characteristics of a product, to be used for develop-ment and become part of the User Manual.
4.5.2.6 Design justification filea. A file shall be established in the form of an assembly of justification evidence
at a given time to prove that the design is optimised for all requirements ex-pressed in the Technical Specification.
b. The file shall identify acceptable risks, in order to ensure that the objectivesachieved fulfil the target requirements and assemble information intended tojustify design option selection.
4.5.3 Design toolsa. All drawings shall be established by use of identical methods, design rules, ref-
erence coordinate systems and technical standards as agreed at System level.
b. CAD tools shall allow selected CAD drawings to be interchangeable betweendifferent locations by suitable electronic means.
4.6 Verification4.6.1 Verification processVerification demonstrates, through a dedicated process, that the System meetsthe applicable requirements and is capable of sustaining its operational role dur-ing the project life cycle.
4.6.1.1 Verification process contentThe verification process addresses all constituents of the system and is incremen-tally performed applying a coherent building block concept through :
� Establishing verification criteria against applicable requirements� Deriving the planning for the associated verification activities� Monitoring the implementation and the execution of all verification acti-
vities at all levels in all phases� Preparing the verification close–out documentation
The typical verification process may encompass the following phases:
� development� qualification (including possibly an in–orbit stage)� acceptance (same as above)
ECSS 19 April 1996
ECSS–E–10A
35
� pre–launch readiness� post–landing verification
4.6.1.2 Verification objectivesThe objectives of the verification process are primarily:
� to demonstrate the qualification of design and performance, as meeting allspecified requirements at all necessary levels;
� to ensure that the flight hardware and software are free from workmanshipdefects and acceptable for flight;
� to validate tools, procedures and personnel necessary to support the Sys-tem ground and flight operations;
� to confirm System integrity and quality of performance after certain stagesin the project life cycle.
4.6.1.3 Verification approacha. A verification approach shall be selected during the project’s early phases by
analysing the requirements to be verified taking into account design con-straints and the qualification status of candidate solutions, availability andmaturity of the verification tools, test and verification methodologies, pro-grammatic constraints, cost and schedule.
b. The approach shall be derived through an iteration process answering theclassical set of questions: ”what?”, ”how?”, ”where?”, as summarised in Figure5.
What ? How ? Where ?
Identify the consistentset of verifiable proj-ect requirements to besubject of the verifica-tion process.
Select methods andlevels of verificationand associated modelphilosophy
Identify the phasesand events in whichthe verification is im-plemented.
Reiterations fortechnical / cost / schedule reasons
Figure 5: Basic Verification Approach
4.6.1.4 Verification methodsa. The System and lower level requirements shall be verified by one or more of
the following verification methods :
� test
� analysis
� review of design
� inspection
� demonstration
ECSS19 April 1996ECSS–E–10A
36
b. The verification method shall be selected according to the type and criticalityof the requirement, and with the cost effectiveness of the method
c. For each verification event, accept/reject criteria shall be defined and ex-pressed in unambiguous, measurable terms.
4.6.1.5 Verification levelsa. The requirement verification shall be performed incrementally at different
verification levels in relationship with the product tree; typical verificationlevels include :
� equipment
� subsystem
� system
d. Formal close–out of qualification or acceptance at lower levels shall be a pre-requisite for close–out at higher level
e. The resulting organised data shall support the formal declaration of theachieved system verification.
4.6.1.6 Model philosophya. The number of physical models (from System to lower assembly levels) shall
be optimised in order to achieve a high confidence in the product verificationwith the shortest planning and a suitable weighting of cost and risk.
VerificationStrategies
�Requirements categories
�Verification methods
�Verification levels
�Verification phases
Integration &Test Programme
�Test requirements
�Test sequences
�Test configurations
�Test facilities
ProgrammaticConstraints
�Schedule / cost
�Industrial architecture
�Reviews
�Interfaces
DevelopmentStatus
�New technologies
�Design qualification
�Heritage
�Potential suppliers
ModelPhilosophy
Figure 6: Model Philosophy Definition Process
ECSS 19 April 1996
ECSS–E–10A
37
b. The model philosophy definition shall combine programmatic constraints,verification strategies, integration and test programme, aspects, availabilityof verification facilities and development status of the candidate design sol-ution as shown in Figure 6.
Typical model philosophies are prototype, protoflight or a mix of the two called”hybrid philosophy”
4.6.2 Verification strategy
4.6.2.1 Strategy overviewa. Verification shall be strictly connected to the requirements which represent
the start and the end point of the process.
b. A coherent verification strategy shall be defined for each class of requirement(see clause 4.3.2.1) combining the selected verification methods at the appli-cable verification levels in the different verification phases in order to ensureconsistency between verification activities, and to avoid duplications or holesin the entire verification process.
c. Appropriate verification matrices shall be generated for each requirementspecification.
4.6.2.2 Environmental verificationVerification of the environmental requirements to be applied in qualification andacceptance represents an important subset of the verification process.
Environmental verification strategy shall be based on the most efficient combina-tion of environmental response prediction by models and/or environmental tests.
4.6.2.3 Integration and testa. The verification process shall include a proper combination of functional tests
during integration and environmental tests.
b. The selection of the tests to be performed on the defined models at the appli-cable levels in the different phases shall be in agreement with the chosenverification strategy.
c. The effectiveness of a specific test shall be evaluated on the basis of statisticaldata in order to reach the specified level of risk.
d. The methodologies applied for testing shall be the subject of trade–offs withconsideration for state–of–the–art test methods and other available differenttechniques (e.g. infrared vs solar simulation in thermal balance test).
e. The test severities (i.e. levels, durations), shall be properly tailored in accord-ance with requirements, design approach and verification strategy, and shalltake into account test conditions (e.g. tolerances).
4.6.2.4 Analysisa. Analysis shall be used in the qualification phase very often in combination
with test.
b. Appropriate analysis methodologies used (math. modelling, similarity analy-sis, simulation, etc.) shall be selected on the basis of technical success and costeffectiveness in line with the applicable verification strategies
c. Similarity analysis with an identical or similar product shall provide evidencethat new applications characteristics and performance are within the limitsof the precursor qualified design, and shall define any difference that may dic-tate complementary verification stages.
ECSS19 April 1996ECSS–E–10A
38
4.6.2.5 Review of design/inspectiona. Review of design shall be used in the qualification phase where review of de-
sign concepts and, in general, lower level documentation records is involved.
b. Inspection shall be used in different phases (including pre–launch, on–orbit,and post–landing) to verify requirements for construction features, documentand drawing compliance, workmanship and physical conditions.
c. Both methods shall be selected in line with the applicable verification strat-egies.
4.6.2.6 Demonstrationa. Demonstration shall be used in qualification in combination with test and
analysis as appropriate.
b. Demonstration shall be conducted through observation with or withoutspecial test equipment or instrumentation, to verify characteristics such ashuman factors engineering features, services, access features, transportabil-ity, etc.
4.6.3 Verification toolsa. The verification programme shall be implemented with the support of ap-
propriate verification tools (i.e. ground support equipment, simulators, ana-lytical tools, test facilities, etc.); maximum care shall be devoted to the designand verification of these tools because verification results strictly depend ontheir quality.
b. Verification tools shall be standardized to improve commonality and reusabil-ity at different levels.
4.6.4 Verification implementationa. The verification process shall be implemented through the following main
steps:
� Definition of the overall verification philosophy.
� Top–down verification requirement generation and associated verificationplanning.
� Bottom–up execution of Review of Design/Analysis/Test/Inspection/Dem-onstration
� Verification control and reporting.
b. Proper implementation of the verification process shall be assured through abasic set of documents which typically consists of:
� Verification matrices associated with specifications.
� System and lower level Verification Plans.
� Test requirement specification as a System Support Specification.
� System and lower level Verification Control Documents (VCD’s).
� Integration and Test Specifications/Procedures.
� Verification Reports.
c. The verification process shall be controlled day by day in order to prevent po-tential problems, reduce risks of cost increase and schedule slip, and give vis-ibility on the verification process to the end–customer.
The use of a verification data base, linked with the requirement data base, is rec-ommended to minimise repetitive work with the possibility of errors, and improvethe effectiveness of the overall process.
Requirement traceability is a prerequisite for a nominal verification control activ-ity.
ECSS 19 April 1996
ECSS–E–10A
39
4.7 System engineering interfaces4.7.1 Managementa. System Engineering management as defined in clause 4.2.1 shall exchange in-
puts and outputs with Project Management in order to provide to and receivefrom the Project Management all necessary technical data for the decision pro-cess at System level.
b. In particular System Engineering shall work in close relationship with Man-agement for matters regarding :
1. Planning (see clause 4.2.2), with reference to Master Phasing Plan and as-sociated detailed plans to assess, define and control the phasing of activitiesand monitor milestone events and forecasts
2. Cost, to supply estimates of activities/resources and monitor accountedactivities and trends
3. Configuration Control, to support finalisation of technical baselinesthrough Configuration Control Boards (CCBs) and properly implementconfiguration management procedures relevant to product identification,control and accounting.
4. Procurement (clause 4.2.12), to assure availability of adequate technicaldata for items to be produced, technical monitoring and control of supplier’sactivities and products and definition of proper acceptance procedures
5. Change Management (clause 4.2.13) to coordinate each change proposal,define technical implications, support planning and budgeting of changeand commit to finalised released proposal
6. Risk Management (clause 4.2.11), to allow risk assessments and the riskmanagement policy selection and implementation as in the requirementsof ECSS–M–00.
4.7.2 Product assuranceProduct Assurance and Systems Engineering activities shall be interfaced in sucha way as to ensure reciprocal timely availability of inputs, especially regarding:
� The implementation of the PA requirements in the Technical Specifica-tions, namely Dependability and Safety, EEE Parts, Materials and Pro-cesses;
� Verification Requirements;
� Requirement Traceability;
� Assessment of the proposed design solutions, namely :
* System Architecture
* Functional Architecture
* Technology Trade–offs
* Materials, Parts and Processes
* Safety features
� The conduct of :
* Risk assessment studies
* Criticality Analyses
* Logistic Support Analyses, Maintenance rules (hardware & software)
� Critical Process assessments
� Evaluation of hardware and software verification process/status
� Acceptance Process
* Nonconformance treatment
ECSS19 April 1996ECSS–E–10A
40
4.7.3 ProductionSystem Engineering shall ensure that all points of interface between System En-gineering and Production responsibility are duly supported by communication,cooperation and provision of inputs between the two organisations.
This relates in particular to :
� Incorporation of Design inputs into Manufacturing, AIV and OperationsDocuments;
� Involvement of Production in evaluations of the design solutions for pro-duceability, testability, cost trade offs;
� Preparation, execution and evaluation of development tests, i.e. tests sup-porting a prototype design improvement process based on iterative loopsof manufacture, test and evaluation when theoretical design work and si-mulation are not sufficient;
� Development and qualification of manufacturing processes;
� Adjustment and validation of assembly and handling procedures;
� Nonconformance evaluation and disposition (hardware and software)
� Approval by System Engineering of the :
* Manufacturing Plan
* Assembly, Integration and Test Plan
* Test Procedures, including test set–ups
* Work Items
* Integration Reports
* Test Reports
* Software test support tools
* Automated Test Procedures
� Approval by Production of :
* Verification Plan
* Test Specifications including set–up
* Manufacturing Drawings
4.7.4 Operations & logistics
4.7.4.1 Operations engineeringa. System Engineering shall regularly support Operations Engineering activity
by providing :
� design feedbacks and implementation policy associated with operations re-quirements
� correlation between system performance and operations requirements
� command and measurement characteristics associated with system equip-ment
� engineering (design, interfaces, and configuration) requirements and con-straints to be satisfied by the Operations plans and procedures
b. Conversely, Operations Engineering shall regularly support System Engin-eering activity by providing :
� operations scenarios, objectives and requirements for implementation inSystem design
� command and measurements list
ECSS 19 April 1996
ECSS–E–10A
41
� operations feedback and implementation policy associated with Engineer-ing requirements and constraints to be satisfied by the Operations plansand procedures
The focus of interaction varies depending on the phase of the project :
Phase A: Operations Engineering to provide operations principles, missionscenarios and functional requirements.
System Engineering to provide preliminary architecture, perform-ances and configuration implementing mission scenarios and func-tional requirements.
Phase B: Operations Engineering to provide consolidated operations andfunctional requirements.
System Engineering to provide consolidated architecture, perform-ances and configuration implementing mission scenarios and func-tional requirements.
Phase C/D:System Engineering to provide requirements and constraints to beimplemented in operations plan and procedures.
Operations Engineering to provide feedbacks and implementationpolicy associated to engineering requirements and constraints
Phase E: Engineering support to Launch Site Operations and Mission Ex-ecution.
4.7.4.2 Operations verificationInterface activities in the area of operations verification shall be supported bySystem Engineering :
� Establishment of operations verification test requirements
� Operations qualification and acceptance, in terms of functional verifica-tion, procedures and operational data verification, integrated mission si-mulation
� Operations verification and testing.
The focus of interaction varies depending on the phase of the project :
Phase B: Establishment of operations verification concepts/general require-ments; concept and requirements implementation by System En-gineering
Phase C/D:Preparation of Operations verification plan and requirements; in-tegration of plan requirements in the AIV Plan; Operations verifi-cation and testing.
4.7.4.3 Operations documentationInterfaces with Operations documentation shall be supported in :
a. Users Manual preparation (this is typically under control of Operations butincludes sections/data provided by Engineering)
b. Accommodation Handbooks preparation (this is typically under control of En-gineering but includes sections/data provided by Operations)
4.7.4.4 Integrated logistics supportILS, within the System Engineering process, is a disciplined, unified and iterativeapproach to the management and technical activities necessary to integrate sup-port considerations into system and equipment design; to develop support re-quirements that are related to supportability and readiness objectives and to de-sign; to acquire the required support.
System Engineering shall take into account and process the inputs and require-ments generated by the Integrated Logistics Support (ILS).
ECSS19 April 1996ECSS–E–10A
42
For ILS requirements standard ECSS–M–70 (Integrated Logistic Support)applies.
4.7.4.5 Logistic analysesa. Logistic Analyses, by which the logistics support necessary for a new system
is identified and evaluated during the Development phase, shall be conductedat System Engineering level.
b. An essential part shall be represented by the Logistic Support Analysis thatoperates in :
� The initial determination and establishment of logistics criteria as an inputto System design.
� The evaluation of various design & support alternatives.
� The identification and generation of logistics source data for the develop-ment and/or provisioning of logistics support elements.
� Establishment of a Reference Logistics Source Data Database (LSA RecordSystem)
LSA activities are supported and complemented by a set of different analyticalmethodologies such as:
� Maintenance analysis
� Reliability Centred Maintenance analysis
� Level of Repair analysis
� Logistics Modelling
� Supply Support analyses
� Packaging, Handling, Shipment and Transportation analyses
ECSS 19 April 1996
ECSS–E–10A
43
5
Specific requirements
The following clauses include System Engineering requirements that are specificto each programme phase and consist of a measurable task or output.
The table is not intended to list all detail tasks/outputs exhaustively nor to be anoverconstraining scheme ; the right/responsibility rests with the project to ident-ify and tailor all tasks and outputs responding to the project’s specific require-ments and constraints.
It represents however a coherent and balanced checklist of key tasks and outputstypical of a nominal project profile available as a primary reference for setting upof project planning, to which it provides consistency and focus.
Programme phases and phase definitions are defined in accordance with StandardECSS–M–30, as are Reviews.
5.1 System engineering required inputsFor each Phase, the inputs of Table 1 shall be available to allow a System Engineer-ing process to take place.
ECSS19 April 1996ECSS–E–10A
44
Table 1: Typical Inputs for System EngineeringPhase Inputs
0– Mission Concepts– User Needs
A
– Phase A System SOW– Mission Requirement Document– Other Complementary Customer Requirements
B
– Phase B System SOW– Customer System Requirement Document and Applicable Documents– Phase A Documentation (including as a minimum : System Architectural Re-
port, Mission Analysis Report, System Layout, System Budgets, Dependabilityand Safety Report, Critical Technology Report, Operations and Logistic Con-cept, Development and Verification Philosophy)
– Phase B System Proposal
C
– Phase C/D System and Lower Levels SOW’s– Phase B Documentation (including as minimum : System and Subsystem
Spec’s, Preliminary EQ Spec’s, System Design Definition File, Interface Con-trol Documents, Discipline Analysis Reports, Preliminary Verification/ P.A./Configuration Control/ Operations/ Project Management/ System EngineeringManagement Plans, System Engineering Drawings, Subsystem Layouts
– Phase C/D System and Lower Level Proposals
D
– Phase C Documentation (including as a minimum : System and Lower LevelDesign Definition Files, System and Lower Level Discipline Analysis Reports,System and Lower Level Budgets, System and Lower Level Verification/ P.A./Conf. Control/ Operations/ Project Management/ System Engineering Manage-ment Plans, P.A. Technical Reports, Configuration Items Data Lists, Prelimi-nary Verification Control Documents at System and Lower Levels, and Test, In-spection, Demonstration, and Review of Design Reports).
E/F
– Phase E/F SOW– Phase E/F System and Lower Levels Proposals– Phase D Documentation (including as a minimum : System User Manual,
Operations and Logistic Analysis Reports, System and Lower Level AcceptanceData Packages, Verification Control Documents, Verification Reports, FlightOperations Procedures, Logistic Support Procedures)
NOTE PA = Product AssuranceSOW = Statement of Work
ECSS 19 April 1996
ECSS–E–10A
45
5.2
Syst
em
eng
ine
erin
g in
teg
ratio
n &
co
ntro
l
Ph
ase
Typ
ical
Tas
ks
Typ
ical
Ou
tpu
t
O
1.S
et u
p th
e ap
prop
riat
e S
E. o
rgan
isat
ion
to
perf
orm
th
is p
has
e
2.Id
enti
fy p
reci
sely
mis
sion
obj
ecti
ves
and
envi
ron
men
tal c
onst
rain
ts
3.Tr
ansf
orm
mis
sion
obj
ecti
ves
into
sys
tem
’s s
peci
fica
tion
4.Id
enti
fy p
ossi
ble
Sys
tem
’s c
once
pts
5.Id
enti
fica
tion
of
poss
ible
ris
ks a
nd
crit
ical
asp
ects
6.P
rovi
de in
puts
to
prog
ram
mat
ics
(cos
t, s
ched
ule
) tr
ade–
offs
7.P
roje
ct d
evel
opm
ent
outl
ine
R
equ
irem
ent
trad
e of
f vs
mis
sion
obj
ecti
ves
Maj
or r
isks
an
d pr
opos
ed r
isk
redu
ctio
n a
ctio
ns
(new
R&
D,
rede
fin
e re
quir
emen
ts...
)P
ossi
ble
can
dida
te S
yste
ms
Pos
sibl
e or
gan
isat
ion
for
th
e n
ext
phas
eP
rogr
amm
atic
pre
dict
ion
(co
st c
riti
cal
path
...)
Pro
ject
dev
elop
men
t ou
tlin
e
A
1.S
et u
p th
e ap
prop
riat
e S
E o
rgan
isat
ion
to
perf
orm
th
is p
has
e an
ddr
aft
for
futu
re p
has
es
2.S
tudy
po
ssib
le
can
dida
te
Sys
tem
s,
asso
ciat
ed
risk
s an
d tr
ade
stu
dies
, in
volv
ing
man
ufa
ctu
rin
g
3.C
ost
esti
mat
ion
4.S
E c
apab
ilit
y st
udi
es
P
reli
min
ary
SE
MP
Pro
pose
d ca
ndi
date
Sys
tem
sR
isk
redu
ctio
n p
lan
Pro
pose
d in
dust
rial
org
anis
atio
n w
ith
S E
cap
abil
ity
Cos
t ob
ject
ives
an
d de
sign
to
cost
man
agem
ent
plan
B
1.S
et u
p th
e pr
ojec
t S
E o
rgan
isat
ion
for
ph
ase
B, C
, an
d D
an
d ou
t-li
ne
E
2.C
ontr
ol t
he
wor
kin
g of
th
e S
E o
rgan
isat
ion
3.U
pdat
e L
ife
Cyc
le C
ost
esti
mat
ion
s
4.R
evie
w o
f te
chn
ical
dat
a on
res
ourc
e re
cord
s
S
EM
PS
tatu
s of
ris
k re
duct
ion
act
ion
sP
rocu
rem
ent,
man
ufa
ctu
rin
g, t
est
man
agem
ent
plan
Cos
t es
tim
atio
n s
tatu
s
Con
tin
ued
.
ECSS19 April 1996ECSS–E–10A
46
Ph
ase
Typ
ical
Tas
ks
Typ
ical
Ou
tpu
t
C/D
1.C
ompl
ete
or u
pdat
e th
e S
E o
rgan
isat
ion
2.C
ontr
ol it
s w
orki
ng
3.C
ontr
ol c
han
ges
at S
yste
m le
vel
4.P
repa
re a
nd
con
duct
Sys
tem
Rev
iew
s
5.S
upp
ort
mak
e or
bu
y st
udi
es
6.P
repa
re S
E s
upp
ort
to o
pera
tion
Sta
tus
of r
isk
redu
ctio
n a
ctio
ns
Upd
ated
SE
MP
Man
ufa
ctu
rin
g, A
ssem
bly
and
Test
Pla
nC
ost
esti
mat
ion
upd
ate
Sys
tem
Rev
iew
dat
a pa
ckag
esS
E o
pera
tion
al s
upp
ort
plan
Qu
alif
ied
Sys
tem
Sys
tem
te
chn
ical
do
cum
enta
tion
an
d H
ardw
are/
Sof
twar
e de
live
rabl
es
E
1.C
ontr
ol t
he
S E
su
ppor
t to
uti
liza
tion
2.D
esig
n a
nd
deve
lop
and
con
trol
th
e n
eces
sary
ch
ange
s
3.F
eed
back
, les
son
s le
arn
t fr
om a
nom
alie
s
Sta
tus
of q
ual
ific
atio
n–
anom
alie
s an
d co
rrec
tive
act
ion
– ch
ange
s–
logi
stic
su
ppor
t u
pdat
es
F1.
Saf
e or
bit
park
ing
2.S
hu
t do
wn
pro
cedu
res
NO
TE
R&
D =
Res
earc
h a
nd
Dev
elop
men
tS
E =
Sys
tem
En
gin
eeri
ng
SE
MP
= S
yste
m E
ngi
nee
rin
g M
anag
emen
t P
lan
ECSS 19 April 1996
ECSS–E–10A
47
5.3
Req
uire
me
nt e
ngin
ee
ring
Ph
ase
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
O
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–M
ake
defi
nit
ion
of
Pre
lim
inar
y pr
ogra
mm
e re
quir
emen
tsth
rou
gh t
he
com
plet
e li
fe c
ycle
(i.e
. mis
sion
, ope
rati
ons,
per
-fo
rman
ce, s
upp
ort,
hu
man
fac
tors
, qu
alit
y fa
ctor
s, e
nvi
ron
-m
ent,
inte
rfac
es, e
tc.)
–V
alid
ate
prel
imin
ary
requ
irem
ents
bas
elin
e
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–M
issi
on R
equ
irem
ent
Doc
um
ent
A
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–A
sses
s en
d–cu
stom
er r
equ
irem
ents
in t
erm
s of
non
com
-pl
ian
ce a
nd
requ
irem
ents
sen
siti
vity
–D
efin
e re
quir
emen
t m
anag
emen
t ap
proa
ch–
Pro
vide
inpu
ts f
or t
he
prel
imin
ary
SE
MP
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–R
equ
irem
ent
Ass
essm
ent
Rep
ort
–In
puts
to
prel
imin
ary
SE
MP
B
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–P
lan
an
d or
gan
ise
requ
irem
ent
man
agem
ent
acti
viti
es–
Pro
vide
inpu
ts f
or t
he
SE
MP
–A
nal
yse
cust
omer
req
uir
emen
ts–
Gen
erat
e S
yste
m a
nd
Su
ppor
t S
peci
fica
tion
s–
All
ocat
e re
quir
emen
ts t
o lo
wer
leve
ls–
Gen
erat
e pr
elim
inar
y lo
wer
ass
embl
y le
vel S
peci
fica
tion
s–
Gen
erat
e S
peci
fica
tion
Tre
e–
Pre
pare
IR
D’s
an
d pr
elim
inar
y IC
D’s
(fo
r in
tern
al a
nd
exte
r-n
al I
nte
rfac
es)
–P
opu
late
req
uir
emen
t da
ta b
ase
wit
h t
race
abil
ity
data
–C
hec
k tr
acea
bili
ty w
ith
res
pect
to
cust
omer
req
uir
emen
ts–
Pre
pare
Tra
ceab
ilit
y R
epor
t
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
yste
m S
peci
fica
tion
–P
reli
min
ary
low
er le
vel s
peci
fica
tion
s–
Spe
cifi
cati
on t
ree
–In
terf
ace
Req
uir
emen
t D
ocu
men
ts–
Pre
lim
inar
y In
terf
ace
Con
trol
Doc
um
ents
–R
equ
irem
ent
Trac
eabi
lity
Rep
ort
–R
equ
irem
ent
data
bas
e
Con
tin
ued
.
ECSS19 April 1996ECSS–E–10A
48
Ph
ase
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
C
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–U
pdat
e S
yste
m S
peci
fica
tion
s–
Fin
alis
e lo
wer
leve
l Spe
cifi
cati
ons
–M
ain
tain
req
uir
emen
ts t
hro
ugh
th
e re
q. d
ata
base
–S
tart
pro
cess
ing
requ
irem
ents
ch
ange
s (P
roje
ct D
irec
tive
s,R
equ
ests
for
Wor
k, R
equ
ests
for
Dev
iati
on)
–P
erfo
rm c
hec
k of
tra
ceab
ilit
y st
atu
s
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
yste
m &
low
er le
vel S
peci
fica
tion
s–
Inte
rfac
e R
equ
irem
ent
Doc
um
ents
–In
terf
ace
Con
trol
Doc
um
ents
–R
equ
irem
ent
Trac
eabi
lity
Rep
ort
–S
tatu
s of
req
. ch
ange
s–
Req
uir
emen
t da
ta b
ase
D
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–M
ain
tain
req
uir
emen
ts t
hro
ugh
th
e re
q. d
ata
base
–S
upp
ort
mai
nte
nan
ce o
f in
terf
aces
th
rou
gh t
he
ICD
sys
tem
–P
roce
ssin
g an
d tr
acki
ng
of R
eq.’s
ch
ange
s
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–R
equ
irem
ents
dat
a in
clu
din
g ch
ange
s–
Req
uir
emen
t da
ta b
ase
E/F
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–M
ake
reco
rd o
f re
quir
emen
t fe
ed b
acks
fro
m m
issi
on p
erfo
rm-
ance
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
NO
TE
ICD
= I
nte
rfac
e C
ontr
ol D
ocu
men
tIR
D =
In
terf
ace
Req
uir
emen
t D
ocu
men
tS
EM
P =
Sys
tem
En
gin
eeri
ng
Man
agem
ent
Pla
n
ECSS 19 April 1996
ECSS–E–10A
49
5.4
Ana
lysi
s
Ph
ase
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
0
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–m
issi
on a
nal
ysis
–as
sess
men
t of
ope
rati
ng
con
stra
ints
–pr
elim
inar
y fu
nct
ion
an
alys
is o
f th
e S
yste
m–
prel
imin
ary
eval
uat
ion
of
syst
em d
esig
n c
once
pts
and
crit
ical
aspe
cts
–or
gan
isat
ion
cos
ts a
nd
sch
edu
les
firs
t as
sess
men
t–
proj
ect
deve
lopm
ent
outl
ine
asse
ssm
ent
–ge
ner
al r
isk
appr
oach
an
alys
is
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Inpu
ts t
o:–
mis
sion
def
init
ion
–co
nce
ptu
al d
esig
n r
efer
ence
an
d tr
ade–
offs
–pr
elim
inar
y S
yste
m b
asel
ine
–te
chn
olog
ical
nee
ds a
nd
stat
us
–fi
rst
life
cyc
le p
rodu
ct a
nal
ysis
–pl
ann
ing
crit
ical
pat
h a
nal
ysis
–D
epen
dabi
lity
an
d S
afet
y go
als
A
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–an
alys
is o
f S
yste
m r
equ
irem
ents
–S
yste
m f
un
ctio
nal
tra
de–o
ffs
–te
chn
olog
y as
sess
men
t ve
rsu
s de
sign
ch
oice
s, c
riti
cal e
l-em
ents
an
alys
is–
inpu
t to
Dep
enda
bili
ty a
nd
Saf
ety
anal
ysis
–pr
elim
inar
y gr
oun
d se
gmen
t an
alys
is–
mar
gin
an
alys
is (
mis
sion
, pro
duct
, des
ign
), in
par
ticu
lar
the
trad
e of
fs b
etw
een
per
form
ance
leve
ls, c
ost
and
sch
edu
leta
rget
s sh
all b
e es
tabl
ish
edÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Inpu
ts t
o:–
Sys
tem
bas
elin
e an
d sp
ecif
icat
ion
–fu
nct
ion
al r
equ
irem
ents
–Te
chn
olog
y de
velo
pmen
t an
d pr
ocu
rem
ent
plan
–P
rodu
ct li
fe c
ycle
def
init
ion
–S
EM
P f
or p
has
e B
Con
tin
ued
.
ECSS19 April 1996ECSS–E–10A
50
Ph
ase
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
B
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–an
alys
is o
f S
yste
m d
esig
ns
in t
erm
s of
per
form
ance
cos
t an
d sc
hed
ule
tar
gets
an
dpr
esen
tati
on t
o m
anag
emen
t fo
r se
lect
ion
of
best
com
prom
ise
–as
sess
men
t of
tec
hn
olog
ies
for
sele
ctio
n o
f ea
rly
deve
lopm
ent
or c
riti
cal c
hoi
ces
(bre
adbo
ard)
–an
alys
is o
f m
anu
fact
uri
ng
prod
uct
ion
an
d op
erat
ion
cos
ts–
reli
abil
ity
and
safe
ty a
sses
smen
t–
in–o
rbit
en
viro
nm
enta
l asp
ects
ass
essm
ent
and
anal
ysis
of
test
req
uir
emen
t–
mod
el p
hil
osop
hy
trad
e–of
fs f
or d
efin
ing
deve
lopm
ent
plan
–an
alys
is o
f th
e lo
gist
ics
nec
essa
ry f
or f
ulf
illi
ng
the
mis
sion
(gr
oun
d se
gmen
t ev
alu
-at
ion
)–
low
leve
l req
uir
emen
t an
alys
is–
cost
ass
essm
ent
–an
alys
is o
f co
mpa
tibi
lity
of
the
syst
em in
terf
ace
spec
ific
atio
ns
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Inpu
ts t
o:–
SE
MP
for
ph
ase
C/D
–D
esig
n J
ust
ific
atio
n F
ile
(DJF
)–
risk
an
alys
is–
cost
an
alys
is–
Sys
tem
, su
bsys
tem
an
d cr
itic
aleq
uip
men
t S
peci
fica
tion
s–
grou
nd
segm
ent
Spe
cifi
cati
on–
inte
rfac
e sp
ecif
icat
ion
s–
veri
fica
tion
req
uir
emen
ts–
tech
nol
ogy
trad
e–of
fs
C
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–fi
nal
ise
mis
sion
an
alys
is in
clu
din
g co
ndi
tion
s an
d co
st o
f op
erat
ion
s–
anal
ysis
of
deve
lopm
ent
test
s (b
read
boar
d, t
ech
nol
ogie
s, m
argi
ns)
–an
alys
is o
f op
erat
ion
s an
d co
st–
perf
orm
per
iodi
c as
sess
men
t of
th
e ve
rifi
cati
on a
nal
ysis
of
veri
fica
tion
too
ls–
asse
ssm
ent
of t
he
requ
irem
ent
spec
ific
atio
n–
inpu
t to
com
plet
e D
epen
dabi
lity
an
d S
afet
y an
alys
is
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Inpu
ts t
o:–
equ
ipm
ent
Spe
cifi
cati
on–
ICD
’s–
tech
nol
ogy
trad
e of
fs–
test
an
alys
is r
epor
ts–
Dep
enda
bili
ty a
nd
Saf
ety
anal
ysis
–M
issi
on a
nal
ysis
Con
tin
ued
.
ECSS 19 April 1996
ECSS–E–10A
51
Ph
ase
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
D
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–an
alys
is o
f th
e gr
oun
d qu
alif
icat
ion
pro
cess
–pe
rfor
m p
erio
dic
asse
ssm
ent
of t
he
veri
fica
tion
pro
gram
me
–an
alys
is o
f ve
rifi
cati
on a
ccep
tan
ce–
anal
ysis
rep
ort
of q
ual
ific
atio
n a
nd
acce
ptan
ce–
anal
ysis
of
fun
ctio
nal
an
d op
erat
ion
al m
argi
ns
–an
alys
is o
f in
–orb
it f
ailu
re r
ecov
ery
for
oper
atio
nal
han
dboo
k
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–Q
ual
ific
atio
n a
nd
Acc
epta
nce
An
alys
is R
epor
ts–
fun
ctio
nal
an
d op
erat
ion
al m
argi
ns
anal
ysis
rep
ort
E/F
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–an
alys
is o
f in
–fli
ght
qual
ific
atio
n w
ith
ref
eren
ce t
o m
issi
onan
d op
erat
ion
al r
equ
irem
ents
–an
alys
is o
f in
–orb
it f
ligh
t da
ta–
anal
ysis
of
grou
nd
segm
ent
perf
orm
ance
–su
ppor
t th
e fa
ilu
re in
vest
igat
ion
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–in
–orb
it p
erfo
rman
ce a
nal
ysis
rep
ort
–le
sson
s le
arn
ed
NO
TE
ICD
= I
nte
rfac
e C
ontr
ol D
ocu
men
tS
EM
P =
Sys
tem
En
gin
eeri
ng
Man
agem
ent
Pla
nV
CD
= V
erif
icat
ion
Con
trol
Doc
um
ent
ECSS19 April 1996ECSS–E–10A
52
5.5
De
sig
n a
nd c
onf
igur
atio
n
Ph
ase
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
O
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–E
stab
lish
men
t of
Sys
tem
des
ign
con
cept
s
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–C
once
ptu
al S
yste
m d
esig
n
A
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–E
stab
lish
men
t of
Sys
tem
des
ign
bas
elin
e–
Tech
nol
ogy
asse
ssm
ent
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
yste
m D
esig
n B
asel
ine
–Te
chn
olog
y P
lan
B
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–Id
enti
fy I
nte
rfac
es o
f A
ssem
blie
s–
Gen
erat
e B
udg
ets
–S
elec
t st
anda
rd c
ompo
nen
ts–
Exa
min
e te
chn
olog
ies
–M
ater
ial s
elec
tion
, Mak
e or
Bu
y–
Com
plet
e pr
elim
inar
y dr
awin
gs f
or e
ach
su
bsys
tem
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–P
reli
min
ary
Sys
tem
an
d S
ubs
yste
m D
raw
ings
–In
terf
ace
Con
trol
Doc
um
ent
–B
udg
ets
–F
or C
riti
cal S
/S :
Sim
ula
tion
or
Bre
adbo
ard
Mod
els
–F
or C
riti
cal T
ech
nol
ogie
s : f
easi
bili
ty
C
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–B
alan
cin
g of
th
e de
sign
tak
ing
into
acc
oun
t co
st, s
ched
-u
le, p
erfo
rman
ce a
nd
risk
for
th
e li
fe c
ycle
–F
inal
isat
ion
of
the
phys
ical
arc
hit
ectu
re a
s an
inte
-gr
ated
det
aile
d de
sign
for
peo
ple,
pro
duct
s an
d pr
o-ce
sses
–C
hec
k de
sign
com
pati
bili
ty w
ith
ext
ern
al I
nte
rfac
es
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–D
etai
led
Des
ign
for
th
e S
tart
of
Man
ufa
ctu
re o
f F
ligh
t H
ardw
are
–Te
chn
olog
ical
Rea
din
ess
–P
roce
ss D
ocu
men
tati
on, M
ater
ial
Spe
cifi
cati
on, T
ools
an
d H
andl
-in
g P
roce
dure
s ve
rifi
ed
D
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–U
pdat
ing
of f
ligh
t st
anda
rd d
esig
n–
Mai
nte
nan
ce o
f do
cum
enta
tion
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–C
ompl
eted
Fli
ght
Sta
nda
rd D
esig
n B
asel
ine.
–C
ompl
eted
Pro
cess
Doc
um
enta
tion
, Han
dlin
g P
roce
dure
s, M
ater
ial
Spe
cifi
cati
on e
tc..
–A
s–B
uil
t S
tatu
s an
d It
ems
ECSS 19 April 1996
ECSS–E–10A
53
5.6
Verif
ica
tion
Ph
aseÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
0
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
upp
ort
to d
efin
itio
n o
f te
chn
olog
ical
asp
ects
an
d de
velo
pmen
t co
nce
pt, i
n-
clu
din
g ve
rifi
abil
ity
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–In
put
to d
evel
opm
ent
docu
men
tati
on
A
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
upp
ort
requ
irem
ent
asse
ssm
ent
–D
efin
e ve
rifi
cati
on m
eth
ods
and
asso
ciat
ed v
erif
icat
ion
str
ateg
ies
–D
efin
e m
odel
ph
ilos
oph
y–
Pre
pare
Har
dwar
e M
atri
x in
clu
din
g qu
alif
icat
ion
sta
tus
–G
ener
ate
a ve
rifi
cati
on p
hil
osop
hy
(pre
lim
inar
y pl
an)
–P
rovi
de in
puts
to
deve
lopm
ent
phil
osop
hy
for
the
prel
imin
ary
SE
MP
–C
oord
inat
e po
ssib
le lo
wer
leve
l con
trib
uti
ons
–S
upp
ort
the
gen
erat
ion
of
phas
e B
pla
nn
ing
and
cost
est
imat
e
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–In
put
to R
equ
irem
ent
Ass
essm
ent
Rep
ort
–In
put
to p
reli
min
ary
S E
Man
agem
ent
Pla
n–
Pre
lim
inar
y V
erif
icat
ion
Pla
n–
Inpu
t to
Ph
ase
B p
lan
nin
g &
cos
t es
tim
ate
B
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
upp
ort
anal
ysis
of
cust
omer
req
uir
emen
ts–
Su
ppor
t ge
ner
atio
n o
f S
yste
m S
peci
fica
tion
–P
repa
re s
yste
m v
erif
icat
ion
mat
rice
s–
Pre
pare
Tes
t R
equ
irem
ent
Spe
cifi
cati
on–
Su
ppor
t re
quir
emen
t al
loca
tion
& t
race
abil
ity
–S
upp
ort
gen
erat
ion
of
prel
imin
ary
low
er le
vel S
peci
fica
tion
s an
d re
leva
nt
veri
fica
tion
mat
rice
s–
Pre
pare
sys
tem
Ver
ific
atio
n P
lan
an
d V
erif
icat
ion
Con
trol
Doc
um
ents
(V
CD
)–
Coo
rdin
ate
the
prep
arat
ion
of
prel
imin
ary
low
er le
vel V
erif
icat
ion
Pla
ns
and
VC
D’s
–In
itia
te t
he
set–
up
of v
erif
icat
ion
dat
a ba
se–
Pro
vide
inpu
t fo
r th
e S
EM
P–
Su
ppor
t th
e pr
epar
atio
n o
f pr
ogra
mm
atic
doc
um
enta
tion
–S
upp
ort
the
gen
erat
ion
of
phas
e C
/D p
lan
nin
g an
d co
st e
stim
ate
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–In
put
to S
yste
m a
nd
low
er le
vel S
peci
fica
tion
s in
part
icu
lar
Ver
fica
tion
Mat
rice
s)–
Test
Req
. Spe
cifi
cati
on–
Sys
tem
Ver
ific
atio
n P
lan
–S
yste
m V
CD
–V
erif
icat
ion
dat
a ba
se–
Pre
lim
inar
y lo
wer
leve
l Ver
ific
atio
n P
lan
s &
VC
D’s
–In
put
to S
yste
m S
EM
P–
Inpu
t to
pro
gram
mat
ic d
ocu
men
tati
on–
Inpu
t to
ph
ase
C/D
pla
nn
ing
and
cost
con
tin
ued
ECSS19 April 1996ECSS–E–10A
54
Ph
aseÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
C
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
upp
ort
upd
atin
g of
Sys
tem
an
d lo
wer
leve
l Spe
cifi
cati
ons
–U
pdat
e Te
st R
equ
irem
ent
Spe
cifi
cati
ons
–F
inal
ise
Sys
tem
an
d lo
wer
leve
l Ver
ific
atio
n p
lan
s–
Upd
ate
Sys
tem
an
d lo
wer
leve
l VC
D’s
–P
erfo
rm p
erio
dic
asse
ssm
ent
of t
he
veri
fica
tion
pro
gram
me
(Ver
ific
atio
nC
ontr
ol B
oard
)–
Mai
nta
in V
erif
icat
ion
Dat
a B
ase
–M
onit
or lo
wer
leve
l qu
alif
icat
ion
ver
ific
atio
n a
ctiv
itie
s–
Su
ppor
t S
yste
m a
nd
low
er le
vel R
evie
ws
(PD
R, T
est
Rea
din
ess
Rev
iew
,TR
B)
–R
evie
w a
nd
appr
ove
low
er le
vel v
erif
icat
ion
doc
um
enta
tion
–G
ener
ate
firs
t S
yste
m I
nt.
& T
est
Spe
cifi
cati
ons
and
Pro
cedu
res
–C
oord
inat
e an
d m
onit
or s
yste
m v
erif
icat
ion
act
ivit
ies
–P
erfo
rm S
yste
m a
nd
low
er le
vel I
nt.
& T
est
on d
evel
opm
ent
mod
el(s
)–
Sta
rt S
yste
m a
nd
low
er le
vel I
nt.
& T
est
on q
ual
ific
atio
n m
odel
(s)
–M
onit
or d
efin
itio
n a
nd
proc
ure
men
t of
ver
ific
atio
n t
ools
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–In
put
to f
inal
Sys
tem
an
d lo
wer
leve
l Spe
c’s–
Fin
al S
yste
m a
nd
low
er le
vel V
erif
icat
ion
Pla
ns
–S
yste
m a
nd
low
er le
vel I
nt.
& T
est
Spe
cifi
cati
ons
and
Pro
cedu
res
for
Dev
elop
men
t/Q
ual
ific
atio
n m
o-de
ls–
Ver
ific
atio
n d
ata
base
–S
yste
m a
nd
low
er le
vel D
evel
opm
ent
Mod
els
–S
yste
m a
nd
low
er le
vel Q
ual
ific
atio
n M
odel
s–
Ver
ific
atio
n t
ools
con
tin
ued
ECSS 19 April 1996
ECSS–E–10A
55
Ph
aseÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Tas
ks
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Typ
ical
Ou
tpu
t
D
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–U
pdat
e an
d co
mpl
ete
syst
em a
nd
low
er le
vel V
CD
’s–
Per
form
per
iodi
c as
sess
men
t of
th
e ve
rifi
cati
on p
rogr
amm
e (V
CB
)–
Mai
nta
in v
erif
icat
ion
dat
a ba
se–
Mon
itor
low
er le
vel v
erif
icat
ion
acc
epta
nce
act
ivit
ies
–S
upp
ort
syst
em a
nd
low
er le
vel R
evie
ws
(Qu
alif
icat
ion
Rev
iew
, Fin
al A
ccep
t-an
ce R
evie
w)
–R
evie
w a
nd
appr
ove
low
er le
vel v
erif
icat
ion
doc
um
enta
tion
–C
oord
inat
e an
d m
onit
or s
yste
m v
erif
icat
ion
act
ivit
ies
–C
ompl
ete
syst
em a
nd
low
er le
vel I
nt.
& T
est
Spe
cifi
cati
ons/
Pro
cedu
res
–C
ompl
ete
Sys
tem
an
d lo
wer
leve
l qu
alif
icat
ion
an
d ac
cept
ance
act
ivit
ies
–G
ener
ate
syst
em a
nd
low
er le
vel V
erif
icat
ion
Rep
orts
for
qu
alif
icat
ion
an
dac
cept
ance
–P
rovi
de in
put
to p
has
e E
/F d
ocu
men
tati
on–
Su
ppor
t th
e ge
ner
atio
n o
f ph
ase
E/F
pla
nn
ing
and
cost
est
imat
e–
Mon
itor
pro
cure
men
t of
ver
ific
atio
n m
odel
s
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
yste
m a
nd
low
er le
vel V
CD
’s–
Sys
tem
an
d lo
wer
leve
l Ver
ific
atio
n R
epor
ts–
Sys
tem
an
d lo
wer
leve
l In
t. &
Tes
t S
peci
fica
tion
an
dP
roce
dure
for
qu
alif
icat
ion
an
d fl
igh
t m
odel
s–
Ver
ific
atio
n d
ata
base
–In
put
to p
has
e E
/F d
ocu
men
tati
on–
Inpu
t to
ph
ase
E/F
pla
nn
ing
and
cost
est
imat
e–
Sys
tem
an
d lo
wer
leve
l fli
ght
mod
els
–V
erif
icat
ion
too
ls
E/F
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–S
upp
ort
mis
sion
ope
rati
ons
and
disp
osal
act
ivit
ies
for
veri
fica
tion
asp
ects
–M
ain
tain
ver
ific
atio
n d
ata
base
–M
onit
or s
yste
m v
erif
icat
ion
du
rin
g pr
e–la
un
ch, o
n–o
rbit
, pos
t–la
ndi
ng
phas
es–
Gen
erat
e S
yste
m v
erif
icat
ion
rep
orts
for
abo
ve p
has
es–
Upd
ate
Sys
tem
VC
D–
Su
ppor
t S
yste
m R
evie
ws
(Lau
nch
Rea
din
ess
Rev
iew
, Com
mis
sion
ing
Re-
view
, En
d of
Mis
sion
)–
Coo
rdin
ate
poss
ible
ver
ific
atio
n s
upp
ort
from
low
er le
vels
–S
upp
ort
the
asse
ssm
ent
of o
pera
tion
s pe
rfor
man
ces
and
asso
ciat
ed f
ailu
rein
vest
igat
ion
s
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
–V
erif
icat
ion
Rep
orts
–V
CD
–In
put
to o
pera
tion
ass
essm
ent
–V
erif
icat
ion
dat
a ba
se
NO
TE
PD
R =
Pre
lim
inar
y D
esig
n R
evie
wS
E =
Sys
tem
En
gin
eeri
ng
SE
MP
= S
yste
m E
ngi
nee
rin
g M
anag
emen
t P
lan
TR
B =
Tes
t R
evie
w B
oard
VC
B =
Ver
ific
atio
n C
ontr
ol B
oard
VC
D =
Ver
ific
atio
n C
ontr
ol D
ocu
men
t
ECSS19 April 1996ECSS–E–10A
56
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
57
Annex A (informative)
DRD: system engineering management plan
Purpose :
Defines and describes approach to and details of System Engineering activities tobe performed by the Contractor and his lower tier contractors
Delivery at :
Proposal, SRR, PDR
Summary of Contents/Preparation Information :
The contractor Plan shall comply with Standard ECSS–E–10 ”System Engineer-ing of Space Programmes”.
The Plan shall cover all Engineering activities to be performed within the appli-cable contractual time and responsibility boundaries.
It shall highlight key engineering methods and tools to be applied and describe in-terfaces to external activities.
This Plan shall also reference and make use of the lower tier Engineering Manage-ment Plans and provide a coherent and consistent planning document for the en-tire Contractor programme.
The Plan Contents List shall be tailored to the specific needs of a Programme basedon the attached model.
TYPICAL CONTENTS LIST1 INTRODUCTION1.1 Scope1.2 Applicability2 APPLICABLE DOCUMENTS3 PROGRAMME OVERVIEW3.1 Objectives and Constraints3.2 Project Phases and Reviews3.3 Technical Organisation and Responsibility Allocation3.3.1 System3.3.2 Subsystems3.3.3 Assemblies and Units3.3.4 Software Products
ECSS19 April 1996ECSS–E–10A
58
3.3.5 Relations to Subsystem, Assembly, Unit Software and Services Contractors
3.3.6 Purchaser and Contractor Relations
3.4 Master Schedule4 APPROACHES & TECHNIQUES4.1 System Engineering Integration & Control4.1.1 System Engineering Management4.1.2 Engineering Discipline Integration4.1.3 Engineering Data Base4.1.4 Interface Management4.1.5 Budget and Margin Philosophy4.1.6 Technology4.1.7 Post Delivery Support4.1.8 Cost Effectiveness4.1.9 Risk Management4.1.10 Procurement Support approach4.1.11 Engineering Capability Assessment4.2 Requirement Engineering4.2.1 Specifications4.2.2 Requirement Process4.2.3 Requirement Management4.3 Analyses4.3.1 System Analyses4.3.2 Functional Analysis & Allocation4.3.3 Analysis Tools & Models4.4 Design & Configuration4.4.1 Design Process4.4.2 Architecture4.4.3 Configuration4.4.4 Design Tools4.5 Verification4.5.1 Verification Process4.5.2 Verification Strategy4.5.3 Verification Tools4.5.4 Verification Implementation4.6 System Engineering Interfaces4.6.1 Management
– Planning– Documentation & Data Exchange– Procurement– Change Management
4.6.2 Product Assurance– Dependability– Safety
4.6.3 Production4.6.4 Operations & Logistics
ECSS 19 April 1996
ECSS–E–10A
59
5 DISCIPLINE SPECIFICS5.1 System Engineering Integration Level
– Payload– Human Factor Engineering– Environment– Serviceability– Microgravity Control– etc.
5.2 Mechanical– Structures– Mechanisms– Fracture Control– Mechanical Ground Support Equipment– etc.
5.3 Propulsion & Reaction Control System5.4 Thermal–Environmental
– Thermal Control– Environmental Control & Life Support– Contamination Control– Fluid Ground Support Equipment– etc.
5.5 Avionics– Electrical Power Generation, Distribution & Storage– Electro–Magnetic Compatibility– Data Management– Optics– Communications– Harness– Electric Ground Support Equipment– etc.
5.6 Controls– AOCS– Robotics– Docking/Berthing– etc.
5.7 Software– Flight Software– Ground Software– Simulation– etc.
6 CRITICAL TECHNOLOGIES
ECSS19 April 1996ECSS–E–10A
60
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
61
Annex B (informative)
Organisation of system engineering Level 3
standards
System Engineering level 3 standards cover specific aspects of System Engineering of eithera procedural or a technical nature, and are believed to result in more economical or morecompliant products if implemented with an optimum, standardized approach.
The plan of these standards is therefore not meant to cover , even in the long term, the totalscope of System Engineering activities to a greater level of detail than ECSS–E–10, but onlythose aspects where detail standardization is economical and not overconstraining.
Except for the overall System Engineering process, Table B–1 groups standards per SystemEngineering function because a path per function is recommended for the screening oftechnical implementation requirements in a programme’s organisation phase.
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Table B–1: Level 3 System Engineering Standards
Number ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Title ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Scope
ECSS–E–10–01
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
System Engineering Pro-cess
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Theory of System Engineering (generic, not limitedto space applications) :
– System Engineering building blocks– Dynamics of the typical process ”engine”
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
System Engineering Integration and Control
ECSS–E–10–101
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Standard practice for in-terface management
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Guideline to the organisation of interface manage-ment :
– interface requirement documents– interface control documents– formal tools and mechanisms
ECSS–E–10–102ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
System Engineering ca-pability assessment
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
System Engineering capability, maturity measure-ment model, model description
ECSS–E–10–103ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Engineering data baserequirements
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
Continued
ECSS19 April 1996ECSS–E–10A
62
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Table B–1: Level 3 System Engineering Standards (continued)
NumberÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
TitleÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Scope
ECSS–E–10–104
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Environmental engineer-ing guidelines
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Guidelines for a correct interdisciplinary approach toenvironmental requirement assembly and design solu-tion
ECSS–E–10–105
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Natural and induced envi-ronments in space
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Objective models for each type of space environment,e.g. radiation, sun, debris, atmosphere, etc.
ECSS–E–10–106
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Human factors for spacesystems
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Statistics of human measures and performance for allactivities and environments associated with space
ECSS–E–10–107ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Human system integra-tion
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Guidelines for the implementation of design selectionsrespectful of human factors, in any item associatedwith physical human interface
ECSS–E–10–108ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Human–computer inter-face for space systems
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–109ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Design to cost ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Definitions and methodologies to derive technical re-quirements against limiting and firm cost constraints
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Requirements
ECSS–E–10–201ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Specification practice ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Guidelines to structure technical specifications of alllevels and spell out requirement
ECSS–E–10–202ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Requirement traceabilityprinciples
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Requirement traceability principles mechanics andtool requirements
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Analysis
ECSS–E–10–301ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Functional analysis ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Principles and methodologies of the functional analy-sis
ECSS–E–10–302ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Mathematical ModelsÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
System level requirements of mathematical models de-veloped for system analyses
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Design
ECSS–E–10–401
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Coordinate system andreference level for spacevehicles
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–402ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Drawing systemÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Requirements for the selection and setting up of adrawing system
ECSS–E–10–403
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Design requirements forCAE interfaces
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–404
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Guide to the software ar-chitectural design
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Guidelines to develop a project’s software architectureas part of an integrated system approach
Continued
ECSS 19 April 1996
ECSS–E–10A
63
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Table B–1: Level 3 System Engineering Standards (continued)
NumberÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
TitleÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
ScopeÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Verification
ECSS–E–10–501
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Verification guidelines formanned and unmannedspacecraft
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–502
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Test requirements forspace equipment
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–503
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Analysis, review of designand inspection require-ments for space equip-ment
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–504
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Requirements for verifica-tion tools, Ground Sup-port Equipment and facili-ties
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–505
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Requirements for assem-bly and integration
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS–E–10–506ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Environmental test meth-ods
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
Self–explanatory
ECSS19 April 1996ECSS–E–10A
64
(This page is intentionally left blank)
ECSS 19 April 1996
ECSS–E–10A
65
Annex C (informative)
System engineering documentation definitions
Analysis procedure
This document lists all the requirements to be verified by analysis, grouping themin categories detailing the Verification Plan activity sheets, with planning of theexecution and a definition of the associated procedures.
Analysis report
This document describes, for each analysis, assumptions, utilised methods, soft-ware and results and contains evidence to show that the relevant requirementsare satisfied.
Drawing Tree
A drawing tree reflect the drawings associated with the elements.
Hardware Matrix
The matrix identifying for each equipment the related qualification status and therequired models.
Integration & Test Procedure
This document provides detailed step–by–step instructions to the Int. & Testteams for conducting the int. and test activities in agreement with the Int. & TestSpecification requirements.
Integration & Test Specification
This document is prepared for each major integration and test activity describedin the Verification Plan task sheets with the aim of giving detailed integration andtest requirements.
Interface Control Document (ICD)
A document which contains the current baseline of detailed system internal andexternal interfaces, with reference to the IRD requirements.
It controls the interface requirement evolution and reflects in principle the de-tailed status of the interested interfaces against which each interface requirementwill be verified.
ECSS19 April 1996ECSS–E–10A
66
Interface Requirement Document (IRD)
Type of specification dedicated to internal and external system interface require-ments.
It describes of essential functional, performance, and physical requirements andconstraints at a common boundary between two or more functions or physicalitems.
It drives the interface management activities.
Specification Tree
The hierarchical structure of all the specifications applicable to a system and itsconstituents in the transition from customer needs to the complete set of productsand services that satisfy those needs.
Specification Preparation and Format Instructions
Self–explanatory
Test Requirement Specification
This document is a system support specification applicable to all verification levelscontaining the general test requirements in terms of type of test, sequences, mar-gins, durations, tolerances, screening policy and methodology.
Verification Control Document (VCD)
This document lists all the requirements to be verified with the selected methodsin the applicable phases at the defined levels and traces during the phase C/D, howand when each requirement is planned to be verified and is actually verified. TheVCD may be an output from the Verification Data Base.
Verification Matrix
Matrix associating to each requirement the selected verification methods for thedifferent verification levels in the applicable verification phases.
Verification Plan
This document is the master plan for the project verification process and demon-strates how the requirements will be verified by a coherent implementation ap-proach. The plan will cover the environmental test aspects.
Verification Report
This document gives evidence that the verification activities have been properlyperformed describing results and associated evaluation.
It could be either test, analysis, Review Of Design, inspection report or a combina-tion of them in the case where more than one of the methods is utilised to verifya requirement or a specific set of requirements.