EN 9208:2021

SLOVENSKI STANDARD
01-december-2021
Aeronavtika - Vodenje programov - Izražanje potreb - Navodilo in oblika za
(potrebe) tehnične specifikacije
Aerospace series - Programme management - Expression of need - Guidance on and
format for (Need) Technical Specification
Luft- und Raumfahrt - Programm-Management - Bedarfsbekundung - Anleitung und
Format für die (Bedarfs-)Technische Lieferbedingung
Série aérospatiale - Management de programme - Expression du besoin - Guide pour
l'élaboration de la spécification technique de besoin
Ta slovenski standard je istoveten z: EN 9208:2021
ICS:
03.100.01 Organizacija in vodenje Company organization and
podjetja na splošno management in general
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 9208
EUROPEAN STANDARD
NORME EUROPÉENNE
October 2021
EUROPÄISCHE NORM
ICS 49.020
English Version
Aerospace series - Programme management - Expression
of need - Guidance on and format for (Need) Technical
Specification
Série aérospatiale - Management de programme - Luft- und Raumfahrt - Programm-Management -
Expression du besoin - Guide pour l'élaboration de la Bedarfsbekundung - Anleitung und Format für die
spécification technique de besoin (Bedarfs-)Technische Lieferbedingung
This European Standard was approved by CEN on 23 August 2021.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2021 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9208:2021 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 List of acronyms . 8
5 Objectives of the (Need) Technical Specification (N)TS . 9
5.1 Purpose of the customer’s expression of need . 9
5.2 Role and contractual nature of the (N)TS . 10
6 Principles for drawing up a (N)TS . 10
6.1 General . 10
6.2 Responsibility for drawing up the (N)TS . 10
6.3 (N)TS elaboration process . 11
6.3.1 Preparatory stage . 11
6.3.2 Description of the process . 11
6.3.3 Position in programme phasing and scheduling . 12
6.3.4 Principles for requirement breakdown and allocation according to the product
breakdown structure . 13
6.4 Rules on the expression of requirements . 14
6.4.1 Requirement quality criteria . 14
6.4.2 Format of the requirements . 14
6.4.3 Concepts of flexibility for requirements . 15
7 Content of the (N)TS . 16
7.1 General remarks . 16
7.2 Product concept . 16
7.3 Scope . 16
7.4 Context of use . 16
7.4.1 Expected missions . 16
7.4.2 Operational context and operational environment . 16
7.4.3 Life profile . 16
7.4.4 Operational scenarios . 16
7.5 Documents and terminology (as subclause of the (N)TS) . 17
7.6 Technical requirements. 17
7.6.1 Functional requirements. 17
7.6.2 Lifetime requirements . 18
7.6.3 RAMS requirements . 18
7.6.4 Product protection requirements . 20
7.6.5 Human factors requirements. 21
7.6.6 Requirements relating to logistic support and in-service operations of the product . 22
7.6.7 Requirements on resistance to the environmental conditions . 23
7.6.8 External interfaces requirements . 23
7.6.9 Design constraints and imposed solutions . 24
7.7 Requirements for result assurance . 25
7.7.1 General . 25
7.7.2 Requirements relating to Definition Justification and Qualification pronouncement . 25
7.7.3 Requirements relating to the conditions of acceptance of specimens of the product . 25
8 Updating of a (N)TS . 26
Annex A (informative) Relations between FPS and (N)TS . 27
Annex B (informative) Mapping with CMMI-Acquisition and CMMI-Development models . 28
Annex C (informative) Overview of the NATO Architecture Framework (NAF) . 29
Annex D (informative) Architecture views for human factors . 32
Annex E (informative) Contents suggested for a (N)TS . 33
Annex F (informative) Standards or guides for safety studies . 34
Annex G (informative) Detailed requirements relating to logistic support and in-service
operations of the product . 35
G.1 User support . 35
G.1.1 Requirements relating to user technical documentation (UTD) . 35
G.1.2 Requirements relating to user training and learning . 35
G.1.3 Requirements relating to user support (Helpdesk Service) . 35
G.2 Customer support . 35
G.2.1 Requirements relating to asset management on behalf of the customer . 35
G.2.2 Requirements relating to technical support or service provision. 36
G.3 Operational services . 36
G.3.1 Requirements relating to product deployment . 36
G.3.2 Requirements relating to product operation . 36
G.3.3 Requirements relating to operation incident treatment . 36
G.3.4 Requirements relating to availability and service continuity follow-up . 36
G.4 Analysis of logistic support, logistics and maintenance in operational condition . 36
G.4.1 Requirements relating to logistic support analysis . 36
G.4.2 Requirements relating to logistics . 37
G.4.2.1 Requirements relating to the product supply chain . 37
G.4.2.2 Requirements relating to packaging, handling, storage and transport (EMST) . 37
G.4.2.3 Requirements relating to spare, consumable and ingredient management . 37
G.4.2.4 Requirements relating to support means (test means and platform tooling, except
training platform) . 37
G.4.3 Requirements relating to maintenance in operational condition . 38
G.4.3.1 Requirements on in-use product observability and data collection . 38
G.4.3.2 Requirements relating to product maintenance (repair, spare, change, etc.) . 38
G.4.3.3 Requirements relating to obsolescence management . 38
Annex H (informative) Standards and guides related to integrated logistic support (ILS)
requirements . 39
Bibliography . 40

European foreword
This document (EN 9208:2021) has been prepared by the Aerospace and Defence Industries
Association of Europe - Standardization (ASD-STAN).
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by April 2022, and conflicting national standards shall be
withdrawn at the latest by April 2022.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
1 Scope
This document belongs to the documents going along with the EN 9200 relating to Project Management
Specification.
The aims of this document are as follows:
— to specify/remind the concept of (Need) Technical Specification (N)TS;
— to define the principles and conditions for drawing up, approving, using and updating a (N)TS;
— to propose a template of (N)TS.
The template identifies topics and types of related requirements to be covered in a (N)TS without being
completely exhaustive or mandatory. It is analysed like a check-list and tailored according to the type of
the product of interest, the context of the bodies involved and the contractual details.
The principle of drawing up a (N)TS applies to both tangible and intangible products (e.g. services).
The customer/supplier relationship addressed by these principles may also apply within a single
organization. The concepts of customer and supplier are discussed in this document without distinction
between internal or external relationship.
This document implements and adapts to the context the EN 16271 standard, in order to meet the
specific needs of the aeronautical field and more generally the needs of other fields.
This document is more explicit about certain aspects of the ISO/IEC/IEEE 29148 document dedicated to
requirements engineering, such as the responsibility for drawing up a (N)TS on a contractual basis and
also the process of drawing it up within a programme (stages and milestones). It also supplements the
technical specification framework proposed by ISO/IEC/IEEE 29148, in particular with requirements
relating to safety of operation and result assurance.
The relationships existing between Functional Performance Specification (FPS) and (N)TS for
expression of needs are given in Annex A.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 9200, Aerospace series - Programme management - Guidelines for project management specification
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 9200 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
environmental agent
one of the physical, chemical, biological, etc. phenomena that may have direct or indirect, immediate or
delayed, effect on living beings, human activities and systems or their operation
[SOURCE: NF X 50-144-1]
3.2
need
what is necessary for, or desired by, the user
Note 1 to entry: A need may be explicit or implicit; it may be existing or potential.
Note 2 to entry: “Implicit” means that it is usual or a common practice for all the parties concerned.
[SOURCE: Adapted from EN 16271]
3.3
functional performance specification
FPS
document in which the needs are listed in terms of service functions and constraints
Note 1 to entry: Drawing up a FPS implies that a functional analysis has been able to clearly define the users’
needs.
Note 2 to entry: Assessment criteria and their performance levels are defined for each of these functions, when
relevant and possible. Each performance level is expressed with a certain degree of flexibility.
[SOURCE: Adapted from EN 16271]
3.4
constraint
externally imposed limitation on requirements, design, or implementation or on the process used to
develop or modify a product or on any other provision
Note 1 to entry: A constraint is a factor that is imposed on the solution by force or compulsion and may limit or
modify the choice of solution.
Note 2 to entry: Constraints may come from authoritative texts (laws, regulations, standards, market
demand, etc.).
[SOURCE: Adapted from ISO/IEC/IEEE 29148]
3.5
life cycle
set of phases in the life of a product, from the expression of need until disposal
Note 1 to entry: The product can be firstly conceptual then physical.
Note 2 to entry: The life cycle typically includes the following phases:
— Initial expression of need;
— feasibility;
— definition;
— development;
— production;
— operation;
— disposal.
Note 3 to entry: Notion not to be confused with life profile.
3.6
requirement
statement that translates or expresses a need and its associated constraints and conditions
[SOURCE: ISO/IEC/IEEE 29148]
3.7
special requirements
those requirements identified by the customer, or determined by the organisation, which have high
risks of not being met, thus requiring their inclusion in the operational risk management process
Note 1 to entry: Factors used in the determination of special requirements include product or process
complexity, past experience, and product or process maturity.
EXAMPLE performance requirements imposed by the customer that are at the limit of the industry’s
capability, or requirements determined by the organization to be at the limit of its technical or process capabilities
[SOURCE: Adapted from EN 9100]
3.8
interface
boundary shared between two products, or two product parts, which has physical and/or functional
exchanges
3.9
performance
measurable characteristic(s) of a product
3.10
life profile
chronological description of the use situations in which a physical product is expected to be found, from
ex-factory to disposal
Note 1 to entry: By situation, we mean: transport, handling, storage, maintenance, operational use., with all
environmental conditions, durations and respective occurrences.
Note 2 to entry: The life profile is described for product/customer or product/job couples. For a given product,
there may be several life profiles depending on the considered concepts of use or deployments.
Note 3 to entry: Not to be confused with life cycle.
3.11
operational scenario
description of an imagined sequence of events that includes the interaction of the product or service
with its environment and users, as well as interaction among its product or service components
Note 1 to entry: Operational scenarios are used to evaluate the requirements and design of the product and to
verify and validate the product.
[SOURCE: Adapted from ISO/IEC/IEEE 24765]
3.12
(need) technical specification
(N)TS
contractual document drawn up by the customer, intended for the supplier, in which the customer
expresses his needs (or the needs he has been instructed to convey) in terms of technical requirements
Note 1 to entry: The (Need) Technical Specification may also establish the conditions to ensure that these
requirements are met.
4 List of acronyms
AIS Analogue Interface Sheet
ARINC Aeronautical Radio INCorporated
BIT Built In Test
CMMI Capability Maturity Model Integration
DIS Digital Interface Sheet
EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) — Expression of need and
Identification of Safety Objectives
EMST (Emballage Manutention Stockage Transport) — Packaging Handling Storage Transport
FEROS (Fiche d’Expression Rationnelle des Objectifs de Sécurité) — Rational expression of Security
Objectives Statement
FPS Functional Performance Specification
HUMS Health and Usage Monitoring System
ICD Interface Control Document
ILS Integrated Logistics Support
IRS Interface Requirement Specification
LRU Line Replaceable Unit
MEHARI (Méthode Harmonisée d’Analyse des Risques) — Harmonized Risk Assessment Methodology
MTBF Mean Time Between Failures
MTTR Mean Time To Repair
NAF NATO Architecture Framework
NATO North Atlantic Treaty Organization
(N)TS (Need) Technical Specification
NRBC Nuclear, Radiological, Bacteriological, Chemical
PTS Product Technical Specification
QoS Quality of Service
RAMS Reliability, Availability, Maintainability and Safety
REACh Registration Evaluation and Authorization of Chemicals
RFID Radio-Frequency IDentification
RoHS Restrictions of Hazardous Substances
SLA Service Level Agreement
TRL Technology Readiness Level
UTD User Technical Documentation
5 Objectives of the (Need) Technical Specification (N)TS
5.1 Purpose of the customer’s expression of need
The (N)TS is drawn up under the customer’s responsibility (see 6.2) and its purpose is to formalize the
needs in technical terms. A (N)TS attached to a contract results from negotiations between the
customer and the supplier. It reflects the compromise between technological feasibility, performance,
imposed solutions, total cost, realization duration and risks.
NOTE 1 The total cost includes non-recurring costs (related to design, development, etc.) and recurring costs
(related to manufacturing, purchasing, operation, support, etc.) over the entire life cycle of the product.
It expresses the technical requirements over the entire life cycle of the product:
— functional and performance requirements;
— lifetime requirements;
— RAMS requirements (reliability, availability, maintainability, safety);
— product protection requirements including information security;
— human factors requirements;
— requirements relating to logistic support and in-service operations of the product;
— requirements on resistance to the environmental conditions;
— external interfaces requirements;
— design constraints and imposed solutions.
It can also express the requirements regarding result assurance:
— relating to definition justification and qualification pronouncement;
— relating to the conditions of acceptance of specimens of the product.
NOTE 2 The expression of need may change according to the phases of the life cycle. It could be considered
compared to expected intermediate supplies, which may be a model, prototype, document, etc. up to the
operational product. Thus mock-ups, prototypes and different versions of the product, which are to be supplied
under contract and which differ from the operational product due to special requirements or tolerances, may be
the subject of a separate (N)TS or a document showing the deviations compared with the (N)TS of the operational
product.
The (N)TS requirements are those necessary and sufficient for a supplier to be able to draw up, if
necessary, its own Product Technical Specification (PTS) and establish a product definition that fulfils
the need.
These requirements are mainly formalized in terms of functions and performance expected from the
product to be designed and defined, bearing in mind the identified risks accepted by the parties
(see 6.1).
It is recommended to take into account the general requirements expressed in the higher-level (N)TS
for each level of the product breakdown structure (see 6.3.4). These general requirements may be:
component policy, marking rule, documentation, etc.
To understand the origin of the requirement, and also how the (N)TS of the product can be integrated in
a larger system (“Where does this need come from? What about this restriction? Why this
requirement?”), the customer should ensure traceability of the requirements from the top-level
(including the case where the product belongs to a larger system, as in the case of systems of systems)
down to the (N)TS appended to the contract. It may also be wise to establish traceability links between
decisions (emails, report, etc.) and the (N)TS requirements, in a requirement justification file for
example.
The Aeronautical Quality Management System standards (EN 9100 and EN 9110) introduce the concept
of “special requirements” for certain requirements (see definition). This concept emphasizes the high
risk of not being able to meet a requirement.
This kind of requirements (“special requirements”) may be determined either by the customer (in the
(N)TS) or by the supplier (in the PTS) and implies these requirements to be dealt with via the risk
management process of the customer and/or supplier.
In order to answer the various questions such as “is this requirement the right one?” it is recommended,
where applicable, to ensure validation of the requirements (using ARP4754A/ED-79A) against the
different expressions of need regarding the context where the product will take place.
5.2 Role and contractual nature of the (N)TS
The (N)TS serves as a contractual basis between a customer and its supplier. The (N)TS allows the
supplier to design and define the product. This product can be developed, modified or selected from a
portfolio of existing products, as long as it fulfils the requirements expressed by the customer.
Based on the customer/supplier relationship, the (N)TS is the reference document that enables the
customer to
— express his need for the supplier in terms of results and not solution,
— pronounce the decision concerning qualification of the product definition and, reciprocally, enables
the supplier to justify the product definition by means of analyses or tests,
— process the technical changes in the product definition; the (N)TS is therefore an element of the
reference configuration of the product (see EN 9223-100 and its accompanying documents) and
— decide on requests for waivers or deviation (see EN 9223-105) if elements of the Definition Data
File are not sufficient to decide on this request.
The (N)TS is a part of the contract; the contract also specifies other types of requirements (means to be
implemented, work packages, programme management requirements, etc.).
NOTE For organisations which follow CMMI models, Annex B shows how CMMI models map to the (N)TS.
6 Principles for drawing up a (N)TS
6.1 General
(N)TS requirements are the result of iterative and, as far as possible, collaborative work based among
other considerations on risk analysis (see EN 9239), performed by both the customer and the supplier.
The goal is to reach a compromise between the customer requirements and industry ability to meet
them, via different proposals of candidate suppliers (performance, costs and deadlines).
6.2 Responsibility for drawing up the (N)TS
Within the customer/supplier relationship, (N)TS requirement elaboration is under customer
responsibility.
NOTE Even if the customer delegates the task of drawing up the (N)TS to a supplier (often under a specific
contract), the document will remain the customer responsibility.
The supplier in turn may translate the customer requirements in a designer (supplier) language and
supplement them with derived requirements related to the chosen solution and the supplier constraints
(product policy, re-use, etc.). In this case the resulting document is the Product Technical Specification
(PTS). This document is the entry point of the product design process which leads to the establishment
of its Definition Data File (DDF).
In all cases, the product definition shall be justified against the Customer (N)TS.
6.3 (N)TS elaboration process
6.3.1 Preparatory stage
It is recommended that a functional analysis of need, possibly supplemented by an architecture
description, be carried out before drawing up a (N)TS. This is to identify the various expected functions
and to express the quantitative and qualitative requirements for each of the functions, for example in a
Functional Performance Specification (FPS).
It is also recommended that information from other programmes be considered before drawing up the
(N)TS, in order to encourage reuse of proven solutions, lessons learned and technology selection based
on readiness levels with regards to the specific programme.
Within a given programme, the preliminary work products (studies results, mock-ups, etc.) resulting
from upstream studies (ILS study, RAMS study, operational concept development and
experimentation, etc.), shall be planned and specified in dedicated (N)TS with the right level of detail,
for reuse in the scope of the final product.
In all cases, the reused solution should meet the requirements of the new programme. It should be
checked that the features of the reused solution not specified in the (N)TS do not lead to negative
consequences (in terms of costs, deadlines, performance, reliability, etc.).
6.3.2 Description of the process
The result of the elaboration process of a (N)TS is a set of technical requirements intended to be
included in the development contract.
The essential stages of this process are (see Figure 1)
— the definition of the requirements, with identification of the special requirements (see 3.7 and 5.1),
— their analysis and negotiation with the potential supplier(s) and
— incorporation of the (N)TS into a contract.
Key
Documents under customer’s responsibility

Documents under supplier’s responsibility

Figure 1 — Fundamental steps of a (N)TS elaboration process
6.3.3 Position in programme phasing and scheduling
6.3.3.1 General
A (N)TS is drawn up progressively with several editions linked to the programme’s milestones (see
Figure 2). This process is performed at each level of the product breakdown structure. The main
editions are the preliminary (N)TS and the reference (N)TS, described below.
6.3.3.2 Preliminary (N)TS
The preliminary (N)TS sets out the initial need as requirements that are usable by designers. The
preliminary (N)TS is baselined at the end of the feasibility phase. Its purpose is to be used by potential
suppliers to draw up bids for the customer. The preliminary (N)TS allows the customer to evaluate the
different bids.
The ability to convert the need expressed in the preliminary (N)TS into an achievable solution concept
(with regards to the technical aspect, cost, deadlines and organization) is generally evaluated in a
Feasibility Review. This review enables the definition phase to be launched.
6.3.3.3 Reference (N)TS
The reference (N)TS is elaborated from the preliminary (N)TS, supplemented with requirements issued
from more detailed studies and resulting from trade-offs performed with candidate supplier(s). It is
baselined at the end of the definition phase (preliminary design process) and is incorporated in a
contract at the latest before the development phase (i.e. before the start of the detailed design process).
NOTE Detailed studies performed during the (N)TS elaboration may concern environmental conditions
(adaptation of the product to its environment), information required for the interfaces, logistical support analysis
studies, qualification requirements, ability to meet performance requirements bearing in mind tolerance margins,
RAMS studies, etc.
The product (N)TS edition presented at the Preliminary Design Review (see RG.Aéro 000 67) is linked
to the preliminary (N)TS documents of its components within the chosen concept of architecture. At the
end of the review, it is approved as reference for development of the product and becomes the
reference (N)TS.
The reference (N)TS should be managed in configuration in accordance with the methods described in
Clause 8 of this document.
Figure 2 — Positioning of (N)TS editions according to project phasing and scheduling
6.3.4 Principles for requirement breakdown and allocation according to the product breakdown
structure
All the (N)TS of the product components are established according to the product breakdown structure,
so that every component needing to be obtained from a third party has a (N)TS. This principle applies
whatever the component level in the product breakdown structure.
The decomposition process of the product involves breakdown and allocation of the requirements
expressed in the product (N)TS into necessary and sufficient requirements for its components.
The requirement allocation results from arbitrations requiring suitable analyses (risks analyses, cost
analyses, feasibility analyses, availability analyses, etc.).
The requirements allocated to a given level of the product breakdown structure should be traced to the
higher-level requirements.
However, some requirements at a given level may be a result of a design choice at that level of the
breakdown structure and consequently not traceable to the higher level. These are called derived
requirements. In this case, the assumptions related to these requirements need to be made explicit.
This is particularly the case when the breakdown process creates new interfaces with generation of
associated requirements assigned to the concerned components. See documents DO-178C or
ARP4754A/ED-79A for more information on the concept of derived requirements.
6.4 Rules on the expression of requirements
6.4.1 Requirement quality criteria
As the (N)TS is the expression of the requirements which shall be fulfilled by the product, these
requirements should be
— identified (marked by a unique identifier),
— atomic (avoid grouping together several requirements in the same statement),
— non-redundant (do not express the same requirement several times, possibly with different
statements),
— non-ambiguous (avoid multiple interpretations of the statements),
— verifiable, either theoretically (calculation, modelling, etc.) or experimentally (tests, set of
tests, etc.),
— complete (address all the requirements in the product (N)TS, including references to other
separate documents) and
— justifiable (in a separate document).
The scope of validity of the requirements should be specified, stating the conditions of application and
cases of exclusion as far as possible.
Any quantified performance requirement should have a tolerance range around the target value. This
range represents uncertainties relating to knowledge of the product or its actual environment, to means
of design, manufacture, measurement, etc.
For a full list of quality criteria in the expression of a requirement, refer to the ISO/IEC/IEEE 29148
standard about requirement engineering.
The main pitfalls to be avoided are over-specification, under-specification, confusion between needs
and solution, insufficient maturity of the expression of needs, lack of customer/supplier agreement, etc.
Only the applicable and relevant subclauses of reference standards, should be quoted.
6.4.2 Format of the requirements
A requirement may be expressed in text or graphic form, within a document or model (e.g. a chart,
digital mock-up or simulation model).
Architectural frameworks (see Annex C) can help formalizing part of requirements with viewpoints
which reflect stakeholder concerns:
— user viewpoint: the operational view (describes operational activities and concept of use of the
solution described with scenarios);
— acquirer viewpoint: the programmatic view (describes activities and supplies in accordance with
the phasing and scheduling of the programme) and capability view (functionalities of the product to
be acquired in accordance with the phasing and scheduling of the programme).
The following architectural views may also be used to formalize the constraints on solutions, processes
and procedures that are imposed or to be reused, especially in the case of renovation, transformation or
work reassignment contracts:
— designer viewpoint on the initial product: the system view (functional and structural
representation;
— manufacturer viewpoint on the initial product: the technical view (taking account of constraints in
terms of standards to be applied or mandatory solutions).
The list of views identified as being relevant in (N)TS elaboration is provided in Annex C and Annex D.
6.4.3 Concepts of flexibility for requirements
6.4.3.1 In the preliminary (N)TS
During the supplier consultation stage, it is recommended that a degree of flexibility be assigned to each
requirement, so that the requirements may be put in hierarchical order in terms of obligation to be met.
This ranges from the lowest level in terms of imperativeness, i.e. “optional”, “desirable” or “nice to have”
up to the highest level, i.e. “mandatory”, “essential“, “guaranteed”, etc. Intermediate levels will be
determined, e.g. “important”, “significant”.
This concept of flexibility allows to keep proper candidates who meet a at least the mandatory
requirements.
It also enables to discriminate between bids which are equivalent in terms of mandatory requirements.
NOTE Degrees of flexibility such as the following may be introduced:
— mandatory;
— important;
— nice to have.
This concept of flexibility disappears in the reference (N)TS in which all the requirements shall be
fulfilled by the supplier.
6.4.3.2 In the reference (N)TS
In the particular case of performance, another concept of flexibility may lead to the specification of two
levels of expected performance for the same requirement:
— a performance level required by contract (which requires a result achievement);
— a target level of performance (which requires a commitment on means and best-effort).
NOTE For commitment on means, the supplier has to implement all possible means to reach the required
objectives.
7 Content of the (N)TS
7.1 General remarks
The suggested contents of a (N)TS are given in Annex E. If necessary, the structure may be tailored to fit
in with the formalism of the architectural frameworks.
Depending on the needs, some of the following subclauses may be split in dedicated documents
(e.g. integrated logistic support, result assurance, information security, interfaces, etc.).
7.2 Product concept
This subclause presents the concept and purpose of the product required by the contract.
7.3 Scope
This subclause defines the scope of application of the (N)TS of considered product with its concerned
included and excluded versions (in terms of Configuration Management). This subclause is particularly
important in the case of large programmes which involve many changes over a long period.
7.4 Context of use
7.4.1 Expected missions
This subclause describes the expected missions of the product required by the contract.
7.4.2 Operational context and operational environment
This subclause defines the scope of use that the product will have to fit in (context and period of
operational use, limits, criticality, location of use, place of the product in the operational environment
where it will be integrated, etc.). This enables the requirements to be considered into the context of use
of the product, and so to be better understood.
The other products which interface directly with the product concerned will be identified in this part.
NOTE Information on general use is necessary in case of sensitive products (in terms of export control of the
products, the national interest and the interest of the (N)TS issuer, etc.), so that the product supplier:
— is sure to obtaining authorization to develop and export the product and
— can use technologies and components compatible with product usage and purpose.
For example, some commercially-available software packages are prohibited in some export products.
The same is true for some hardware components such as “wideband” or high-power components.
7.4.3 Life profile
This subclause defines the different situations that the product will face during its usage (transport,
handling, storage, maintenance, operational use).
The relative duration of exposure of the product to each identified situation should be quantified for a
standard period of use.
As a reminder, the definition of “life profile” is given in Clause 3.
7.4.4 Operational scenarios
This subclause defines the design-critical operational scenarios applicable during the expected
missions, in the context identified in 7.4.2. I.e. as all the scenarios
...