SMC-S-001
SYSTEMS ENGINEERING REQUIREMENTS AND PRODUCTS
Year: 2010
Abstract: Document Purpose
This standard defines the government's requirements for a disciplined systems engineering approach to system acquisitions. It specifies the government's requirements for executable contractor systems engineering efforts, and can also be used as a guide by the tasking agency/activity to assist in systems engineering planning and management. Government agencies (Department of Defense and the intelligence community) should use this document as a compliance document for system acquisition contracts. It is also applicable to non-DOD government (NASA and others), civil, and commercial developments.
This document's objective is to define the essential work products, produced in the systems engineering process, needed to:
1. Adequately define a system over its life cycle such that the integrated system when deployed:
a. Provides at least the threshold or minimum required capabilities and requirements and is affordable, but otherwise balances capability, cost, schedule, risk, and the potential for evolutionary growth
b. Is defined by operations concepts, operational capabilities/requirements, system architectures, specifications, drawings, technical orders, training documents, maintenance facilities and equipment documents, verification and validation plans, procedures, and reports
c. Includes the documented processes that are essential to build-to, buy-to, code-to, verifyto, deploy-to, train-to, operate-to, support/sustain-to, and dispose-to over the system life cycle
d. Has system definition products satisfying this objective, referred to as the system configuration baseline 2. Define products that can be used throughout the intermediate development stages by the tasking and performing activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program.
2. Define products that can be used throughout the intermediate development stages by the tasking and performing activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program.
Document Organization
Each systems engineering functional (process) area is presented in this document using the following format:
1. Functional area requirement
2. Required systems engineering products
3. Required product characteristics
Each general requirement stated in the Requirements sections contains the contractor's requirement for performance of the specific systems engineering function/process as expressed in a "shall" statement. Each section entitled "Required Systems Engineering Products" provides a list of products required to comply with the general requirement. The section entitled "Required Product Attributes" describes the characteristics of each required systems engineering product.Intended Use: This section contains information for reference only. The primary purpose of this document is to be specified by the government on space system development contracts as a compliance document. Therefore, the requirements herein are intended to be contractor requirements. This document, however, can be used by the government as a guide to assist in systems engineering planning in terms of the required systems engineering efforts. Programs for which a government activity plays a "contractor" role should implement this standard under a "contract" to the tasking government activity. A single, integrated set of technical tasks should be developed. This can be accomplished by integrating all the tasks in the contract's Statement Of Work (SOW), tailoring this document to include tasks from other standards selected for contractual application, executing the complete, integrated task set via the Systems Engineering Management Plan (SEMP), or some appropriate combination of these alternatives. Regardless of the approach taken to place the tasks of this standard on contract, the SEMP should be the single, integrated technical planning document. This standard can be used by the government as follows: a. For defining the government's requirements for systems engineering in a request for proposal (RFP) or contract. Toward this end, the requirements in this section can be applied by tailoring the requirements in Subsection 4.2 and definitions in Section 3.0 consistent with the objectives and constraints of the program and contract, or by developing tailoring for additional government, NSS industry, or professional society systems engineering standards to bring them into compliance with Sections 4.2 and 3.0 below. The resulting document(s) should then be included in the list of compliance documents in the RFP. b. To be incorporated by reference in Section M, "Evaluation Criteria and/or Source Selection Standards" for evaluating either: (1) Proposed alternative standards or corporate policies, or (2) Further tailoring of a standard listed in the RFP. The tailored standard that proves to be acceptable to the government should then be placed on contract as a compliance document. c. As a "checklist" for monitoring the contractor's systems engineering processes and products. This standard applies to all acquisition phases of DODI 5000.02. The requirements herein provide important steps in implementing DOD direction to managed acquisition programs through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. The continuous application of a robust systems engineering methodology also serves as a way to ensure effective sustainment of weapon systems through design and development of reliable and maintainable systems. Many other DOD directives and instructions, such as those for affordability, safety, and human factors, also require "the continuous application of a robust systems engineering methodology." While all of the requirements in Subsection 4.2 collectively respond to these directives, those under Tradeoff Analyses and Effectiveness and Cost Analyses are specifically responsive. Similarly, systems engineering is a core issue to be addressed at each major milestone review.
This standard defines the government's requirements for a disciplined systems engineering approach to system acquisitions. It specifies the government's requirements for executable contractor systems engineering efforts, and can also be used as a guide by the tasking agency/activity to assist in systems engineering planning and management. Government agencies (Department of Defense and the intelligence community) should use this document as a compliance document for system acquisition contracts. It is also applicable to non-DOD government (NASA and others), civil, and commercial developments.
This document's objective is to define the essential work products, produced in the systems engineering process, needed to:
1. Adequately define a system over its life cycle such that the integrated system when deployed:
a. Provides at least the threshold or minimum required capabilities and requirements and is affordable, but otherwise balances capability, cost, schedule, risk, and the potential for evolutionary growth
b. Is defined by operations concepts, operational capabilities/requirements, system architectures, specifications, drawings, technical orders, training documents, maintenance facilities and equipment documents, verification and validation plans, procedures, and reports
c. Includes the documented processes that are essential to build-to, buy-to, code-to, verifyto, deploy-to, train-to, operate-to, support/sustain-to, and dispose-to over the system life cycle
d. Has system definition products satisfying this objective, referred to as the system configuration baseline 2. Define products that can be used throughout the intermediate development stages by the tasking and performing activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program.
2. Define products that can be used throughout the intermediate development stages by the tasking and performing activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program.
Document Organization
Each systems engineering functional (process) area is presented in this document using the following format:
1. Functional area requirement
2. Required systems engineering products
3. Required product characteristics
Each general requirement stated in the Requirements sections contains the contractor's requirement for performance of the specific systems engineering function/process as expressed in a "shall" statement. Each section entitled "Required Systems Engineering Products" provides a list of products required to comply with the general requirement. The section entitled "Required Product Attributes" describes the characteristics of each required systems engineering product.Intended Use: This section contains information for reference only. The primary purpose of this document is to be specified by the government on space system development contracts as a compliance document. Therefore, the requirements herein are intended to be contractor requirements. This document, however, can be used by the government as a guide to assist in systems engineering planning in terms of the required systems engineering efforts. Programs for which a government activity plays a "contractor" role should implement this standard under a "contract" to the tasking government activity. A single, integrated set of technical tasks should be developed. This can be accomplished by integrating all the tasks in the contract's Statement Of Work (SOW), tailoring this document to include tasks from other standards selected for contractual application, executing the complete, integrated task set via the Systems Engineering Management Plan (SEMP), or some appropriate combination of these alternatives. Regardless of the approach taken to place the tasks of this standard on contract, the SEMP should be the single, integrated technical planning document. This standard can be used by the government as follows: a. For defining the government's requirements for systems engineering in a request for proposal (RFP) or contract. Toward this end, the requirements in this section can be applied by tailoring the requirements in Subsection 4.2 and definitions in Section 3.0 consistent with the objectives and constraints of the program and contract, or by developing tailoring for additional government, NSS industry, or professional society systems engineering standards to bring them into compliance with Sections 4.2 and 3.0 below. The resulting document(s) should then be included in the list of compliance documents in the RFP. b. To be incorporated by reference in Section M, "Evaluation Criteria and/or Source Selection Standards" for evaluating either: (1) Proposed alternative standards or corporate policies, or (2) Further tailoring of a standard listed in the RFP. The tailored standard that proves to be acceptable to the government should then be placed on contract as a compliance document. c. As a "checklist" for monitoring the contractor's systems engineering processes and products. This standard applies to all acquisition phases of DODI 5000.02. The requirements herein provide important steps in implementing DOD direction to managed acquisition programs through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. The continuous application of a robust systems engineering methodology also serves as a way to ensure effective sustainment of weapon systems through design and development of reliable and maintainable systems. Many other DOD directives and instructions, such as those for affordability, safety, and human factors, also require "the continuous application of a robust systems engineering methodology." While all of the requirements in Subsection 4.2 collectively respond to these directives, those under Tradeoff Analyses and Effectiveness and Cost Analyses are specifically responsive. Similarly, systems engineering is a core issue to be addressed at each major milestone review.
Show full item record
contributor author | AIR FORCE - 02 - Air Force Network Integration Center (AFNIC) | |
date accessioned | 2017-09-04T16:39:49Z | |
date available | 2017-09-04T16:39:49Z | |
date copyright | 07/12/2010 | |
date issued | 2010 | |
identifier other | VMDQJEAAAAAAAAAA.pdf | |
identifier uri | https://yse.yabesh.ir/std/handle/yse/103526 | |
description abstract | Document Purpose This standard defines the government's requirements for a disciplined systems engineering approach to system acquisitions. It specifies the government's requirements for executable contractor systems engineering efforts, and can also be used as a guide by the tasking agency/activity to assist in systems engineering planning and management. Government agencies (Department of Defense and the intelligence community) should use this document as a compliance document for system acquisition contracts. It is also applicable to non-DOD government (NASA and others), civil, and commercial developments. This document's objective is to define the essential work products, produced in the systems engineering process, needed to: 1. Adequately define a system over its life cycle such that the integrated system when deployed: a. Provides at least the threshold or minimum required capabilities and requirements and is affordable, but otherwise balances capability, cost, schedule, risk, and the potential for evolutionary growth b. Is defined by operations concepts, operational capabilities/requirements, system architectures, specifications, drawings, technical orders, training documents, maintenance facilities and equipment documents, verification and validation plans, procedures, and reports c. Includes the documented processes that are essential to build-to, buy-to, code-to, verifyto, deploy-to, train-to, operate-to, support/sustain-to, and dispose-to over the system life cycle d. Has system definition products satisfying this objective, referred to as the system configuration baseline 2. Define products that can be used throughout the intermediate development stages by the tasking and performing activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program. 2. Define products that can be used throughout the intermediate development stages by the tasking and performing activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program. Document Organization Each systems engineering functional (process) area is presented in this document using the following format: 1. Functional area requirement 2. Required systems engineering products 3. Required product characteristics Each general requirement stated in the Requirements sections contains the contractor's requirement for performance of the specific systems engineering function/process as expressed in a "shall" statement. Each section entitled "Required Systems Engineering Products" provides a list of products required to comply with the general requirement. The section entitled "Required Product Attributes" describes the characteristics of each required systems engineering product.Intended Use: This section contains information for reference only. The primary purpose of this document is to be specified by the government on space system development contracts as a compliance document. Therefore, the requirements herein are intended to be contractor requirements. This document, however, can be used by the government as a guide to assist in systems engineering planning in terms of the required systems engineering efforts. Programs for which a government activity plays a "contractor" role should implement this standard under a "contract" to the tasking government activity. A single, integrated set of technical tasks should be developed. This can be accomplished by integrating all the tasks in the contract's Statement Of Work (SOW), tailoring this document to include tasks from other standards selected for contractual application, executing the complete, integrated task set via the Systems Engineering Management Plan (SEMP), or some appropriate combination of these alternatives. Regardless of the approach taken to place the tasks of this standard on contract, the SEMP should be the single, integrated technical planning document. This standard can be used by the government as follows: a. For defining the government's requirements for systems engineering in a request for proposal (RFP) or contract. Toward this end, the requirements in this section can be applied by tailoring the requirements in Subsection 4.2 and definitions in Section 3.0 consistent with the objectives and constraints of the program and contract, or by developing tailoring for additional government, NSS industry, or professional society systems engineering standards to bring them into compliance with Sections 4.2 and 3.0 below. The resulting document(s) should then be included in the list of compliance documents in the RFP. b. To be incorporated by reference in Section M, "Evaluation Criteria and/or Source Selection Standards" for evaluating either: (1) Proposed alternative standards or corporate policies, or (2) Further tailoring of a standard listed in the RFP. The tailored standard that proves to be acceptable to the government should then be placed on contract as a compliance document. c. As a "checklist" for monitoring the contractor's systems engineering processes and products. This standard applies to all acquisition phases of DODI 5000.02. The requirements herein provide important steps in implementing DOD direction to managed acquisition programs through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. The continuous application of a robust systems engineering methodology also serves as a way to ensure effective sustainment of weapon systems through design and development of reliable and maintainable systems. Many other DOD directives and instructions, such as those for affordability, safety, and human factors, also require "the continuous application of a robust systems engineering methodology." While all of the requirements in Subsection 4.2 collectively respond to these directives, those under Tradeoff Analyses and Effectiveness and Cost Analyses are specifically responsive. Similarly, systems engineering is a core issue to be addressed at each major milestone review. | |
language | English | |
title | SMC-S-001 | num |
title | SYSTEMS ENGINEERING REQUIREMENTS AND PRODUCTS | en |
type | standard | |
page | 85 | |
status | Active | |
tree | AIR FORCE - 02 - Air Force Network Integration Center (AFNIC):;2010 | |
contenttype | fulltext |