ecss-e-10a system engineering (19 april 1996)

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.


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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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.


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


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.


12


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


14


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


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


18


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


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.


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.


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


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


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.


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.


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.


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


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.


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


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).


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.


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

.


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

.


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

.


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


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


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


56


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


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


60


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


Engineering data baserequirements


Self–explanatory

Continued


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


Human–computer inter-face for space systems


Self–explanatory


Design to cost ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Definitions and methodologies to derive technical re-quirements against limiting and firm cost constraints


Requirements


Specification practice ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Guidelines to structure technical specifications of alllevels and spell out requirement


Requirement traceabilityprinciples


Requirement traceability principles mechanics andtool requirements


Analysis


Functional analysis ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Principles and methodologies of the functional analy-sis


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


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


Environmental test meth-ods


Self–explanatory


64


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.


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.