EN 9277:2015

SLOVENSKI STANDARD
01-november-2015
Aeronavtika - Vodenje programov - Navodilo za vodenje sistemskega inženiringa
Aerospace series - Programme Management - Guide for the management of Systems
Engineering
Programm-Management - Leitfaden für das Management von Systemtechnik
Ta slovenski standard je istoveten z: EN 9277:2015
ICS:
03.100.40 Raziskave in razvoj Research and development
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 9277
EUROPEAN STANDARD
NORME EUROPÉENNE
September 2015
EUROPÄISCHE NORM
ICS 49.140
English Version
Aerospace series - Programme Management - Guide for the
management of Systems Engineering
Série aérospatiale - Management de Programme - Luft- und Raumfahrt - Programm-Management -
Guide pour le management de l'ingénierie Système Leitfaden für das Management von Systemtechnik
This European Standard was approved by CEN on 11 November 2014.

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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

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

Contents Page
European foreword . 3
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 6
4 Symbols and abbreviations . 7
5 Positioning of Systems Engineering and SE management within a project . 7
6 Systems Engineering process . 12
7 Principle for defining requirements and elements of the management plan. 19
8 Examples of management requirements and elements of the management plan
concerning Systems Engineering . 22
9 Interfaces between Systems Engineering Management and the other Programme
Management disciplines . 30
10 Specialty engineering activities . 32
Annex A (informative) Areas covered by standards covering Systems Engineering . 34
Annex B (informative) Method for identifying management requirements . 35
B.1 “SE management generic requirements” table . 35
B.2 Method for using the “SE Management generic requirements” table . 36
B.2.1 For drafting SE management requirements . 36
B.2.2 To draft elements concerning the SE management plan . 38
Annex C (informative) Implementation example: “solution definition” activity . 39
C.1 Filled out table . 39
C.2 Requirements and elements of the management plan . 40
C.2.1 Management requirements (see 8.6.1) . 40
C.2.2 Elements of the management plan (see 8.6.2) . 41
Annex D (informative) Description of SE process activities . 43
D.1 Expression of need by the Acquirer . 43
D.2 Acquirer's needs analysis and system requirements definition . 43
D.3 Requirements validation . 43
D.4 Solution definition . 43
D.5 Modelling and simulation . 45
D.6 System analyses . 45
D.7 System verification . 45
D.8 System validation . 46
Annex E (informative) Description of certain objects in the SE process . 47
Annex F (informative) Mapping between systems engineering processes and Human-
centred design for interactive systems processes and principles . 48
F.1 Mapping with ISO/IEC 15288:2008 Technical processes . 48
F.2 Mapping with ISO/IEC 15288:2008 others processes than technical ones . 49
Bibliography . 50
European foreword
This document (EN 9277:2015) has been prepared by the Aerospace and Defence Industries
Association of Europe - Standardization (ASD-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this Standard has
received the approval of the National Associations and the Official Services of the member countries of
ASD, prior to its presentation to CEN.
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 March 2016, and conflicting national standards shall
be withdrawn at the latest by March 2016.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such
patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

Introduction
This document aims to address the current challenges of the programmes that are:
 the multi projects approach,
 the multi-disciplinary approach,
 new methods of acquisition,
 the increasing complexity of systems to be acquired,
 the evolving aspects of the system and its incremental development,
 the complexity of the management of projects in terms of organization,
 the evolution of the industrial sectors.
In this document the system considered comprises a target system and elements (products, processes,
etc.) needed for developing, producing and using it, in other words a range of end products and
products supporting the lifecycle of the target system.
The case where the system is only an element of the service provided (no system is acquired, service
only) is not adressed in this document.
Systems Engineering (SE) cover a set of activities which, based on a perceived operational need and
via an organized approach, aims to:
 describe this need in technical terms,
 gradually transform it into a system solution,
 at each stage, demonstrate that this system is compliant with the need.
Systems Engineering:
 considers the system as a whole and in all situations of its lifecycle,
 provides a framework for combining various technical disciplines (electronics, data processing,
mechanics, ergonomics, etc.) and some enterprise functions (design, production, logistics, tests,
etc.) without necessarily intervening in these disciplines and functions,
 aims for the overall optimization of the solution in a field of constraints (costs, schedule,
performance, strategy, etc.) established by the Programme management,
 guarantees consistency between all components of the solution (functional and physical
interfaces).
In this document, the organisational dimension is essential to reach the overall objectives. The
complexity of the system and the complexity of the organisation are correlate (the more complex the
system is, the more control of the organisation is necessary).
Its position with respect to other normative documents handling Systems Engineering (ISO/IEC
15288, EIA 632,IEEE 1220, EN 9200) is represented in Annex A. This document falls within the scope
of EN 9200 and ISO/IEC 15288, focusing on aspects linked to the management of the technical
activities of SE with a higher level of detail. It relies partly on the SE process described in ISO/IEC
15288:2008 and if necessary with addition from EIA 632, adding the project phasing and scheduling
aspect. It overlaps little with IEEE 1220 as such, which concentrates primarily on SE technical
activities.
1 Scope
Based on the following considerations:
 reminder of Systems Engineering and its scope of application,
 positioning of SE management in Programme Management and in relation to Systems Engineering
technical activities,
 identification of interfaces between SE management and the other disciplines linked to
Programme Management,
the purpose of this standard is:
 to help the acquirer and the Organization to establish management requirements for SE activities,
 to help the supplier to construct the elements of the management plan (explain how to reply in
particular to the management requirements).
This standard applies to the various levels of the product tree for the products that can be considered
as systems:
 in the general case of an supplier which, with the help of one or more suppliers, develops a system
on behalf of an acquirer,
 in the case of an integrated team (sharing of SE roles, responsibilities and risks).
NOTE ISO/IEC/IEEE 24765:2010 integrated team should include organisation discipline and functions which
have a stake in the success of the work products.
This standard constitutes a guide illustrating the requirements and possible responses for SE
management. It can be used as a check-list which should be adapted or completed according to the
specific context of each project.
2 Normative references
The following referenced documents are indispensable for the application 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, General recommendation for the project management specification
EN 12973, Value management
EN ISO 9000:2005, Quality management systems — Fundamentals and vocabulary (ISO 9000)
ISO 9220, Metallic coatings — Measurement of coating thickness — Scanning electron microscope
method
EN ISO 9241-210:2011, Ergonomics of human-system interaction — Part 210: Human-centred design for
interactive systems (ISO 9241)
ISO/IEC 15288:2008, Systems and software engineering — Systems life cycle processes
ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary
1)
EIA 632:2003, Processes for Engineering a System
2)
IEEE 1220:2005, Standard for Application and Management of the Systems Engineering Process
3 Terms and definitions
The following referenced documents are essential for the application of this document. For dated
references, only the written issue applies.
For the purposes of this document, the following terms and definitions apply.
ISO/IEC/IEEE 24765:2010 Systems and software engineering vocabulary should be used for the
definition. In addition, the following standards should be used for definition as ordered:
 ISO/IEC 15288:2008, Systems and software engineering — Systems life cycle processes
 EN ISO 9241-210:2011, Ergonomics of human-system interaction — Part 210: Human-centred
design for interactive systems
 EIA 632:2003, Processes for Engineering a System
 IEEE 1220:2005, Standard for Application and Management of the Systems Engineering Process
 EN ISO 9000:2005, Quality management systems — Fundamentals and vocabulary
3.1
complexity
characteristic of a process linked to the number and diversity of participants, components and
technologies, involved in the design and production of products and the supporting logistics
3.2
iterativity
characteristic of a process which is repeated several times in full or in part, with a search for
convergence towards a product meeting the expressed need
3.3
recursivity
owing to the system breakdown into sub-systems, repetition of the SE process at various breakdown
levels with strong interaction between the levels
3.4
system
set of complex hardware, software, personnel and operational processes, organized so as to satisfy the
needs and fulfil the expected services, in a given environment
3.5
systems engineering
interdisciplinary approach governing the total technical and managerial effort required to transform a
set of customer needs, expectations, and constraints into a solution and to support that solution
throughout its life
Note 1 to entry: Includes the definition of technical performance measures; the integration of engineering
specialties toward the establishment of architecture; and the definition of supporting lifecycle processes that
balance cost, performance, and schedule objectives.

1) EIA National (US) Electronic Industries Association http://www.eia.org/
2) IEEE International Institute of Electrical and Electronical Engineers http://www.ieee.org/
3.6
scalability
the ability to change the component configuration of a system to fit desired application context
Note 1 to entry: Component configuration changes may be obtained by deployment of items or by setting
configuration parameters of each item.
3.7
upgradability
potential ability of a system, subsystem or component to respond to changes in operational
requirements and anticipated or foreseeable technical changes without affecting the basis of its
structure
Source: ISO 9220.
4 Symbols and abbreviations
For the purpose of this document, the abbreviations used are clarified below:
 CAD : Computer Assisted Design
 FS : Functional Specifications
 ILS : Integrated Logistics Support
 MP : Management Plan
 MS : Management Specification
 (N)TS : (Need) Technical Specification
 PDCA : Plan/Do/Check/Act
 PTS : Product Technical Specification
 SE : Systems Engineering
 TS : Technical Specification
5 Positioning of Systems Engineering and SE management within a project
5.1 The need for Systems Engineering Management
Within the business activities, two different and complementary visions co exist. SE vision highlights
the following main objectives:
a) The management of SE activities giving assurance that all SE activities are identified, planed,
monitored and controlled:
 before launch of the project through the identification of the technical activities to perform
during the project to satisfy needs of the system development and project constraints (costs,
schedule, performance),
 during the project through the identification of the engineering tasks, the relevant resources
including human resources, the appointment of the main responsibles, the reporting needed
to monitor and control the progress of the engineering,
 along the project maintain the compliance of the system design and definition with the
requirements.
b) Contribution of the Systems Engineering to the Programme:
 converting a set of needs into a system meeting the set of needs, through a systematic
approach contributing towards an integrated design of the product and associated
manufacturing, testing and support processes,
 from a technical point of view, managing and optimizing the system performance in
accordance with the Programme objectives and constraints,
 enable to deploy a gradual demonstration that this system meets the set of needs,
 identifying the system technical risks and conducting risk mitigation actions, and contributing
to the overall risk management process.
A strong coordination and integration is essential, justifying the creation of formalized specific SE
management, for example through an SE specification and MP.
Indeed, some main characteristics differentiate the SE with respect to conventional engineering
activities and justify the need for specific SE management:
 imprecise requirements, which are refined during development, supplemented by assumptions;
 complexity of the environment, interacting closely with the system (Man Machine Interface, field of
operation, etc.);
 complexity linked to the number and diversity of stakeholders, the number of different
technologies, the products themselves and the supporting logistics (system dedicated to multi
acquirers on multi markets);
 iterativity; recursivity of project processes;
 scalability of the system;
 upgradability of the systems, sub-systems and components.
Systems Engineering involves both the Acquirer and the Supplier(s) of the Organization and comprises
the various technical processes which iteratively and exhaustively contribute to ensuring that the
solution meets the need throughout the lifecycle of the system.
See Figure 1 — Systems Engineering positioning in relation to Programme Management.
SE management is therefore not restricted to management of the Organization's SE technical activities,
but must also provide the link with the higher and lower level SE activities (Organization's acquirers and
suppliers).
In this context, cooperative Acquirer/Organization/Supplier working methods will be encouraged in
order to improve data exchanges, partner reactivity and convergence towards common requirements
and solutions (for example: networking, shared data environment, etc.).
The large number of stakeholders (owing to the numerous disciplines involved and the
Acquirer/Organization/Supplier tree) similarly requires specific SE management to ensure the
consistency of the work done, the consistency of the data and of technical data flow.
Consequently, SE management requires the use of specific methods, tools and skills.
5.2 Relation between SE management and Programme Management
Given the need for Systems Engineering Management, the overall SE process can be split into 2 types
of activities:
 SE management activities which are included in Programme Management and which comprise
planning, management and control of SE technical activities,
 the technical activities themselves, linked to the technical processes (Acquirer needs analysis,
design, verification, validation, etc.) applied to the system.
See Figure 1 — Systems Engineering positioning in relation to Programme Management.
The main role of SE management within Programme Management is to ensure system performance in
conformity with the expressed need and to control the technical risks involved in the development.
Besides, SE management contribute to the Programme Management for all technical aspects of the
system through the whole lifecycle. SE management therefore reinforces the technical viewpoint
within the Programme Management.
The cost and schedule parameters, which are the responsibility of Programme Management are taken
into account in SE management as input constraints in the search for optimum performance: SE
management must measure all the resulting consequences in terms of technical choice and associated
risks for the project and help Programme Management to define the performance/cost/schedule
trade-off in cooperation with all the stakeholders.
5.3 Positioning of SE in relation to Programme Management
For a given Organization (level N), Figure 1 presents the positioning of Systems Engineering in relation
to Programme Management within a generic Acquirer Supplier relationship, as well as the central
positioning of SE management between Programme Management and technical activities.
This figure applies to any organization, from the end user up to the furthest downstream suppliers. In
this figure, the notion of acquirer is to be taken in the broadest sense. It includes all the stakeholders
outside the Organization expressing needs to it (contracting organizations, certification Authorities,
end-user, etc.).
All the SE, technical and management activities together, are organized according to a reference
process recalled in Clause 6 and described in Annex D. The relations between the SE technical and
management activities are defined in Clause 7.
SE management uses the elements of the management plan related to SE in reply to all the
management requirements specific to SE expressed on the one hand in the Acquirer's management
specification and on the other hand internally by the Organization (Clause 8).
SE management also interfaces with all the other components of Programme Management such as
Integrated Logistics Support, risks and RAMS management. These interfaces are explained in Clause 9.
In the Figure 1 — Systems Engineering positioning in relation to Programme Management, the solid
line circles inside the Acquirer, Organization and Supplier entities represent the activities carried out
by these entities (the what) without anticipating the organization put in place to carry them out (the
who) which can fluctuate from one Organization to another and one project to another Figure 1 —
Systems Engineering positioning in relation to Programme Management.
Figure 1 — Systems Engineering positioning in relation to Programme Management
6 Systems Engineering process
6.1 Reference process
The basic SE process is described in EIA 632 through static relations (no phase sequencing) between
activities, without specifying the Actors in this process. The approach of this standard is to supplement
this view by handling the time aspects of the SE process within a project phasing and scheduling
approach with responsibilities sharing in the Acquirer Supplier relationship, as envisioned by EN 9200.
Thus, it was proved necessary to combine these two visions in order to obtain a reference process for
the rest of the document.
The description of the SE process activities is detailed in Annex D. Regular reference to this annex is
strongly recommended for a clear understanding of the management requirements in Clause 8.
6.2 Technical activities
The SE process comprises the following technical activities:
 expression of the Acquirer's need;
 system design incorporating:
 analysis by the Organization of this need and the system requirements definition,
 definition of the system solution: structuring, requirements allocation and components
specification.
 modelling/simulation (performance, etc.);
 technical assessment comprising:
 requirements validation,
 system analysis,
 system verification,
 system validation.
The content, players and inputs/outputs of these activities are described in Annex D.
NOTE Due to its growing role in the development of complex systems (for example mock-ups and virtual
products), modelling/simulation is here considered to be an activity in its own right, going beyond the simple
framework of systems analysis.
The SE process is also involved in the following technical activities:
 acquisition of components from the Suppliers of the Organization (or in-house),
 integration of these components into the system,
 development of the supporting logistics,
 transition to use placing of the final system at to the Acquirer's use (installation and
commissioning in the Acquirer's environment).
The SE activities are carried out iteratively for each level of the product-tree which can be considered
as a system, refining the requirements and the solutions at each iteration. Moreover, these activities
are repeated recursively from level to level of the product-tree.
These activities comprise the flow down of the needs, the search for and consolidation of solutions.
The chosen solutions are gradually detailed and then implemented (the implementation activities are
not part of SE).
All these activities contribute to controlling the performance of the system, in other words, obtaining,
optimizing, checking and validating this performance.
6.3 Interactions between technical activities
Figure 2 represents the interactions, flows and looping (non-chronological) between the technical
activities in the SE process. The activities are positioned in it according to the field of responsibility of
each player (Acquirer, Organization, Supplier). The scale of shading differentiates the SE activities
from those in which the SE process is simply involved. The “supporting logistics development” activity
is not represented because showing its interactions with the other activities would degrade the overall
legibility without really adding any significant value.
The direct process activities and flows, ranging from expression of need to transition to use, are
represented differently (bold simple arrows) from the loop flows used to check that each step has
been achieved correctly and iterate if necessary (simple arrows). The specific interactions between
system analysis and the other activities are represented in a particular way (dotted two-way arrows).
Figure 2 — Interactions between the SE process technical activities
6.4 Activities specific to Systems Engineering management
This standard focuses on the management activities designed to control the specific aspects of SE
described in 5.1, without dealing with the more conventional aspects linked to Programme
Management (contract, breakdown of tasks, planning, etc.). See Table 1.
Table 1
Objective criteria Activities
To guarantee the Ensure the consistency and exhaustiveness of the requirement allocations
compliance of system during the breakdown into sub-systems.
design and definition
Ensure the consistency and exhaustiveness of the proposed sub-system
with the
solutions when reconstituting the system.
requirements
Ensure the compatibility of the functional and physical interfaces both
within the system and with the world outside the system.
Specify and analyse the tests and provings concerning the system or its
components.
To ensure system Iteratively seek consistency between the performance of the system and the
performance performance of the sub-systems.
convergence
Allocate or re-allocate performance values, taking account of the technical
risks and design margins, by implementing the following techniques:
 analysis of robustness, sensitiveness, reliability, limit tests;
 use of models and simulation tools.
Take advantage of the new properties of the system observed during
development (notion of emerging properties).
NOTE Given the characteristics of a system, the system optimum is rarely the
sum of the optima of its sub-systems. Optimization is therefore carried out overall:
 on the complete system rather than separately for each component of the
system,
 on a given component, between several performance parameters.
To ensure control Manage and coordinate the SE technical activities as defined in section 6.2.
of the SE process
Manage the many independent technical data originating from all the
technical disciplines involved in the project:
 document, validate and regularly distribute technical data concerning
the system (technical decisions, system design data, etc.);
 implement processes and tools to ensure data traceability and
consistency (in addition to traceability at document level);
 organize data flows between the system components and ensure
exchange compatibility (formats and synchronization);
 manage changes and harmonize configuration management rules for
the various areas of expertise (system and sub-systems configuration,
models, CAD tools, etc.);
To reinforce the Ensure that the technical risks are identified and analysed and that risk
technical viewpoint mitigation actions are defined;
of Programme
Ensure that criteria have been established and indicators are in place to
Management
assess whether the engineering efforts and the system performed will be
able to meet the requirements.
The above activities are conducted by the Organization and by the Acquirer/Organization/Supplier
network (recursivity), within the context of overall coordination provided by Programme
Management.
The breakdown of these management activities according to each of the SE technical activities is
illustrated in Clause 8 in the form of examples of requirements and elements of the MP.
6.5 Systems Engineering management, phasing and scheduling and recursivity
Figure 3 represents the SE process activities organized according to a “project phasing and scheduling”
vision that is both generic and macroscopic. This vision enables management to identify all the tasks
and apply a sequencing logic to them (e.g.: acquisition of components is initiated when the system
design is considered as mature enough).
In order to control the iterative nature of the SE process, this is the SE management which determines
the interactions between activity in terms of data flow and sequencing and which dynamically
determines the possible iterations and the stopping criteria.
This figure does not show any possible reactivation of closed activities (e.g.: an unsatisfactory
validation may leads to reactivate the “expression of need” task. Another example: a change in the
need during the course of the project may leads to reactivate a process cycle).
In addition to the “phasing and scheduling vision”, the notion of recursivity between the different
system breakdown levels is illustrated in Figure 4. In this Figure, the SE process is repeated overall at
component acquisition level, requiring complex interactions between the various management levels
and technical activities.
In order to control the recursive nature of the SE process, the feedback of results with respect to the
requirements and between the levels of the product-tree are determined dynamically by SE
management.
Figure 3 — “SE Process phasing and scheduling” vision
Figure 4 — Recursivity of SE management and technical activities
7 Principle for defining requirements and elements of the management plan
7.1 Approach
The approach chosen in this standard to define the requirements and the elements of the Management
Plan concerning the SE consists:
 firstly, in specifying the role of the Management Specification (MS) and Management Plan (MP),
documents exchanged at project level between the Acquirer and the Organization, for controlling SE at
Organization level;
 secondly, in identifying the interactions between on the one hand the management activities and
on the other hand the technical objects and activities which are typically observed during running
of a project. These interactions are then analysed and traced using tables which are based on the
PDCA management model and focused on the characteristic aspects of the SE;
 finally, concatenation of the elements of these tables, after application to the
Acquirer/Organization relationship, allows drafting of SE-related elements of the MS and MP
documents.
7.2 Control of Systems Engineering technical objects and activities
The sections dedicated to SE in the project MS and MP (or the MS and MP documents specific to the SE
when they are differentiated) are the management baseline applicable throughout the project to the
relations between the SE management of the Acquirer, the Organization and the Supplier.
The purpose of applying this baseline is to ensure control by the Organization:
 of the flow of technical objects that can be directly exchanged between the Organization and
Acquirer SE technical activities,
 of the Organization's SE technical activities,
 of the flow of technical objects that can be directly exchanged between the Organization and the
Suppliers SE technical activities.
This mechanism is reproduced at each level on the Acquirer/Organization/Supplier tree.
Figure 5 represents the flow of MS requirements and of MP elements and the flow of technical data as
part of a Acquirer/Organization/Supplier tree. The “table” symbol represents the analysis table
mentioned in 7.1 and described in 7.3.
Figure 5 — Interactions between SE management artefacts (MS, MP, …)
and technical objects across the design layers
7.3 Interactions between management activities and technical objects and activities
The SE management activities are structured according to the “PDCA” (Plan/Do/Check/Act) cycle
model. Applying this model to control of SE technical objects and activities is a mean of guaranteeing
good control and permanent optimization of these objects and activities.
This model has been refined to allow a more precise identification of the management actions. For
example, the overall “Plan” action covers the following basic actions: identify, describe, select, etc.
Each technical activity is characterized by a set of objects representative of it: input and output data
and products, resources and organization.
The interactions between the technical and management activities are shown in Figure 6 in the form of
management actions directed towards technical activities and concerning the objects of this activity. In
response, the technical activity gives status information about the input/output data and products, the
resources used and the organization put in place.
The PDCA cycle runs continuously throughout the project. This cycle sets the timing of the interactions
between the technical and management activities, in order to control the iterative aspect of SE and
ensure convergence.
Figure 6 — Interactions between the technical activities and SE management
7.4 Drafting of requirements and elements of the Systems Engineering management
plan
The interaction model presented above has been used to define a structured method for identifying
management requirements and elements of the MP. This method is described in Annex B of this
standard.
Therefore, to draft SE Management requirements, the Acquirer could use the following steps:
a) Apply the method defined in Annex B, on the basis of the generic SE process presented in 6.2,
adapting it to the given project.
b) Refine the requirements with the Organization in order to determine the exact need.
When drafting the requirements, care will be taken to formulate them in terms of management
actions.
In drafting the elements of the MP, in particular replying to these management requirements, the
Organization may follow a similar method applied on the basis of its own SE process and its own
organization.
NOTE The elements of the management plan may be covered by a specific SE plan separate from the overall
management plan (see outline in EN 9200).
This method is recursive and can be broken down in the Acquirer Supplier relationship.
8 Examples of management requirements and elements of the management
plan concerning Systems Engineering
NOTE This paragraph is an application of the project processes of ISO/IEC 15288:2008.
8.1 General
For each activity of SE described in Annex D, this Clause on the one hand gives an illustrative example
of a SE management specification in the form of a list of management requirements from the Acquirer
to the Organization (which is its supplier) and on the other hand gives elements of the MP from the
Organization to its Acquirer in order to comply with these requirements.
The examples are chosen from among the usual good practices, with no search for exhaustiveness.
Significance of technical and project processes activities depends on system lifecycle phase, the
system-of-interest and its associated lifetime, the requirement and operational environment stability,
and the technical solution maturity as shown in the Figure 7.

Figure 7 — System Engineering Level of Effort across Life-Cycle Stages
[SOURCE: INCOSE Systems Engineering Handbook]
8.2 General Systems Engineering Management requirements
8.2.1 Management requirements
8.2.1.1 The Organization in charge of developing a system will be able to demonstrate that a SE
process has been defined then implemented and that it comprises two main sub-processes, the
interactions of which have been identified:
 a process for implementing the SE technical activities,
 a process for managing these technical activities.
8.2.1.2 The sub-process for managing the SE technical activities will comply with the requirements
expressed by the Acquirer in the Management Specification using the method defined in this standard.
8.2.1.3 The SE management requirements will be flown down to the Suppliers of the Organization in
charge of developing the sub-systems, for example in the MS intended to the Suppliers.
8.2.2 Elements of the management plan
8.2.2.1 The SE technical and management activities follow the process described in this standard.
8.2.2.2 To flow down the SE management requirements to the Suppliers, the method defined in this
standard is used.
8.3 Expression of need by the Acquirer
8.3.1 Management requirements
As this process is primarily performed by the Acquirer, the management requirements cannot here be
expressed as such because they concern the Acquirer itself for its own SE management activity. Here
we simply present a few recommendations for use by the Acquirer to ensure the quality of its
expression of need. Owing to the recursivity of the process, these recommendations also apply to the
Organization for the “solution definition” activity, as part of the flowdown of requirements for
Suppliers (see 8.6).
8.3.2 Recommendations
8.3.2.1 In order to acquire a clear knowledge of its own need, it is recommended that the Acquirer
conduct technical/economic/operational studies, for example: functional analysis to identify the service
functions, value analysis to select these functions and optimize the required performance levels,
operational simulations, and so on.
8.3.2.2 In the expression of need intended for the Organization, the Acquirer will indicate the
operational scenarios, the operating situations, etc. To do this, whenever possible, it will use
simulation to represent the needs in order to ensure that there is mutual understanding of the needs
expressed.
NOTE These means could also be used to validate the solution concepts.
8.4 Acquirer needs Analysis and System requirements definition
8.4.1 Management requirements
8.4.1.1 The Organization will identify all the stakeholders likely to express needs concerning the
system over its entire lifecycle.
8.4.1.2 The Organization will ensure that it has up to date input documents expressing all the
Acquirer's needs (for example: functional specifications, system Technical Specification (TS), etc.).
8.4.1.3 Throughout the iterative Acquirer expression of need process, the Organization will analyse
the need expressed in order to determine its degree of maturity according to criteria of clarity,
consistency, absence of ambiguity and completeness, for example by taking account of the scope of the
requirements to be met (environment, operational scenarios, various constraints such as laws and
regulations, etc.).
8.4.1.4 Similarly, the Organization will check the convergence of the maturity of this expression of
need, in particular by analysing the following aspects:
 detection and expression of implicit requireme
...