Applicationimplementation of ECSS documents in projects

1
Application/implementation of ECSS documents in
projects

• ECSS Executive Secretariat

2
Content

• 1 Intended use of the 3 types of ECSS documents
• How to use standards
• 2.1 Application of standards Business
  agreements
• 2.2 The ECSS customer-supplier model
• 2.3 The consistent set of standards
• 2.4 Content of ECSS standards
• 2.5 Requirements
• 2.6 DRDs
• 3 Tailoring
• 3.1 Tailoring process
• 3.2 Tailoring tools
• 3.3 Flowing down requirements
• Requirement verification
• 4.1 Verification and validation
• 4.2 Verification objectives
• 4.3 Verification process
• 4.4 Verification methods
• 4.5 Verification documentation
• 4.6 Verification stages

3
1. Intended use of the 3 types of ECSS documents

• The types of ECSS documents, and their intended
  use and application is explained in ECSS-S-ST-00
  ECSS system Description and implementation
• Three types of documents in ECSS
• Standards
• Handbooks, and
• Technical Memoranda

4
1. Intended use of the 3 types of ECSS documents
Standards

• An ECSS Standard is written specifically for
  direct use in invitation to tender and business
  agreements for implementing space related
  activities.
• Its content is strictly limited to the statement
  of verifiable customer requirements, supported by
  the minimum descriptive text necessary to
  understand their context.
• Each Standard falls into one of three ECSS
  domains Management, Engineering, or Product
  Assurance, with its scope strictly limited to the
  subject being addressed within that domain, but
  accounting for the hierarchical nature of the
  ECSS System and its applicability as a set.

5
1. Intended use of the 3 types of ECSS documents
Handbooks and Technical memoranda

• Handbook
• Handbooks are non-normative documents providing
  background information, orientation, advice or
  recommendations.
• A handbook therefore contains advice about how
  properly to do something important and useful
  information about a subject.
• An ECSS handbook is a document related to one
  specific discipline or to a specific technique,
  technology, process or activity. It contains
  the best knowledge and practice on the subject
  and can contain
• Descriptions of the matters,
• Associated explanations and/or justifications,
• Rationale for using one or other method or
  technique,
• Examples of applications,
• Recognised/accepted values/characteristics.
• TWO types of handbooks (1) guidelines and good
  practices, and (2) Collection of data
• Technical Memorandum
• A Technical memorandum is a specific document
  providing useful information to the space
  community on a specific subject.
• It is prepared to record and present
  non-normative data which are not relevant for a
  standard or for a handbook or not yet mature to
  be published as handbook or standard.

6
1. Intended use of the 3 types of ECSS documents
What ECSS standards are not

• Handbooks - because they contain requirements
  directly applicable to establish project
  specifications
• Teaching books or encyclopedia for specific
  subjects
• Documents to be used independently/autonomously
  (except for some detailed standards) - for the
  ECSS standards, they are part of a system where
  standards are complementary and interconnected
• Their purpose is not to interfere with the
  internal organization of the suppliers or their
  quality system

7
1. Intended use of the 3 types of ECSS documents
Summary
Type
Intended use
Policy of ECSS members
Commitment to use the ECSS system of STANDARDS in
space projects by tailoring
Normative documents for direct use in invitation
to tender and business agreements
Standards
Non-normative documents providing background
information, orientation, advice or
recommendations
Handbooks
No commitment to use HBs and TMs. They can be
used as reference documents in projects. Individua
l projects may use them as normative documents if
so desired.
Non-normative documents providing useful
information on a specific subject. Mainly, for
material not yet mature to be published as
handbook or standard
TechnicalMemo
8
2. How to use standards2.2 The ECSS
customer-supplier model
9
2. How to use standards2.1 Application
Business agreements

• Applicability of ECSS documents
• The ECSS documents themselves do not have legal
  standing and they do not constitute business
  agreements.
• They are made applicable by invoking them in
  business agreements (most commonly in contracts).
  
• Applicability chain (see next slide)
• The applicability of standards and requirements
  is specified in the project requirements
  documents (PRDs), which are included in business
  agreements, which are agreed by the parties and
  binding them (For PRD, see ECSS-M-10C, 4.1.10.)
• The toplevel customers PRD forms the basis for
  the generation of all lower level customer PRDs.
• An integral part of a PRD, at any level, is the
  set of ECSS Standards tailored as necessary and
  documented in an ECSS Applicability Requirements
  Matrix"
• A supplier, at any level, is responsible for
  demonstrating compliance with the requirements in
  his customers PRD (e.g. by elaborating a
  compliance matrix), and ultimately for supplying
  a conforming product. The compliance to the PRD
  is presented in an Implementation Documents
  (IDs), for example project plans (e.g.
  management, engineering and product assurance)
  and compliance matrix.

10
2. How to use standards2.1 Application
Business agreements

• Business agreements
• Within the project, exchanges of products
  services are governed by business agreements,
  i.e. legally binding agreements between customer
  and supplier.
• They include the terms and conditions agreed
  between the parties, the rules by which business
  is conducted, the actors commitments and
  obligations for the provision of goods and
  services, the me-thods of acceptance and
  compensation, monetary, or otherwise.
• They are recorded in a variety of forms, such as
• Contracts,
• Memoranda of understanding,
• Intergovernmental agreements,
• Interagency agreements,
• Partnerships,
• Bartering agreements, and
• Purchase orders.

11
2. How to use standards2.3 The consistent set of
standards

• ECSS standards are not to be used in isolation
• The set of standards, plus the external
  standards adopted by ECSS, constitute a
  consistent set of standards for use in
  business agreements
• Consequences of this are
• ECSS standards are built to prevent
  contradictions (conflicting requirements)
  either internally, or externally between
  standards
• Repetitions between standards are avoided
• If some material existing in a standard is
  considered useful for a second standard, the
  material is referred, not repeated.
• Two types of references Normative (references
  from requirements) and informative/bibliograph
  y (references from descriptive text)

12
2. How to use standards2.4 Content of ECSS
standards

• Normative statements
• ECSS standards do contain requirements,
  identified by SHALL or SHALL NOT.
• ECSS standards exceptionally may contain some
  recommendations (which may be converted in
  requirements or deleted on a case by case base
  by tailoring), identified with SHOULD or SHOULD
  NOT
• ECSS standards may contain permissions (i.e.
  waivers or alleviations to existing
  requirements) identified by MAY and NEED NOT
• ECSS standards may contain definitions of terms
  used in requirements
• Descriptive material
• Its content is strictly limited to verifiable
  normative statements, supported by the minimum
  descriptive text necessary for a supplier to
  understand their context.
• In ECSS standards, normative statements and
  descriptive material are always clearly separated

13
2. How to use standards2.5 Requirements (1)

• Standards requirements are written to be clear,
  unambiguous, complete and individually
  identifiable
• Requirements are verifiable
• Normative cross references are be clear, specific
  and limited
• Requirements are neither repeat nor inconsistent
  with other requirements in the same or other
  Standards
• Requirements so obvious that if suppressed there
  is no variation in the contractual obligation,
  are avoided.
• Requirements are essential for an acceptable
  product, and not merely desirable requirements
• Requirements text is written in a concise way
• Recommendations are avoided in a Standard (the
  related general requirements is generally quoted
  and recommendations are included in Handbooks and
  cross referenced where necessary)

14
Requirements characteristics
2. How to use standards2.5 Requirements (2)

• A Requirement is a normative statement, which
  shall be complied with and which has the
  following characteristic it is to be clear,
  unambiguous, concise, verifiable, uniquely
  identifiable, complete (i.e. avoiding addition of
  explanatory notes), addressing a specific need
  and not multiple needs .

15
How to identify requirements
2. How to use standards2.5 Requirements (3)
1 - Requirements are individually identified
STRUCTURE
EXAMPLE 14.6.1a. Action A shall be
performed4.6.2a. Action B shall be performed
EXAMPLE 24.6.1a. Action A shall be performed
b. Action B shall be performed
INDIVIDUAL ITEMS
Each requirement can be identified by the number
of the clause, plus a minor letter. Example 1
includes the following 2 requirements 4.6.1a and
4.6.2a Example 2 includes the following 2
requirements 4.6.1a and 4.6.1b
16
Verbal Forms
2. How to use standards2.5 Requirements (4)
FORM TO USE FORMS TO AVOID
Requirement SHALL is to be/ is required to / is
mandatory, has to, must, may only only
is permitted SHALL NOT it is not allowed
permittedacceptable, ... It is not
possible, must not is not to
be Recommendation SHOULD it is recommended, it
is preferred ought to SHOULD NOT should be
avoided, it is not recommended only in
exceptional cases Permission MAY is
permitted NEED NOT it is not required Possibili
ty and CAN to be able, to be in the
position capability CANNOT to be unable. It is
impossible
Normative statements
17
DRD stands for Document Requirements Definition
2. How to use standards2.6 DRDs

• What is a DRD?
• A DRD is a Normative annex, specifying the
  content of a deliverable document. No other
  requirement is permitted in a DRD, or
  requirements on.
• What it is not!
• A DRD is strictly limited to identifying what is
  expected as a response to specific
  requirements contained in an ECSS Standard. A
  DRD does not include hidden, or implied
  additional requirements on a project
• A DRD does not address the delivery requirements
  of the response to the DRD (e.g. schedule,
  update frequency, number of copies, release
  authority, or who has to deliver it). These
  requirements are in the body text of the
  standard.
• A DRD does not contain requirements on the
  format or structure of the deliverable
  document (except in very few exceptional cases)

18
3. Tailoring3.1 Principles and process
How standards are used in a project - Tailoring

• Tailoring means that the list of standards and
  their content is analysed by the customer in
  order to
• Select the set of standards to be made applicable
  to the project, taking into account its
  specificity and constrains.
• identify those requirements in the individual
  standards which are not applicable to the
  project,
• modify or exceptionally add requirement for
  specific needs.
• For a specific project, standards are tailored
  according to the type and phase of the project,
  the acceptable risks, the project complexity,
  cost,

19
3. Tailoring3.1 Principles and process
20
3. Tailoring3.1 Principles and process
21
3. Tailoring3.2 Use of tailoring tools

• Tailoring tools under consideration DTT (Direct
  tailoring tool)
• Developed by ESA
• For voluntary use
• Capabilities
• Able to use a list of applicable standards
• Able to tailor the list of applicable standards
• Inclusion of project specific requirements
• Able to tailor the requirements of each
  individual standard
• Able to individually give a project specific
  number to each req.
• Able to present the information in different
  ways
• Neutral format
• DLR Tailoring tool
• Developed by DLR
• Provides the DTT capabilities, plus a the
  capability of performing a pre-tailoring in
  accordance with a number of parameters of the
  project
• DOORS Not an ad-hoc tailoring tool, but a tool
  for managing requirements. Neutral format

22
3. Tailoring3.3 Flowing down requirements

• An organization receives a PRD from his
  customer, and has to produced a set of PRDs,
  one per each of its suppliers
• The requirements in the PRDs to be provided to
  the suppliers shall be derived from the
  requirements in the PRD received from the
  customer
• During the flowing down, requirements can be
  transmitted down as is (e.g. qualitative
  requirements), apportioned (e.g. budgets),
  modified (e.g. concreted), or new added
  requirements.
• Correspondence between received (from customer)
  and transmitted requirements (to suppliers) is
  multijective a received requirement can be
  the origin of one or several transmitted
  requirements (which can go all to one supplier,
  or to several suppliers), and one transmitted
  requirement can be the consequence of one or
  several received requirements.
• Up- and down- traceability of the requirements
  is critical

23
4. Requirement verification4.1 Verification and
validation
Verification
Validation
confirmation through the provision of objective
evidence that specified requirements have been
fulfilled
confirmation, through the provision of objective
evidence that the requirements for a specific
intended use or application have been fulfilled
What
Who
Customer
Supplier
The supplier shall demonstrate to the customer
compliance with all the requirements specified in
the customers PRD
The customer ensures that the provided supply is
suitable for the use intended by him
Therefore, verification is a customer-supplier
issue and covered by ECSS system (E-10-02 and
E-10-03)
Validation is an customer internal issue, and
therefore not covered by ECSS system of standards
(it may be covered in the future by HBs)
Comments
If the requirements in the PRD do really collect
all the needs, successful verification will lead
to a successful validation
24
4. Requirement verification4.2 Verification
objectives

• The objectives of the Verification process are as
  follows
• to demonstrate the qualification of design and
  performance, as meeting the specified
  requirements at the specified levels
• to ensure that the product is in agreement with
  the qualified design, is free from workmanship
  defects and acceptable for use
• to confirm product integrity and performance at
  particular steps of the project life cycle
  (e.g. launch, commissioning, mission events
  and landing).
• to confirm that the overall system (including
  tools, procedures and resources) will be able
  to fulfil mission requirements

25
4. Requirement verification4.3 Verification
process

• Verification is a process gt composed of
  activities
• The process does not change the product itself,
  but the confidence
• The only output of each activity is the
  verification documentation, which serves to
  support this increasing confidence

26
4. Requirement verification4.4 Verification
methods

• 4 verification methods are recognized in
  ECSS-E-ST-10-02 (in order of confidence provided
• Test (which includes demonstration) (specifically
  covered by E-10-03)It consists of measuring
  product performance and functions under
  representative simulated environments. It
  includes the analysis of data derived from the
  test.
• Analysis (which includes similarity)It consists
  of performing theoretical or empirical evaluation
  using techniques agreed with the Customer (such
  as systematic, statistical and qualitative design
  analysis, modelling and computational simulation)
• Review-of design (ROD) It consists of using
  approved records or evidence (e.g. design
  documents and reports, technical descriptions,
  engineering drawings) that unambiguously show
  that the requirement is met.
• InspectionIt consists of visual determination of
  physical characteristics (such as constructional
  features, hardware conformance to document
  drawing or workmanship requirements, physical
  conditions, software source code conformance with
  coding standards).

27
4. Requirement verification4.5 Verification
documentation (2)

• Verification plan
• It contains the overall verification approach,
  the model philosophy, the product matrix, the
  verification strategies for the requirements (the
  interrelation between different
  methods/levels/stages of verification to be used
  to demonstrate status of compliance to
  requirements), the test, inspection, analysis and
  review-of-design programme with the relevant
  activity sheets and planning, the verification
  tools, the verification control methodology, the
  involved documentation, the verification
  management and organization.
• Verification approach
• In generating the verification approach, the
  supplier conducts the following steps
• Identify what are the products and
  requirements subject of the verification process
• Identify How to verify them by considering the
  methods stated in the technical specification
• Identify When to implement by applying the
  chosen verification strategy.
• These steps are generally conducted in an
  iterative process based on technical, cost and
  schedule considerations, ensuring that the
  approach is agreed by both the supplier and the
  customer.

28
4. Requirement verification4.5 Verification
documentation (3)
Model philosophy definition of the optimum
number and the characteristics of physical models
required to achieve confidence in the product
verification with the shortest planning and a
suitable weighting of costs and
risks Verification strategy For each
requirement to be verified, the verification
strategy shall be defined in terms of the
combination of the selected verification methods
for the different verification levels at the
applicable verification stages in the initial
issue of the Verification Control Document (VCD)
also called verification matrix, for approval by
the Verification Control Board (VCB). Verificatio
n stages The verification process is implemented
in subsequent verification stages along the
project life cycle. The stages depend upon
project characteristics and identify a type of
verification. The verification stages are
qualification, acceptance, prelaunch, inorbit
(including commissioning) and postlanding.
29
4. Requirement verification4.5 Verification
documentation (4)
Verification Control Document It lists the
requirements to be verified with the selected
methods in the applicable stages at the defined
levels. It includes the Verification Matrix. The
VCD is a living document and provides
traceability during the phase C, D and E, how and
when each requirement is planned to be verified
and is actually verified. The VCD becomes part of
the EIDP, as detailed in ECSS-Q-20.
30
4. Requirement verification4.5 Verification
documentation (5)
Verification Reports Test report It describes
test execution, test and engineering assessment
of results and conclusions in the light of the
test requirements (including pass-fail
criteria). It contains the scope of the test, the
test description, the test article and sep-up
configuration, and the test results including the
asrun test procedures, the considerations and
conclusions with particular emphasis on the
closeout of the relevant verification
requirements including deviations. Analysis
report It describes, for each verification
analysis, the relevant assumptions, utilized
methods and techniques. It provides the results
and supporting evidence Review-of-design and
Inspection reports They describe each
verification activity performed for reviewing
documentation. They contain proper evidence that
the relevant requirements are verified and the
indication of deviations. The inspection report
may be embedded in the test report if the
verification by inspection is carried-out in
combination with testing. Verification report It
is prepared when more than one of the defined
verification methods are utilized to verify a
requirement or a specific set of requirements. It
reports the approach followed and how the
verification methods were combined to achieve the
verification objectives.
31
4. Requirement verification4.6 Qualification and
acceptance

• Qualification is used to demonstrate that the
  design, including margins, meets the applicable
  requirements
• Acceptance is used to demonstrate compliance of
  specific units to the design
• Qualification is carried-out on hardware and
  software which is representative of the end item
  configuration in terms of design, materials,
  tooling and methods
• Acceptance shall be carried-out on the final
  hardware and software

32
4. Requirement verification4.6 Qualification and
acceptance

• QUALIFICATION BY SIMILARITY PRODUCT CATEGORIES
• The already qualified product was not qualified
  by similarity.
• The product to be verified belongs to category A
  or to category B of the following Table, but no
  testing is required to achieve qualification.

 JA1AI Didier to provide Eursopace consolidated
table
33
5. Feedback

• ECSS users feedback is the primary source for
  maintaining and enhancing the ECSS System,
  because they provide information on how ECSS
  documents were applied and on how requirements
  evolved during project life cycle.
• In addition to user feedback provided during the
  development of ECSS documents, following feedback
  is expected
• The set of requirements tailored from ECSS
  documents to the project specificities and
  made applicable as part of the business
  agreement(s). For example, this can be
  documented into an ECSS Applicable Requirements
  Matrix (EARM).
• Status of compliance with respect to the above
  set of ECSS requirements. This can be
  documented into an ECSS Compliance Matrix (ECM).
  This matrix provides, during the development
  phase, the actual indication of compliance.
• Change proposals to ECSS documents or to the
  ECSS System as a whole, provided in the form
  of an ECSS Change Request at any time.

34
Thank you for your attention

• Any Questions?