DATA ITEM DESCRIPTION

helping projects succeed... www.ppi-int.com DATA ITEM DESCRIPTION 1. TITLE SYSTEMS ENGINEERING PLAN (SEP) 2. Identification Number PPA-005327-13 2...
Author: Leslie Stone
3 downloads 0 Views 247KB Size
helping projects succeed...

www.ppi-int.com

DATA ITEM DESCRIPTION 1. TITLE

SYSTEMS ENGINEERING PLAN (SEP)

2. Identification Number PPA-005327-13 29 May 2012

3.

DESCRIPTION/PURPOSE

3.1

The Systems Engineering Plan (SEP) defines the plans and procedures of an enterprise for the management and conduct by that enterprise of a fully integrated technical program in conduct of the engineering element(s) of a project. The term “SEP” is generic, and may be replaced with any meaningful name.

3.2

Throughout this DID, the term “enterprise” may be interpreted to mean "customer", "acquirer", "supplier", "contractor", "subcontractor" or other organizational element, as applicable, responsible for performance of the work which is the subject of the SEP.

3.3

The SEP, including or supplemented by subordinate plans, is used to provide the primary work planning and process direction and guidance to the technical team responsible for conduct of the work. The SEP may also be used to provide visibility, to a customer, of a tenderer's or enterprise's engineering planning and intended processes.

3.4

The content of the SEP is intended to be responsive to contract requirements, if any, but is not, itself, intended to be invoked contractually.

3.5

The “system” referred to in the name and scope of the plan may be an end-use system, a production system, a support system or any other type of system.

4.

APPLICATION/INTERRELATIONSHIP

4.1

The SEP is subordinate to and derives its authority from a Project Plan or similar document which contains the highest level of project planning. This SEP Data Item Description (DID) may also be cited contractually in a Statement of Requirement (SOR), Statement of Work (SOW), a Contract Data Requirements List (CDRL), or within a standard invoked by a SOR or SOW.

4.2

The SEP may exist in partial satisfaction of the requirements of process standards such as ISO 9001, EIA632 and IEEE Std 1220, which may in turn be invoked contractually or by management decision of an enterprise.

4.3

This DID incorporates and adapts some non-copyrighted material contained in DI-MGMT81024 and MIL-STD-499B draft issued by the United States Government.

5.

PREPARATION INSTRUCTIONS

5.1

General Instructions continued next page

6.

SOURCE

Copyright Project Performance International. This document may be reproduced and distributed without restriction except as below provided that all reproductions contain the original copyright statement in the original form and location. Derivative works may be produced provided each derivative work contains a copyright statement referring to the content in which PPI holds copyright, in a form and in a location no less prominent than the copyright statement on the original. Copies and derivative works may not be used for the delivery of training for profit.

www.ppi-int.com Page 1 of 20

5.

5.2

PREPARATION INSTRUCTIONS - 5.1 General Instructions (continued) a.

Automated techniques. Use of automated techniques is encouraged. Where the SEP is deliverable, the Contract Data Requirements List (CDRL) should specify whether the data are to be delivered on paper or electronic media; any requirements on the electronic representation (such as ASCII, CALS, or compatibility with a specified word processor or other support software); whether the data may be delivered in enterprise format rather than in the format specified herein; and whether the data may reside in a computer-aided systems engineering (CASE) or other automated tool rather than in the form of a paper document or word processing file. The term “document” in this DID means data and its medium, regardless of the manner in which the data are recorded.

b.

Alternative presentation styles. The format contained within this DID is for guidance only and enterprise format may be used. Diagrams, tables, matrices and other presentation styles may be preferable substitutes for text when data required by this DID can be made more readable using these styles.

c.

Title page or identifier. When data are delivered in the form of a paper document or word processing file, the document shall include a title page containing, as applicable: document number; volume number; version/revision indicator; security markings or other restrictions on the handling of the document; date of issue, document title; name, abbreviation, and any other identifier for the project, contract, subcontract or other entity to which the document applies; contract number; CDRL item number (if applicable); organisation for which the document has been prepared and name and address of the preparing organization. For data delivered in an alternative form, this information shall be included on external and internal labels or by equivalent identification methods.

d.

Table of contents. When data are delivered in the form of a paper document or word processing file, the document shall contain a table of contents providing the number, title, and page number of each titled paragraph, figure, table and annex. For data delivered in an alternative form, this information shall consist of an internal or external table of contents containing pointers to, or instructions for, accessing, each paragraph, figure, table and annex or their equivalents.

e.

Page numbering/labeling. When data are delivered in the form of a paper document or word processing file, each page shall contain a unique page number and display the document number, including version, volume, and date of issue, as applicable. For data delivered in an alternative form, files, screens, or other entities shall be assigned identifiers in such a way that desired data can be indexed and accessed.

f.

Response to tailoring instructions. When data are delivered in the form of a paper document, paragraphs that have been tailored out of the DID shall result in the corresponding paragraph number and title in the document, followed by “Not applicable” or alternatively, paragraph numbering may be varied to allow for the missing paragraph. For data delivered in an alternative form, the “Not applicable” representation may be incorporated in the table of contents or equivalent.

g

Multiple paragraphs and subparagraphs. Any section, paragraph, or subparagraph in this DID may be written as multiple subparagraphs to enhance readability.

Content Requirements

Content requirements begin on the following page. The numbers shown designate the paragraph numbers to be used in the document. Each such number is understood to have a prefix “5.2” within this DID. For example, the paragraph numbered 1.1 is understood to be paragraph 5.2.1.1 within this DID.

www.ppi-int.com Page 2 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

The degree of detail to be incorporated in the SEP for use by the enterprise's technical team should be guided by the following criteria: all information contractually required or beneficial to bound, constrain and control the time, cost, schedule, processes used and process performance achieved by the technical team responsible for implementation of the system should be included. Information which would undesirably constrain team and individual initiative should be excluded. 1.

SCOPE

This section should be divided into the following paragraphs. 1.1

Identification

This paragraph should contain a full identification of the project to which this document applies, including, as applicable, identification number(s), title(s) and abbreviation(s). Where the project to which the document applies includes variants or options to the scope of work, the above information should be provided for each variant or option. This paragraph should also contain a full identification of the system and any other deliverables the designs and other technical documentation of which are to be prepared within the work elements covered by the plan, including, as applicable, system identification number(s), title(s), abbreviation(s), version number(s), and release number(s). 1.2

Background and Intended Use of the SEP

This paragraph, if applicable, should briefly summarize the program to date and identify, as applicable, the project sponsor, acquirer, user and support agencies. It should state the intended users and uses of the SEP, for the current and each planned future issue. 1.3

Document Overview

This paragraph should summarize the contents and structure of the plan and should describe any security or privacy considerations associated with its use. The description of SEP content should include the following, or similar: "This SEP describes the enterprise's work plan and engineering process as it is to be applied to the engineering elements of the project. The SEP includes a description of the systems engineering processes planned to define the system requirements; to define the preferred system configuration to satisfy those requirements; the planning and controls of the technical program tasks; and the management of a totally integrated effort of product engineering (all applicable disciplines), test engineering, logistics engineering and production engineering, to meet cost, schedule and product quality objectives. 2.

APPLICABLE DOCUMENTS

This section should list in the subparagraphs below the number, title, revision, and date of each document referenced in the plan. This section should also identify the source of each document not available through normal channels. 2.1

Applicable Documents

This paragraph should list each document which is invoked in whole or in part within 4. The paragraph should contain any applicable rules for establishing precedence in the event of conflict of information between 4 and the applicable documents, and between applicable documents. The paragraph should also contain, where applicable, rules for establishing the applicable issue number of documents invoked in 4. 2.2

Other Referenced Documents

This paragraph should list each document which is referenced in the SEP but which is not invoked in whole or in part by 4 as a part of the SEP. 3.

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

This section should be divided into the following paragraphs.

www.ppi-int.com Page 3 of 20

5. 3.1

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued) Definitions

This paragraph should list alphabetically and define each word or term used in the SEP for which reliance on dictionary definitions is not appropriate. As a guide, terms which are not likely to be in the vocabulary of the intended users of the SEP, terms which have multiple dictionary meanings but only a single meaning in the SEP, technical terms and terms which are used with special meanings should be defined in this paragraph. The meanings of technical terms should, where applicable, be referenced to an authoritative standard such as IEEE 1220/EIA/IS-632, or to an appropriate technical dictionary. 3.2

Acronyms

This paragraph should list alphabetically each acronym used in the document, together with the acronym’s expanded meaning. 3.3

Abbreviations

This paragraph should list alphabetically each abbreviation used in the document, together with the abbreviation’s expanded meaning, except that abbreviations within the International System (Si) system of units should not be listed. 4.

PLANS AND PROCESSES

This paragraph should be divided into the following paragraphs to specify the plans and processes to be implemented in conduct of the technical program. 4.1

Engineering Work Plan

The subparagraphs of this paragraph should the identify technical program work tasks as a functional subset of the total Project work scope. The subparagraphs should define the plans for the accomplishment of these work tasks in terms of schedules, budgets, organization, responsibility and authority, including, where applicable, contractor and subcontractor work performance. 4.1.1

Engineering Objectives

This paragraph should describe the objectives of the technical program in terms related to success of the project and the effectiveness of the system after introduction into service. More specifically, technical objectives may include those related to development, manufacturing, validation, deployment, operations, user training, support or disposal. 4.1.2

Work Breakdown Structure (WBS)

This paragraph should identify by name and Project-unique identifier the elements of the enterprise's WBS which are the subject of this SEP. The elements of the WBS should extend to the levels at which work is assigned to the lowest levels of organizational elements above individuals for its performance. 4.1.3

Engineering Deliverables

This paragraph should describe for each WBS element at 4.1.2 the products, deliverable to the customer and deliverable internally to other functions performed within the enterprise organization, as applicable, resulting from the activities which are the subject of this plan. 4.1.4

Engineering Activities

This paragraph should describe the major engineering functional activities to be performed within the scope of this plan. Such functional activities may transcend two or more WBS elements. 4.1.5

Engineering Schedule

This paragraph should incorporate by reference a Systems Engineering Master Schedule (SEMS) and supporting Gantt chart or similar time-related representation of activities and milestones. The paragraph should also describe the analysis and rationale used to derive the SEMS.

www.ppi-int.com Page 4 of 20

5. 4.1.6

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued) Engineering Budget

This paragraph should incorporate by reference a Engineering Budget (EB). 4.1.7

Project Organization

This element should describe the organizational structure responsible for performing the Project scope. It should identify the name(s) and the place(s) within that structure of the organizational element(s) responsible for performing work which is within the scope of the SEP and its subordinate plans. 4.1.8

Engineering Organization

This paragraph should describe by means of the subparagraphs below the structure of each organizational element responsible for performing work which is within the scope of the SEP. 4.1.8.1 Organizational Structure 4.1.8.1.1

Organization

This paragraph should describe the composition of each organisational element responsible for performing work which is within the scope of the SEP. It should show the position within this structure of each organisational element which is responsible for performing work which is within the scope of each plan which is included by reference in and is subordinate to the SEP. 4.1.8.1.2

Lines of Authority

This paragraph should describe the reporting lines for engineering tasks and activities. 4.1.8.1.3

Senior Technical Team Member

This paragraph should describe the technical and reporting responsibilities of the technical team member who has responsibility overall for ensuring that the system design satisfies the system requirements, for the system(s) which is/are the subject of the SEP. 4.1.8.1.4

Subcontractor Relationships

This paragraph should describe the reporting and tasking relationships of the engineering organization with internal and external subcontractors to whom technical tasks are to be subcontracted. 4.1.8.2 Team and Sub-Team Composition and Purpose This paragraph should identify, and describe the make-up of, each technical team to be employed in performance of the technical program. Example teams for a small project are system team, teams for elements down the system hierarchy to at least the level of CIs that constitutes a point of departure into hardware/software design, user documentation team, ILS team, test team, production system team, etc. 4.1.8.3 Team Member Responsibilities and Authority This paragraph should define the responsibilities and authorities for each appointment within the technical team organization. Example appointments are Engineering Manager, System Architect, Requirements Manager, Team Leaders, System Integration Manager, Software Engineering Manager, Hardware Engineering Manager, Applications Engineer, RF Engineer, Configuration Manager and Lead Engineering Specialists. Example engineering specialty areas for which Lead Engineering Specialist appointments may be defined include system availability, hardware reliability, software reliability, hardware maintainability, software maintainability, electromagnetic compatibility, human factors engineering, health and safety, system security, producibility, life cycle cost, test and evaluation, testability and integrated diagnostics (BIT), computer resources and product costing.

www.ppi-int.com Page 5 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.1.8.4 Responsibility Assignment Matrix This paragraph should contain a matrix showing the assignment of engineering task responsibilities to members of the engineering organization. 4.1.8.5 Team Member Qualifications and Experience This paragraph should contain detailed descriptions of the required qualifications and experience of technical team members. 4.1.8.6 Team Member Training This paragraph should identify both internal and external training, if any, for enterprise personnel. The plan may include analysis of performance or behavior deficiencies or shortfalls, required training to remedy, and schedules to achieve required proficiency. 4.1.8.7 Planned Technical Team Staffing This paragraph should contain aggregate and labour-category-based time-phased plans for the use of human resources in the performance of work which is within the coverage of the SEP. Human resources for work which is within the coverage of plans which are subordinate to the SEP should be referenced rather than included in this paragraph. 4.1.9

Other Resource Planning

This paragraph should identify other resources required for conduct of the technical program, where these resources will be sourced, amounts of resources required, associated schedules for the utilization of these resources and any other planning with respect to these other resources. Resource profiles should reflect the consolidation and coordination of planning for each WBS element having an engineering component. Example other resources include user/customer supplied equipment, services and information, engineering management information systems, CASE tools, existing designs and technical training resources. If developmental test and evaluation is not the subject of its own planning document, test and evaluation resources such as test article manufacturing resources and resources for the conduct of testing should be described in this paragraph. 4.1.10

Risk and Contingency in the Work Plan

This paragraph should summarise those aspects of the systems engineering work plan that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.2.

Engineering Process

4.2.1

Process Inputs, Outputs, Functional and Organizational Interfaces

This paragraph should identify the detailed information needed to be able to accomplish the activities of the engineering process (to the level appropriate to the circumstances/contract or other agreement) , how needed information will be acquired when not already held, and how conflicts in information provided will be resolved. The paragraph should summarise information flows to and from the engineering function, the sources and recipients of such information, and should identify the required formats of the information. 4.2.2

Process Summary

This paragraph should summarise the engineering process as described in subsequent paragraphs. 4.2.3

Requirements Analysis

The subparagraphs of this paragraph should describe plans and processes for the conduct of requirements analysis. Separate, detailed procedures should be incorporated by reference, where applicable. www.ppi-int.com Page 6 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.3.1 Sources of Requirements This paragraph should identify requirements document(s) to be analyzed, together with any nondocumentary sources of requirements, eg users. The paragraph should also specify the criteria to be used in selecting any additional sources of requirements to be canvassed. 4.2.3.2 Summary of the Requirements Analysis Process This paragraph should summarize the process of requirements analysis as an integrated process, based upon inputs from the sources described in paragraph 4.2.3.1, and referring to the techniques described in the paragraphs below, as applicable. The paragraph should describe the outputs expected from the requirements analysis process, and how the quality of the outputs will be assured. 4.2.3.3 Requirements Analysis Process Description - [process title] to 4.2.3.v This and subsequent paragraphs should describe each of the requirements analysis techniques to be used, the criteria for use of the technique, and, where applicable, the detailed selection of technique(s) against requirements analysis tasks. Example techniques for description include context flow analysis, context analysis, states and modes analysis, mission/scenario analysis, other functional analyses, data analysis, parsing analysis, value analysis, constraints search and text terms search. The use of tools should be described where the use of tools is an integral part of the process. The description should specifically address how requirements of the following types are to be determined or verified: a.

functional requirements (what the item is to do, including conditions under which functions are to be performed);

b.

performance requirements (quantitative measures of how well functions are to be performed);

c.

external interface requirements;

d.

external environmental requirements (the external environments within which other requirements are to be satisfied, and constraints as to the effects of the item on the external environment, such as EMI generation);

e.

resource requirements (constraints on the usage by the system of externally supplied resources, such as memory or power);

f.

physical requirements (physical characteristics of the item as a whole, such as mass or size constraints);

g.

other "black box" characteristics, such as inherent availability; reliability; maintainability; survivability, including nuclear, biological and chemical; useability, safety, level of environmental impact, level of technical security, producibility, testability, interoperability, expandibility, flexibility of use, transportability, portability and cost;

h.

design requirements, which direct aspects of the design or specifically exclude technologies, materials or other aspects of internal design of the item; and

i.

test requirements, which define the evidence required to establish with an acceptable degree of assurance that the as-built system possesses the required characteristics.

4.2.3.w Application of the Requirements Analysis Process This paragraph should describe the extent of application of requirements analysis to each object which is the subject of requirements within the scope of work to which the SEP applies. The paragraph should define the application of the process to at least the requirements sets indicated by the subparagraph titles below: www.ppi-int.com Page 7 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.3.w.1 4.2.3.w.2 4.2.3.w.3 4.2.3.w.4 4.2.3.w.5 4.2.3.w.6

System Requirements Facilities Requirements, if facilities are not a part of the system per se Support System (ILS) Requirements Production System Requirements Statement of Work Requirements User Training Requirements

Where the process does not apply, the paragraph should so state. The application of requirements analysis to the development of support system (ILS) requirements may be described in a separate Logistics Support Analysis Plan. In this case the information should be summarized here and cross-referenced to the subordinate plan. 4.2.3.x Engineering Specialty Integration in Requirements Analysis This paragraph should describe the means to be used to ensure that engineering specialties such as reliability, maintainability, safety, human machine interface, security, etc. effectively influence the products of requirements analysis. It may, if appropriate, cross-reference additional detail contained in a plan at paragraph 4.7 for each specialty area. 4.2.3.y Tools Usage in Requirements Analysis This paragraph should identify the software and hardware tools, if any, to be used for requirements analysis, and describe the planned purpose and method of usage. Example tools that may be addressed by this paragraph are requirements databases and structured analysis tools. 4.2.3.z Risk and Contingency in Requirements Analysis This paragraph should summarize those aspects of the planned requirements analysis activities that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realised during the course of the Project. 4.2.4

Development of Logical Solution Descriptions

The subparagraphs of this paragraph should describe plans and processes for the development of logical solution descriptions. viz, logical analysis of solution architectures based on one or more concepts of physical solution to satisfy requirements. Separate, detailed procedures and standards should be incorporated by reference, where applicable. 4.2.4.1 Summary of Development of Logical Solution Descriptions This paragraph should summarize the process of development of logical solutions as an integrated process, based upon inputs from requirements analysis and development of physical solution descriptions, and referring to the techniques described in the paragraphs below, as applicable. The paragraph should describe the outputs expected from the process, and how the quality of the outputs will be assured. 4.2.4.2 Development of Logical Solutions Process Description - [process title] to 4.2.4.v These paragraphs should describe each of the techniques to be used, the criteria for use of the technique, and, where applicable, the detailed selection of technique(s) against each task. Example processes for description include functional flow analysis, performance flowdown, functional interface definition, functional thread analysis and the use of simulation and behavior modeling, fault tree analysis (FTA), failure modes, effects and criticality analysis (FMECA) in developing logical solution descriptions.

www.ppi-int.com Page 8 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.4.w Application of the Development of Logical Solutions Process This paragraph should describe the extent of application of development of logical solutions to each object which is the subject of design within the scope of work to which the SEP applies. The paragraph should define the application of the process to at least the products indicated by the subparagraph titles below: 4.2.4.w.1 4.2.4.w.2 4.2.4.w.3 4.2.4.w.4 4.2.4.w.5

System Facilities, if facilities are not a part of the system per se Support System Production System User Training

Where the process does not apply, the paragraph should so state. The application of development of logical solution descriptions to design of support may be described in a separate Logistics Support Analysis Plan. In this case the information should be summarised here and cross-referenced to the subordinate plan. 4.2.4.x Engineering Specialty Integration in Development of Logical Solutions This paragraph should describe the means to be used to ensure that engineering specialties such as reliability, maintainability, safety, human machine interface, security, etc. effectively influence the products of development of logical solution descriptions. It may, if appropriate, cross-reference additional detail contained in a plan at paragraph 4.7 for each specialty area. 4.2.4.y Tools Usage in Development of Logical Solutions This paragraph should identify the software and hardware tools, if any, to be used for systems analysis, and describe the planned purpose and method of usage of each tool. Example tools that may be addressed by this paragraph are databases, structured analysis tools, simulators and behavior modeling tools. 4.2.4.z Risk and Contingency in Development of Logical Solution Descriptions This paragraph should summarise those aspects of the process that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realised during the course of the project. 4.2.5

Development of Physical Solution Descriptions

The subparagraphs of this paragraph should describe plans and processes for the conduct of development of physical solution descriptions activities, viz the definition of physical solution. Separate, detailed procedures and standards should be incorporated by reference, where applicable. 4.2.5.1 Summary of Development of Physical Solution Descriptions This paragraph should summarize the process of development of physical solution descriptions as an integrated process, based upon inputs from requirements analysis and systems analysis, and referring to the techniques described in the paragraphs below, as applicable. The paragraph should describe the outputs expected from the development of physical solution descriptions process, and how the quality of the outputs will be assured. 4.2.5.2 Development of Physical Solution Descriptions Process Description - [process title] to 4.2.5.u These paragraphs should describe each of the processes to be used in development of physical solution descriptions, the criteria for use of the process, and, where applicable, the detailed selection of technique(s) against each development of physical solution descriptions task. Example processes for description include definition of alternative concepts of physical solution, mapping of functional architectures to physical architectures, definition of physical interfaces, treatment of nonwww.ppi-int.com Page 9 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

developmental items in development of physical solution descriptions, direct requirements flowdown, reconciliation of "black box" requirements with directed design, performance analysis, use of simulation in development of physical solution descriptions, fault tree analysis (FTA), failure modes, effects and criticality analysis (FMECA) and the implementation of value engineering. 4.2.5.v Application of the Development of Physical Solution Descriptions Process This paragraph should describe the extent of application of the development of physical solution descriptions process as described to each object which is the subject of design within the scope of work to which the SEP applies. The paragraph should define the application of the process to at least the products indicated by the subparagraph titles below: 4.2.5.v.1 System 4.2.5.v.2 Facilities, if facilities are not a part of the system per se 4.2.5.v.3 Support System 4.2.5.v.4 Production System 4.2.5.v.5 User Training Where the process does not apply, the paragraph should so state. The application of development of physical solution descriptions to design of support may be described in a separate Logistics Support Analysis Plan. In this case the information should be summarized here and cross-referenced to the subordinate plan. 4.2.5.w Engineering Specialty Integration in Development of Physical Solution Descriptions This paragraph should describe the means to be used to ensure that engineering specialties such as reliability, maintainability, safety, human machine interface, security, etc effectively influence the products of development of physical solution descriptions. It may, if appropriate, cross-reference additional detail contained in a plan at paragraph 4.7 for each specialty area. 4.2.5.x Parts Control This paragraph should state whether parts control is to be employed and if so, define the procedures to be used for parts control. 4.2.5.y Tools Usage in Development of Physical Solution Descriptions This paragraph should identify the software and hardware tools, if any, to be used for development of physical solution descriptions, and describe the planned purpose and method of usage of each tool. Example tools that may be addressed by this paragraph are databases, structured design tools, simulators, optimization tools and parameter budgeting tools. 4.2.5.z Risk and Contingency in Development of Physical Solution Descriptions This paragraph should summarize those aspects of the development of physical solution descriptions process that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realised during the course of the Project. 4.2.6

Evaluation and Decision

4.2.6.1 Summary of the Engineering Decision Making Process This paragraph should summarize the process of system/cost effectiveness analyses and any other approaches to be used in engineering decision making. The paragraph should describe the integration of system/cost effectiveness analysis with other efforts of the enterprise's engineering process. If analyses which integrate all measures of effectiveness are not to be conducted, a description of how individual analytic results will be integrated into the evaluation and decision process should be provided. A description of how analyses will be conducted at levels of design below the highest level and how such lower level analyses will be related to higher level measures of effectiveness should also be provided.

www.ppi-int.com Page 10 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.6.2 Criteria for Use of Trade-off Studies This paragraph should define the criteria for determining when formal trade-off studies are to be used. 4.2.6.3 Conduct of Trade-off Studies This paragraph should identify the major trade-off studies to be accomplished and the plan for their accomplishment. The method(s) for identifying, performing and documenting the results of trade-off studies should be included. 4.2.6.4 Decision Models This paragraph should identify any decision models to be used. The paragraph should also define the procedures for the construction of decision models, including sources of decision criteria, weighting of the influence of criteria from different sources, setting criteria worst and best case limits, and model types. The paragraph should define methods or guidelines for the characterization of decision alternatives, including handling of risk and uncertainty. 4.2.6.5 Application of the Evaluation and Decision Process This paragraph should describe the extent of application of the decision making process as described to each object which is the subject of design within the scope of work to which the SEP applies. The paragraph should define the application of the process to at least the products indicated by the subparagraph titles below: 4.2.6.5.1 System 4.2.6.5.2 Facilities, if facilities are not a part of the system per se 4.2.6.5.3 Support System 4.2.6.5.4 Production System Where the process does not apply, the paragraph should so state. The application of the decision making processes to design of support may be described in a separate Logistics Support Analysis Plan. In this case, the information should be summarized here and crossreferenced to the subordinate plan. 4.2.6.6 Engineering Specialty Integration in Evaluation and Decision This paragraph should describe the means to be used to ensure that engineering specialties such as reliability, maintainability, safety, human machine interface, security, etc. effectively influence the decision making process. It may, if appropriate, cross-reference additional detail contained in a plan at paragraph 4.7 for each specialty area. 4.2.6.7 Tools Usage in Evaluation and Decision This paragraph should identify the software and hardware tools, if any, to be used for engineering evaluation and decision, and describe the planned purpose and method of usage of each tool. Example tools that may be addressed by this paragraph are spreadsheets, analytic hierarchy tools, multiple attribute utility technique tools and quality function deployment (QFD) tools. 4.2.6.8 Risk and Contingency in Evaluation and Decision This paragraph should summarize those aspects of the engineering evaluation and decision process that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realised during the course of the project. 4.2.7

Description of System Elements

www.ppi-int.com Page 11 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.7.1 Summary of the Specification Process This paragraph should summarize the overall approach to development of specifications of elements of the system solution. The role of a Specification Tree or equivalent should be discussed, and standards for its construction provided. 4.2.7.2 Specification Types and Formats This paragraph should identify the specification types and formats to be used, and the criteria for the use of each specification type. 4.2.7.3 Specification Structuring This paragraph should establish the principles to be used in developing the structure of specifications. 4.2.7.4 Engineering Specialty Integration in the Specification Process This paragraph should describe the means to be used to ensure that engineering specialties such as reliability, maintainability, safety, human machine interface, security, etc effectively influence the description of system elements. It may, if appropriate, cross-reference additional detail contained in a plan at paragraph 4.7 for each specialty area. 4.2.7.5 Tools Usage in the Specification Process This paragraph should identify the software and hardware tools, if any, to be used for specification development, and describe the planned purpose and method of usage of each tool. Example tools that may be addressed by this paragraph are databases, requirements management tools, structured analysis tools, specification DID tailoring tools and specification templates. 4.2.7.6 Risk and Contingency in Specification Development This paragraph should summarize those aspects of the planned specification activity that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.2.8

Life Cycle Application of the Engineering Process

This paragraph should describe the application of the engineering process throughout the project life. The criteria for and means of update of engineering data should also be described, with reference to the configuration control procedures described in 4.2.11.3.8. 4.2.9

System Integration

4.2.9.1 System Integration Process This paragraph should describe the process by which the system is integrated and assembled, with emphasis on risk management and continuing verification of all external and internal interfaces (physical and functional). 4.2.9.2 Risk and Contingency in System Integration This paragraph should summarise those aspects of system integration that give rise to cost, schedule, product quality or other risk, how these risks have been minimised, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.2.10

Verification and Validation

4.2.10.1 Reviews The subparagraphs of this paragraph should describe criteria and procedures for engineering participation in project reviews and the conduct of requirements, design and functional reviews. www.ppi-int.com Page 12 of 20

5.

4.2.10.1.1

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

Project Reviews

This paragraph should describe the participation of the technical function in project-wide reviews. In particular, the manner in which the enterprise will assess, reoptimize and redirect as necessary the technical program effort during the course of the project should be described. 4.2.10.1.2

Requirements Reviews

This paragraph should set forth the enterprise's proposed plan and schedule for all requirements reviews. This paragraph should describe what kinds of documentation should be provided prior to and at the various requirements reviews, and how this data relates to any contractually required data, e.g. deliverable specifications, requirements traceability databases and testing-related data. 4.2.10.1.3

Design Reviews

This paragraph should set forth the enterprise's proposed plan and schedule for all design reviews to be performed, including architectural design reviews and detailed design reviews at each level of the system physical design. This paragraph should describe what kinds of documentation should be provided prior to and at the various design reviews, how this data relates to any contractually required data, e.g. technical manuals, drawings, specifications, software/firmware documentation, users manuals, and how all these final products relate to each other. 4.2.10.1.4

Functional Reviews

This paragraph should set forth the enterprise's proposed plan and schedule for all functional reviews, e.g. systems engineering, software development, test and evaluation reviews, to be performed. This paragraph should describe what kinds of documentation should be provided prior to and at the various functional reviews, how this data relates to other contractually required data, e.g. technical plans, and how these final products relate to each other. 4.2.10.1.5

Conduct of Technical Reviews

This paragraph should describe the planning, administration and conduct of technical reviews. The paragraph should address the distribution of review packages, development of review agenda and the conduct of reviews, including rules for participation and chairpersonship. The total documentation release system should be discussed, including signoff. 4.2.10.2 Developmental Test and Evaluation (DT&E) This paragraph should describe plans and processes for developmental test and evaluation, under the subparagraph headings below, by inclusion or by reference to a Master Test Plan or similar subordinate document. In this case, the information should be summarized here and cross-referenced to the subordinate plan. 4.2.10.2.1 4.2.10.2.2 4.2.10.2.3 4.2.10.2.4 4.2.10.2.5 4.2.10.2.6 4.2.10.2.7 4.2.10.2.8

DT&E Planning DT&E Organization & Staffing DT&E Resources Test Article Manufacture Conduct of DT&E Regression Testing Reporting of DT&E Results DT&E Result Utilization

4.2.10.3 Independent Verification and Validation This paragraph should describe the plans of the enterprise, if any, other than the review described in 4.2.10.1, for the conduct on its own behalf of verification and validation tasks performed by persons who are independent of the persons whose work products are subject to independent verification or validation. This paragraph should also describe the support to be provided by the enterprise to the conduct by agents of a third party, e.g. the customer, of independent verification and validation tasks. www.ppi-int.com Page 13 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

Where independent verification and validation is partly or entirely the subject of a subordinate plan, e.g. an Independent Verification and Validation (IV&V) Plan, then the subordinate plan should be invoked by the SEP in this paragraph, and the specified information should be included in that plan rather than in this paragraph of the SEP. In this case the SEP should contain a summary of the IV&V plans and processes contained in the subordinate plan. 4.2.10.4 Acceptance Test This paragraph should describe plans and processes for acceptance test of the system, if applicable, by inclusion or by reference to a Test and Evaluation Master Plan, Master Test Plan, Acceptance Test Plan or similar subordinate document. If a separate plan is used, the information should be summarized here and cross-referenced to the subordinate plan. 4.2.11

Systems Engineering Management

4.2.11.1 Planning The subparagraphs of this paragraph should describe engineering management planning processes and procedures. 4.2.11.1.1

Revision of the SEP

This paragraph should, in later issues, describe how revisions to the SEP will be developed, approved and incorporated. 4.2.11.1.2

Engineering Program Integration

This paragraph should describe the enterprise's proposed technical program planning and control mechanisms for ensuring the conduct of a totally integrated engineering effort. 4.2.11.1.3

Work Breakdown Structure and Specification Tree

This paragraph should describe the manner in which the enterprise’s systems engineering management function is to incorporate the defined technical elements of solution into the work breakdown structure (WBS). This paragraph should also describe the relationship between the development of the system design, the specification tree or equivalent and the WBS. 4.2.11.1.4

Resource Allocation

This paragraph should describe the technical basis and rationale for resource allocation to program technical tasks. This paragraph may include procedures for resource requirements identification, control and reallocation. If this information is specified elsewhere, the information should not be duplicated but a cross reference to the location of the information provided. 4.2.11.2 Creative Environment and Technique This paragraph should describe the approach to be implemented to creation and maintenance of a technical work environment which fosters and harnesses creativity. 4.2.11.3 Control The subparagraphs of this paragraph should describe how control of the technical program is to be exercised. 4.2.11.3.1

Work Authorisation

This paragraph should describe the method by which work packages are initiated (opened) and the criteria for their closeout as well as the method by which changes to the content of work packages will be authorized If this information is specified elsewhere, the information should not be duplicated but a cross reference to the location of the information provided.

www.ppi-int.com Page 14 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.11.3.2

Cost Control

This paragraph should describe how cost of the technical program is to be controlled. If this information is specified elsewhere, the information should not be duplicated but a cross reference to the location of the information provided. 4.2.11.3.3

Schedule Control

This paragraph should describe how accomplishment of scheduled milestones of the technical program is to be controlled. If this information is specified elsewhere, the information should not be duplicated but a cross reference to the location of the information should be provided. 4.2.11.3.4

Technical Performance Measurement

This paragraph should describe the approach to and methods to be used for establishing, maintaining, and reporting of technical performance measurement (TPM) parameters which reflect key requirements, design and process parameters. This paragraph should include: a.

TPM update frequencies, level of tracking depth, and response time to generate recovery plans and planned profile revisions;

b.

technical parameters selected for tracking, including, as applicable, system parameters, subsystem parameters and process parameters;

c.

descriptions of risks related to each parameter;

d.

depiction of relationships between each selected critical parameter and those lowerlevel parameters that must be measured to determine the critical parameter achievement value. Discussion of methods, equations or models for transforming parameter values of lower-level elements to those of higher-level elements and their sensitivities should be addressed;

e.

correlation of each parameter with a specific Work Breakdown Structure (WBS) element; and

f.

a description of the means by which technical performance measurement should be related to cost and schedule performance measurement.

The paragraph should include directly or in an annex data for each parameter to be tracked, as follows: a.

specification threshold, technical objective or requirement, or measure of effectiveness (MOE);

b.

time-phased planned value profile with a tolerance band (error budget). The planned value profile should represent the expected trend of the parameter over the subsystem development life cycle. The boundaries of the tolerance band should represent estimated inaccuracies at the time of the estimate, and should indicate the region within which it is expected that the specification requirement will be achieved with allocated resources and planned events and milestones. Events significant to the technical performance measurement should be noted on these profiles.;

c.

program events significantly related to the achievement of the planned value profile (e.g. technical reviews); and

d.

conditions of measurement (type of test, simulation, analysis, demonstration, estimate).

A sample technical performance report for an “out-of-tolerance” technical parameter should be included in this paragraph. This example should include a planned value profile, the planned value, demonstrated value, specification requirement, current estimate at completion and variance analysis. www.ppi-int.com Page 15 of 20

5.

4.2.11.3.5

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

Requirements Traceability

This paragraph should describe the approach and methods to be used to establish and maintain requirements traceability between system requirements and the requirements of lower level elements in the design. The paragraph should also describe the approach and methods to be used to establish and maintain requirements traceability between any Statement of Work or similar requirements, the Project Plan, the SEP and plans subordinate to the SEP. 4.2.11.3.6

Design Traceability

This paragraph should describe the approach and methods to be used to establish and maintain design traceability, viz description and explanation of the design which evidences its correctness, throughout the system development life cycle. 4.2.11.3.7

Test Traceability

This paragraph should describe the approach and methods to be used to establish and maintain test traceability throughout the system development life cycle. 4.2.11.3.8

Configuration Management

This paragraph should describe the approach and methods to be used to establish and maintain configuration management. Where a separate Configuration Management Plan or similar document is used as a subordinate document, this paragraph should summarize the content of the subordinate plan and reference that document. 4.2.11.3.9

Interface Management

This paragraph should describe the enterprise’s procedures for control of the interfaces of the system with external systems, including equipment, facilities, software and personnel under customer control. This paragraph should also describe the enterprise’s procedures for control of the internal interfaces of the system. 4.2.11.3.10

Documentation Control

This paragraph should describe the enterprise’s methods for controlling change to any internal technical data which is not subject to control by the configuration management system. 4.2.11.3.11

Use and Control of Intellectual Property

This paragraph should describe the enterprise’s methods for controlling within the technical program the use of the intellectual property of others and the protection of the intellectual property of the enterprise. 4.2.11.3.12

Subcontractor Technical Effort

This paragraph should describe how vendors and suppliers are to be selected and controlled. This paragraph should describe the technical management of suppliers and subcontractors including integration of their technical efforts and data into the overall systems engineering effort, and the integration of subcontractor data into design records. 4.2.11.3.13

Risk Management

This paragraph should describe those processes, if any, unique to the technical program, for the analysis and management of risk having its origins in the technical program. Where processes to be used are described in a program-wide risk management planning document, such as the Project Plan or a Risk Management Program Plan, the information should be summarized and referenced, rather than being duplicated in the SEP.

www.ppi-int.com Page 16 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

4.2.11.3.14

Problem Resolution

This paragraph should describe the enterprise's procedures for raising, monitoring the status of and resolving technical, cost and schedule problems. 4.2.11.4

Continuous Improvement

This paragraph should describe the methods adopted, if any, for continuous improvement of engineering and engineering management processes. 4.2.11.5

Security of Technical Data

This paragraph should define any processes to be used to maintain the security of technical data. Where processes to be used are described in the Project-wide security planning document, such as the Project Security Plan or a Security Standard Operating Procedure, the information should be referenced, rather than being duplicated in the SEP. 4.2.11.6

Risk and Contingency in Systems Engineering Management

This paragraph should summarise those aspects of the systems engineering management process that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.3.

Hardware Development

This paragraph should describe plans and methodologies that are to be used uniquely for hardware development. Where general processes described elsewhere in the SEP are to be used for hardware development, e.g. functional analysis, then these processes should be cross-referenced rather than duplicated in this paragraph. Where hardware development is the subject of a subordinate plan, e.g. a Hardware Development Plan, then the subordinate plan should be invoked by the SEP in this paragraph, and the specified information should be included in that plan rather than in the body of the SEP. In this case the SEP may contain a summary of the approach to hardware development contained in the subordinate plan, using at least the subparagraphs below: 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5

Hardware Development Work Plan Hardware Development Process Engineering Specialty Integration Hardware Engineering Management Risk and Contingency in Hardware Development

Where the process does not apply, the paragraph should so state. Paragraph 4.3.5 should summarise those aspects of hardware development that give rise to cost, schedule, product quality or other risk, how these risks have been minimised, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the project. 4.4.

Software Development

This paragraph should describe plans and methodologies that are to be used uniquely for software development. Where general processes described elsewhere in the SEP are to be used for software development, e.g. data flow analysis, behaviour modelling, then these processes should be crossreferenced rather than duplicated in this paragraph. Where software development is the subject of a subordinate plan, e.g. a Software Development Plan, then the subordinate plan should be invoked by the SEP in this paragraph, and the specified information should be included in that plan rather than in the body of the SEP. In this case the SEP may contain a summary of the approach to software development contained in the subordinate plan, using at least the subparagraphs below: 4.4.1 4.4.2 4.4.3 4.4.4

Software Development Work Plan Software Development Process Engineering Specialty Integration Software Engineering Management www.ppi-int.com Page 17 of 20

5. 4.4.5

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued) Risk and Contingency in Software Development

Where the process does not apply, the paragraph should so state. Paragraph 4.4.5 should summarize those aspects of software development planning that give rise to cost, schedule, product quality or other risk, how these risks have been minimised, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.5

Logistics Support Analysis and Design

This paragraph should describe those processes, if any, to be used uniquely for the design of the support system. Where general processes described elsewhere in the SEP are to be used for logistics support analysis, e.g. functional analysis, then these processes should be cross-referenced rather than duplicated in this paragraph. Where an existing process standard such as MIL-STD-1388-1A is to be used for logistics support analysis, then this paragraph should invoke the standard and, where applicable, the selection of tasks from the nominated standard. Where logistics support analysis and design is the subject of a subordinate plan, e.g. a Logistics Support Analysis (LSA) Plan, then the subordinate plan should be invoked by the SEP in this paragraph, and the specified information should be included in that plan rather than in the body of the SEP. In this case the SEP may contain a summary of the approach to logistics support analysis and design contained in the subordinate plan. This paragraph should summarize those aspects of logistics support analysis and design that give rise to project cost, life cycle cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realised during the course of the Project. 4.6.

User Procedures Development

This paragraph should describe the processes, if any, to be used uniquely for operational task analysis and the development of user instructions. This paragraph should summarize those aspects of user procedures development that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.7.

Engineering Specialty Integration

4.7.1

Summary of Approach to Engineering Specialty Integration

This paragraph should summarise the approach across the whole technical program to achieving effective engineering specialty integration. 4.7.2 Engineering Specialty Integration Process Description - [specialty title] to 4.7.x These paragraphs should summarize and cross reference, for each applicable engineering specialty area, the way in which that specialty has been integrated into the overall technical program such as to effectively influence design. Where plans and processes are unique to a specialty area, those plans and processes should be described in full detail in this paragraph. Where the specialty area is the subject of a subordinate plan, e.g. an EMP Control Plan, then the subordinate plan should be invoked by the SEP in this paragraph, and the specified information should be included in that plan rather than in this paragraph of the SEP. In this case the SEP may contain a summary of the specialty plans and processes contained in the subordinate plan.

www.ppi-int.com Page 18 of 20

5.

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

Candidate specialty areas for inclusion in this paragraph include availability, hardware reliability, software reliability, hardware maintainability, software maintainability, electromagnetic compatibility, human factors engineering, health and safety, system technical security, producibility, life cycle costing, test and evaluation, testability and integrated diagnostics (BIT), computer resources and product costing. 4.7.y

Risk and Contingency in Engineering Specialty Integration

This paragraph should summarise those aspects of engineering specialty integration that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.8

Summary of Risk of Technology Origin/Contingency Planning

4.8.1

Transition of Critical Technologies

4.8.1.1 Identification of Key Technologies This paragraph should identify the key technologies on which the success of the technical program relies. 4.8.1.2 Critical Technology Transition This paragraph should summarize those aspects of the planned technologies of implementation that give rise to cost, schedule, product quality or other risk, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the course of the Project. 4.8.2

Other Risk Areas

This paragraph should summarize any other matters that give that give rise to cost, schedule, product quality or other risk related to the technical program and not addressed elsewhere in the SEP, how these risks have been minimized, the assessed levels of residual risk and the contingency plans for responding in a controlled fashion should the residual risks be realized during the Project. 4.9

Related Topics

4.9.1

Long Lead-Time Items

This paragraph should list or reference a list of long lead items, if any, to be subject to acquisition in advance of completion of associated design work. The paragraph should contain an assessment of cost, schedule, product quality or other risk related to the early ordering of long lead items, and should describe how these risks have been minimized and the contingency plans for responding in a controlled fashion should the residual risks associated with long lead time items be realized during the course of the project. 4.9.2

Constraints and Assumptions in Systems Engineering Planning

This paragraph should state the major constraints and assumptions on which the SEP is based. 5.

SYSTEMS ENGINEERING QUALITY ASSURANCE PLANS AND PROCEDURES

If the information is not contained in a separate Quality Assurance Plan or similar, this paragraph should define a set of plans and procedures to be implemented to ensure that the plans and procedures contained in the SEP are being followed and are effective. 6.

NOTES

This paragraph should contain any general information that aids in understanding or using the SEP (e.g. background information, rationale). This paragraph may include the following paragraphs, as applicable. www.ppi-int.com Page 19 of 20

5.

6.x

PREPARATION INSTRUCTIONS - 5.2 Content Requirements (continued)

Requirements Traceability

This paragraph should contain, if applicable: a.

data which details traceability from each provision in the SEP to the requirement(s) in a Statement of Work or higher level requirements which the SEP provisions implement; or alternatively

b.

reference to the document which contains the above requirements traceability information.

Note: Higher level requirements are requirements which are source requirements contained in source documents. Source documents may include high level planning documents, policy documents, standards, legislation, requirements clarification records, etc. 6.2

List of SEP Safety Provisions

This paragraph should list the SEP requirements, if any, specified in 4. and concerned with preventing or minimizing unintended hazards to personnel, property and the physical environment. Examples include restricting the use of dangerous processes; classifying explosives for purposes of shipping, handling and storing, and conduct of a safety program in accordance with a standard such as MILSTD-882D. 6.3

List of SEP Information Security Provisions

This paragraph should list the SEP requirements, if any, specified in 4. and concerned with preventing the disclosure via the engineering program of classified or sensitive information, including information subject to non-disclosure agreements. Examples include threat assessment tasks, IT risk analysis tasks, some types of IV&V task, certification activities, TEMPEST testing and the like. A.

Annexes

Annexes may be used to provide information published separately for convenience in document maintenance or use (e.g. charts, classified data). As applicable, each annex should be referenced in the main body of the document where the data would normally have been provided. Annexes may be bound as separate documents for ease in handling. Annexes should be lettered alphabetically (A, B, etc.). Appendices may be used to annexes. Appendices should be numbered numerically (1, 2, etc.).

www.ppi-int.com Page 20 of 20