BS EN 9277:2015

$198.66

Aerospace series. Programme Management. Guide for the management of Systems Engineering

Published By	Publication Date	Number of Pages
BSI	2015	54

Guaranteed Safe Checkout

Category: BSI

If you have any questions, feel free to reach out to our online customer service team by clicking on the bottom right corner. We’re here to assist you 24/7.
Email:[email protected]

Description

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.

PDF Catalog

PDF Pages	PDF Title
4	Contents Page
5	European foreword
7	1 Scope 2 Normative references
8	3 Terms and definitions
9	4 Symbols and abbreviations 5 Positioning of Systems Engineering and SE management within a project 5.1 The need for Systems Engineering Management
11	5.2 Relation between SE management and Programme Management
12	5.3 Positioning of SE in relation to Programme Management
14	6 Systems Engineering process 6.1 Reference process 6.2 Technical activities
15	6.3 Interactions between technical activities
17	6.4 Activities specific to Systems Engineering management
18	6.5 Systems Engineering management, phasing and scheduling and recursivity
21	7 Principle for defining requirements and elements of the management plan 7.1 Approach 7.2 Control of Systems Engineering technical objects and activities
23	7.3 Interactions between management activities and technical objects and activities
24	7.4 Drafting of requirements and elements of the Systems Engineering management plan 8 Examples of management requirements and elements of the management plan concerning Systems Engineering 8.1 General
25	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.
26	8.3 Expression of need by the Acquirer 8.3.1 Management requirements 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 funct… 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 … 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, f… 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:
27	8.4.1.5 The Organization will ensure that the impacts of the operational requirements expressed (operating environments, system lifecycle, interfaces with the user and the higher level system, etc.) have been analysed for all the functions of the system. 8.4.1.6 The Organization will seek convergence with the Acquirer on a reformulated system requirements baseline (which could for example take the form of a system PTS) complying with the maturity criteria mentioned in 8.4.1.3. 8.4.1.7 In order to control the complexity, the Organization will check that the formulation of system requirements limits their degree of inter-dependency. 8.4.1.8 If the Acquirer need changes, the Organization will analyse the impact on the requirements baseline in terms of maintaining the maturity and feasibility criteria. 8.4.2 Elements of the management plan 8.4.2.1 The methods, tools and resources used for the analysis of the Acquirer needs are described. 8.4.2.2 All shortfalls, ambiguities, inconsistencies, etc., are reported to the Acquirer, so that the Acquirer can complete its expression of need. 8.4.2.3 The system interfaces with the operational environment and the higher level system are analysed, in order to ensure that they are correctly included in the specifications of the system and its components. 8.5 Requirements Validation 8.5.1 Management requirements 8.5.1.1 The Organization will demonstrate that the system requirements fully reflect the need expressed by the Acquirer. 8.5.1.2 The Organization will check that the system requirements which are not directly derived from the Acquirer need are necessary and sufficient as induced by the design of the system. 8.5.1.3 The Organization will coordinate the requirements validation activities with the Suppliers who have been delegated responsibility for some system requirements. 8.5.2 Elements of the management plan 8.5.2.1 It is checked and validated with the Acquirer as early as possible that the end-user’s needs are clearly understood, for example through simulation, models or mock-ups. 8.5.2.2 A traceability matrix is provided, justifying the complete coverage of the expressed need and highlighting the possible interdependences between requirements. 8.5.2.3 The availability of the human resources with appropriate competence in requirements engineering is planned, taking account of the time needed to acquire the necessary experience in this field.
28	8.6 Solution Definition 8.6.1 Management requirements 8.6.1.1 The Organization will describe the method used to define a system solution that meets the system requirements and will demonstrate its capability to implement this method. 8.6.1.2 The Organization will demonstrate that this method can be used to acquire definition states of the system solution which are compatible with the project phasing and scheduling (for example to guarantee the availability of the development speci… 8.6.1.3 The Organization will provide a solution definition comprising: 8.6.1.4 The Organization will demonstrate the traceability of the system requirements towards the sub-system requirements and the consistency of their allocation to the sub-systems. 8.6.1.5 The Organization will have assessed the feasibility of the sub-systems identified in the proposed solution concepts. 8.6.1.6 The Organization will demonstrate that the system definition meets the Acquirer requirements for interfacing with the higher level system. 8.6.1.7 The Organization will demonstrate that the definition of the sub-systems and their interfaces (without forgetting any existing or modified sub-systems that are reused) ensures: 8.6.1.8 If necessary the Organization will transfer to the lower level Suppliers the elements of the higher level expression of need to ensure that the needs as expressed by the Acquirer are clearly understood. 8.6.2 Elements of the management plan 8.6.2.1 The initial approach adopted for structuring the solution is the functional analysis. The need expressed by the Acquirer is thus broken down into functions and then successive sub-functions down to a functional level enabling the complexity to… 8.6.2.2 The adopted physical architecture is checked in order to ensure that it enables all the elements of the functional architecture to be projected into physical components that exist or are specifically designed. 8.6.2.3 The results of system level requirements allocation to the various components of the system architecture are recorded in a traceability matrix and these requirements are translated into sub-system needs. 8.6.2.4 A simulation model, comprising the definition of the sub-systems and their interfaces, is used in order to optimize the system definition process. This model includes the sub-models produced by the sub-systems Suppliers.
29	8.6.2.5 The additional requirements resulting from the system architecture and the analysis of the interfaces between the components are included in the sub-systems requirements baseline. 8.6.2.6 For each sub-system making up the system, a set of requirements is thus identified and must be consolidated. The initial consolidation step consists in checking their consistency with the other components requirements and with the system. The … 8.6.2.7 The physical environments encountered by each sub-system throughout its lifecycle are described as precisely as needed, as well as the non-functional requirements such as RAMS requirements, and if necessary, the expectations in terms of ergono… 8.7 Modelling/simulation 8.7.1 Management requirements 8.7.1.1 The Organization will describe its modelling strategy based on: 8.7.1.2 8.7.1.3 The Organization will ensure the availability of the appropriate skills for the design and utilisation of the models. 8.7.1.4 The Organization will ensure that the models are robust and representative of the actual system and its environment. 8.7.1.5 The Organization will analyse the origin of discrepancies between the expected results and the results of the simulations and tests and will consequently define the actions necessary with regard to the models, the actual system or its Product …
30	8.7.2 Elements of the management plan 8.7.2.1 A standardized neutral format is used to exchange CAD mock-ups, in order to ensure the compatibility of the technical data exchanged as part of the Definition Files. 8.7.2.2 The various system representation models (behaviour, dimensions, etc.) needed at the various stages of system development are identified in a modelling plan. 8.7.2.3 A performance simulation model is developed based on the integration of the performance models for each of the sub-systems, in order to demonstrate the convergence of system performance throughout the project. 8.7.2.4 The breakdown of system performance into specifications of need for the sub-systems is supported by a model able to consolidate the requirements. 8.7.2.5 The models are fixed or improved by correlating their results with those of the verification and validation tests on a set of chosen key points in the operating range. The models are thus made reliable and can be used to predict the system per… 8.8 System analysis 8.8.1 Management requirements 8.8.1.1 Throughout the design process, the Organization may be required to analyse several alternative solutions (including some proposed by the Acquirer) in response to technical problems raised at a given stage (logical architectures, physical conce… 8.8.1.2 The Organization will provide an analysis report in order to compare the alternative solutions with each other with regard to the need compliance criteria and to guide the choice of the optimal solution. 8.8.1.3 The Organization will organize a specific review to enable the Acquirer to rule on the choice of the solution which will become a contractual reference for the rest of the development activities. 8.8.2 Elements of the management plan 8.8.2.1 The system analysis of the solutions is based on the analysis results obtained at the sub-systems level. 8.9 System verification 8.9.1 Management requirements 8.9.1.1 At each agreed step in the project phasing and scheduling, the Organization will check that the system definition meets the system requirements defined in the system PTS. 8.9.1.2 This verification will take place throughout the development, in particular at the design stage and when producing the development products. 8.9.1.3 This verification will be based on the proof obtained at the level of the system which the Organization is responsible for, as well as on the proof obtained at the lower levels.
31	8.9.1.4 The major risks linked to the verification (for example, availability of the test resources and development products) will be identified by the Organization, quantified and communicated to the Programme Management. 8.9.1.5 The Organization will define the internal organization and identify the responsibilities necessary for successful verification and production of the associated supplies. 8.9.1.6 If the verification results show that the product makes it impossible to meet one or more technical requirements, the Organization will investigate the causes and will propose to the Acquirer one or more corrective solutions after assessing th… 8.9.2 Elements of the management plan 8.9.2.1 A test logic is established to describe the verification method and the phasing and scheduling of the verification tasks, which allow acquisition of all the expected evidence and minimizes the risks and costs, and which aim at achieving the ma… 8.9.2.2 This logic takes account of the following identified assumptions and constraints: 8.9.2.3 The organization of this activity takes account of the following tasks related to verification: 8.9.2.4 As part of this approach, the needs in terms of technical assistance and the associated skills are flown down to the Suppliers concerned. 8.10 System validation 8.10.1 Management requirements 8.10.1.1 Through the proofs resulting from the studies, simulations or tests, the Organization will ensure that the solution developed meets the needs of the Acquirer as expressed in the system (N)TS. 8.10.1.2 The Organization will deliver a Definition Justification Plan, submitted to the Acquirer for acceptance, that defines for each requirement in the system (N)TS the validation methods and tools which will be used to prove that the requirement i…
32	8.10.1.3 The Organization will check that the validation work has been carried out in accordance with the Definition Justification Plan. 8.10.1.4 The Organization will deliver a synthesis document (for example Definition Justification File) recalling the list of requirements of the (N)TS and, for each one, stating the work (studies, tests, etc.) done and the results obtained, along wit… 8.10.2 Elements of the management plan 8.10.2.1 The validation results are analysed with the Acquirer in order to determine what the possible causes of operational dissatisfaction with the system are, for example: incomplete expression of need, incorrect interpretation of the expressed nee… 8.10.2.2 The Definition Justification File is built up along the development and is supplied to the Acquirer at the major milestones. This justification file is the subject of reviews with the Acquirer in order to validate the results obtained, assess… 8.11 Processes in which the Systems Engineering is involved 9 Interfaces between Systems Engineering Management and the other Programme Management disciplines 9.1 General
33	9.2 Risk management
34	9.3 Configuration management 10 Specialty engineering activities 10.1 Design to Cost 10.2 Reuse or new solution
35	10.3 Human factors
36	Annex A (informative) Areas covered by standards covering Systems Engineering
37	Annex B (informative) Method for identifying management requirements B.1 “SE management generic requirements” table
38	B.2 Method for using the “SE Management generic requirements” table B.2.1 For drafting SE management requirements
40	B.2.2 To draft elements concerning the SE management plan
41	Annex C (informative) Implementation example: “solution definition” activity C.1 Filled out table
42	C.2 Requirements and elements of the management plan C.2.1 Management requirements (see 8.6.1)
43	The Organization will provide a solution definition (DO: Supply X Documents: System Definition File) (see 8.6.1.3) comprising: The Organization will demonstrate that the system definition meets the Acquirer requirements for interfacing with the higher level system. (CHECK: Demonstrate X Product interfaces: Interface with higher level requirements) (see 8.6.1.6). The Organization will demonstrate that the definition of the sub-systems and their interfaces (without forgetting any existing or modified sub-systems that are reused) (see 8.6.1.7) ensures: If necessary the Organization will transfer to the lower level Suppliers the elements of the higher level expression of need to ensure that the needs as expressed by the Acquirer are clearly understood. (DO: Communicate X Technical Requirements: Acqui… C.2.2 Elements of the management plan (see 8.6.2) The initial approach adopted for structuring the solution is the functional analysis. The need expressed by the Acquirer is thus broken down into functions and then successive sub-functions down to a functional level enabling the complexity to be redu… The adopted physical architecture is checked in order to ensure that it enables all the elements of the functional architecture to be projected into physical components that exist or are specifically designed. (CHECK: Verify X Results: System architec… The results of system level requirements allocation to the various components of the system architecture are recorded in a traceability matrix and these requirements are translated into sub-system needs. (DO: Record X Criteria: Traceability of sub-sys… A simulation model, comprising the definition of sub-systems and their interfaces, is used in order to optimize the system definition process. This model includes the sub-models produced by the sub-system Suppliers. (PDCA: Assure X Process Interfaces:… The additional requirements resulting from the system architecture and the analysis of the interfaces between the components are included into the sub-systems requirements baseline. (PLAN: Identify X Results: Sub-system requirements) (see 8.6.2.5).
44	For each sub-system making up the system, a set of requirements is thus identified and must be consolidated. The initial consolidation step consists in checking their consistency with the other components requirements and with the system. The next co…
45	Annex D (informative) Description of SE process activities D.1 Expression of need by the Acquirer D.2 Acquirer’s needs analysis and system requirements definition D.3 Requirements validation D.4 Solution definition
47	D.5 Modelling and simulation D.6 System analyses D.7 System verification
48	D.8 System validation
49	Annex E (informative) Description of certain objects in the SE process
50	Annex F (informative) Mapping between systems engineering processes and Human-centred design for interactive systems processes and principles F.1 Mapping with ISO/IEC 15288:2008 Technical processes
51	F.2 Mapping with ISO/IEC 15288:2008 others processes than technical ones
52	Bibliography

Additional information

Status	Definitive
Pages	54
Publication Date	2015-09-30
ISBN	978 0 580 87289 1
Standard Number	BS EN 9277:2015
Title	Aerospace series. Programme Management. Guide for the management of Systems Engineering
Identical National Standard Of	EN 9277:2015
Descriptors	Air transport engineering, Systemology, Plans, Management operations, Management, Quality management
Publisher	BSI
Committee	ACE/1
ICS Codes	49.140 - Space systems and operations

Preview PDF


PDF Format	Searchable	Printable	Preview Now

BS EN 9277:2015

PDF Catalog

Related products