Systems Engineering Guide - Version 1.1

Keywords guide systems engineering
Metadata
Document identifier
ASC/EN -- SMC/SD
Date published
1996-04-05
Language
English
Pages
6
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
File MIME type Size (KB) Language Download
073GZ001ASC_EN_SMC_SDSEGuid.doc application/msword   56 KB English DOWNLOAD!
File attachments
Extract(s)

Notice

This guide is being published for use within ASC and SMC, to train our people, to foster a consistent systems engineering definition and implementation, and to make the information available to all interested parties.
If you have any questions or comments on this document, please direct them to:
ASC/ENSI Bldg 126
2664 Skyline Dr.
Wright-Patterson AFB, OH 45433-7800
This document is based on the development and coordination of MIL-STD-499B (Draft, 6 May 1994), Systems Engineering. MIL-STD-499B had an extensive review and coordination under the auspices of a Joint OSD/Services/Industry Working Group and was coordinated by the Army, Navy, and Air Force. Final approval by the DoD as a military standard was withheld as part of the Department’s reevaluation of its entire approach to standardization. Appendix D, on technical reviews, underwent the same scrutiny as the other attachments however it was not included in the final “for approval/coordination” package that went to the service standardization executives.

Efforts to revise and replace MIL-STD-499A (May 1974), Engineering Management, with a more pertinent and suitable Systems Engineering document have been underway for over a decade. The origins of this document trace back to an Aeronautical Systems Center (ASC) effort initiated in 1989 that was termed Systems Engineering Manual (SEM) 1-1. After some revisions, it was selected in May 1991 by a Tri-Service and Industry Steering Committee sponsored by AFSC as the basis for the proposed MIL-STD-499B, Systems Engineering. A “Pre-Coordination” draft (15 May 1991) was circulated for review, and a “For Coordination” draft (6 May 1992) was widely distributed for review in late July 1992. After an extensive 15 month review, comment assessment and resolution, and document revision effort (including the formation of a senior OSD and Services Executive Steering Committee to review issues), the completed document was forwarded to the OSD Standardization Office in mid-October 1993 for approval. As a result of Secretary Perry’s direction on specifications and standards, it was decided to forgo final approval of MIL-STD-499B. This has resulted in a critical shortfall in the definition of the systems engineering process.

/Signed/
Leslie L. Bordelon, SES
Director of Program Management
Space and Missile Systems Center

/Signed/
Maurice R. Himmelberg, SES
Director, Engineering Directorate
Aeronautical Systems Center

Foreword

1. This document defines fundamental systems engineering efforts that, when tailored for specific program efforts and used as a guide for developing systems engineering tasks or as a reference to assess proposed systems engineering tasks, provides the basis for an effective systems engineering implementation for development and modification programs.

2. This document captures the key aspects of the Department of Defense’s (DoD) reform initiatives to: better integrate requirements; implement multidisciplinary teamwork, including potential suppliers, early in establishing the requirements; establish clear measurements of system responsiveness; encourage innovation in products and practices; focus on process control rather than inspection; encourage risk management rather than risk avoidance; eliminate functional stove-pipes; reduce the time it takes to acquire products and services; increase teamwork and cooperation within the government and industry; and encourage tailoring.

3. The intent of this document is to assist in defining, performing, managing, and evaluating systems engineering efforts in defense system acquisitions and technology developments. The scope and requirements of systems engineering are defined in terms of what should be done, not how to do it. As a result, the systems engineering activities to manage are defined, not how to manage them.

4. This document defines an executable systems engineering process and needed systems engineering efforts. In doing this, it implements DoD policy on systems engineering to: translate operational needs and/or requirements into a system solution that includes the design, manufacturing, test and evaluation, and support processes and products; provide a comprehensive, iterative technical process as the basis for integration of all technical efforts; and, establish a proper balance between performance, risk, cost, and schedule encompassing people, products, and processes. The process is applicable in any phase of an effort and for any size or complexity of an effort, and can apply to non-DoD programs with minimal tailoring.

5. This document provides the technical foundation for integrating product and process development. This requires: the simultaneous development of system products and life-cycle processes to satisfy user needs; multidisciplinary teamwork; and a systems engineering approach.

6. This document provides the process to leverage development techniques including streamlined management approaches (e.g., use of Non-Developmental and Military or Commercial Off-The-Shelf items) and commercial leveraging options (e.g., Dual Use Technologies). These leveraged approaches are enabled by emphasizing a performance-based approach to system requirements and then identifying/defining/designing candidate solution alternatives that best satisfy those requirements. Preferred solutions are identified based on cost, schedule, performance, and risk.

7. This document describes the conduct of a complete, integrated technical effort (systems engineering), not the organizational entity or method of implementation. The organization of resources employed to implement this document is expected to vary from program to program.

8. Each program implementation typically employs standardization documentation to satisfy program requirements and to comply with DoD policy. It is the Program Manager’s responsibility to select and tailor those standards which are necessary to execute the program successfully and to ensure that the resulting requirements are incorporated in the integrated technical effort.

9. This document describes the conduct of systems engineering generically. For any given program, only those tasks that are necessary and appropriate should be implemented.

1. -- Scope
This document defines a total system approach for the development of defense systems. The document requires: establishing and implementing a structured, disciplined, and documented systems engineering effort incorporating the systems engineering process; multidisciplinary teamwork; and the simultaneous development of the products and processes needed to satisfy user needs. The systems engineering process is defined generically to facilitate broad application. This document defines the requirements for technical reviews. The tasks in this document provide a methodology for evaluating progress in achieving system objectives. This document provides a comprehensive, structured, and disciplined approach for new system product and process developments, for upgrades, for modifications, and for engineering efforts conducted to resolve problems in fielded systems in all acquisition and support phases. This document is applicable to technical efforts in support of advancement and development of new technologies and their application. It applies to large and small scale systems; to single or multiple procurements; and to the replacement of current products and processes. The document is applicable to systems irrespective of composition including those that are integrated from diverse elements, hardware dominant, and software dominant. This document should be tailored for effective and efficient program implementation.

Note: Systems engineering involves design and management of a total system which includes hardware and software, as well as other system elements. They all should be considered in analyses, trade-offs, and engineering methodology.

Organisation(s)
Editor
Visit also