- Reduced price
- New
EIA-IS-632
$78.00
$35.10
Save 55%
EIA-IS-632 2015 Edition, July 1, 2015
Systems Engineering
Description / Abstract:
This standard defines a total system approach for the development of systems. The standard 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 standard defines the requirements for technical reviews. The tasks in this standard provide a methodology for evaluating progress in achieving system objectives.
This standard provides a comprehensive, structured, and disciplined approach for all life-cycle phases, including new system product and process developments, upgrades, modifications, and engineering efforts conducted to resolve problems in fielded systems. This standard 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 standard 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.
Systems engineering involves design and management of a total system which includes hardware and software, as well as other system elements. All system elements should be considered in analyses, trade-offs, and engineering methodology.
Background. The systems engineering process is applied iteratively throughout the system life cycle to translate staled problems into design requirements, providing an integrated system solution consisting of people, products, and processes with the capability to satisfy customer needs. See Figure 1 for key terms. Problems are normally expressed in terms of needs for new developments and modifications or, as deficiencies in operating, supporting, or providing training for already-fielded items. Performance-based requirements and alternative solutions to problems are iteratively defined and refined. Solutions may employ existing, limited development, or emerging technologies transitioned from the technology base to product and process applications. Where needed, a technology transition approach is established, implemented and controlled. Transition criteria and implementation methods (what, when, to whom, by whom) are defined cooperatively by the tasking and performing activities and include definition of an acceptable level of maturity for all life cycle products and processes. Selection of preferred solutions is based on cost, schedule, performance, and risk. Technical risk management is integral to the process and includes the identification, quantification, impact assessment and implementation of mitigation measures throughout the life cycle. A comprehensive, responsive verification effort is implemented to ensure that designs satisfy requirements. Progressive verification from individual pieces of the solution (system elements) up through the total system is required. This structured and disciplined systems-engineering process is applied across the eight primary system functions (characteristic actions spanning life cycle requirements) to define and select optimal solutions that solve the problem from a life-cycle perspective, that is, life-cycle-balanced solutions
Application Guidance. This standard applies to the entire product life cycle. This standard applies to all tasking and performing activities. It can be used by the tasking activity to assist in systems engineering planning (in terms of the required systems engineering efforts), as well as the performing activity's planning function (in terms of a responsive proposal and implementation plan). Documents pertaining to the design and management of a total system, hardware and software, as well as other system elements, are considered applicable to the provisions of this standard and subordinate thereto.
Tailoring Guidance. This standard is applied at the discretion of the tasting activity or performing activity. In each application, this standard should be tailored to the specific requirements of a particular program, program phase. Tasks which add unnecessary costs, data, and any factors which do not add value to the process or product should be eliminated. Tailoring takes the form of deletion (removal of tasks not applicable), alteration (modifying tasks to more explicitly reflect the application to a particular effort), or addition (adding tasks to satisfy program requirements).
Tailoring involves selection of the most appropriate, or preferred, documents to be applied, and the precedence of tasks to ensure that the complete task set is integrated, harmonized, and balanced to best achieve total system requirements. Harmonization must include provisions for resolving conflicts among task requirements. This can include procedures ranging from simple notification to notification with solution recommendations and justifications. Each task selected for application must contribute, in a cost-benefit sense, to the final objective. Tasks are not viewed as an end in themselves. The total system approach embodied in this standard provides the process to effect this harmonization.
Tailoring specific tasks requires definition of the depth of detail. level of effort, and the data expected. Tailoring is performed to both breadth and depth based on the program and program phase. Tailoring in breadth of application deals with factors such as types and numbers of systems impacted by the development of a new general application subsystem, the numbers and types of assessments, numbers and types of reviews, and so forth. Tailoring in depth involves decisions concerning the level of detail needed to generate and substantiate the outputs required to satisfy program objectives. The depth of the systems engineering effort varies from program to program in relationship to complexity, uncertainty, urgency, and the willingness to accept risk.
Terms and Designators.
Usage of "Configuration Item'' Designator. Throughout this standard, subsystems, components or other aggregates of hardware and software elements may be considered configuration items.
Usage of "Tasking and Performing Activities''. Throughout this standard, the term "tasking activity" refers to the organization requiring the technical effort. The term "performing activity" refers to that organization doing the technical effort. In other documents the tasking activity is referred to as the "acquirer", "procuring agency", or "customer" and the performing activity is referred to as the "developer" or "supplier."
Usage of "Program". Throughout this standard, the term "program" is used generically to include programs or projects for which systems engineering is tasked or performed.
Usage of "Document" and "Documentation" Throughout this standard, the terms "document" or "documentation" are used to mean a collection of data regardless of its medium.
Order of Precedence. This standard is the top document for a total system approach for the development of products and processes. In the event of a conflict between the text of this standard and any other document, the text of this standard is superseding except for statutory and regulatory requirements.
This standard provides a comprehensive, structured, and disciplined approach for all life-cycle phases, including new system product and process developments, upgrades, modifications, and engineering efforts conducted to resolve problems in fielded systems. This standard 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 standard 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.
Systems engineering involves design and management of a total system which includes hardware and software, as well as other system elements. All system elements should be considered in analyses, trade-offs, and engineering methodology.
Background. The systems engineering process is applied iteratively throughout the system life cycle to translate staled problems into design requirements, providing an integrated system solution consisting of people, products, and processes with the capability to satisfy customer needs. See Figure 1 for key terms. Problems are normally expressed in terms of needs for new developments and modifications or, as deficiencies in operating, supporting, or providing training for already-fielded items. Performance-based requirements and alternative solutions to problems are iteratively defined and refined. Solutions may employ existing, limited development, or emerging technologies transitioned from the technology base to product and process applications. Where needed, a technology transition approach is established, implemented and controlled. Transition criteria and implementation methods (what, when, to whom, by whom) are defined cooperatively by the tasking and performing activities and include definition of an acceptable level of maturity for all life cycle products and processes. Selection of preferred solutions is based on cost, schedule, performance, and risk. Technical risk management is integral to the process and includes the identification, quantification, impact assessment and implementation of mitigation measures throughout the life cycle. A comprehensive, responsive verification effort is implemented to ensure that designs satisfy requirements. Progressive verification from individual pieces of the solution (system elements) up through the total system is required. This structured and disciplined systems-engineering process is applied across the eight primary system functions (characteristic actions spanning life cycle requirements) to define and select optimal solutions that solve the problem from a life-cycle perspective, that is, life-cycle-balanced solutions
Application Guidance. This standard applies to the entire product life cycle. This standard applies to all tasking and performing activities. It can be used by the tasking activity to assist in systems engineering planning (in terms of the required systems engineering efforts), as well as the performing activity's planning function (in terms of a responsive proposal and implementation plan). Documents pertaining to the design and management of a total system, hardware and software, as well as other system elements, are considered applicable to the provisions of this standard and subordinate thereto.
Tailoring Guidance. This standard is applied at the discretion of the tasting activity or performing activity. In each application, this standard should be tailored to the specific requirements of a particular program, program phase. Tasks which add unnecessary costs, data, and any factors which do not add value to the process or product should be eliminated. Tailoring takes the form of deletion (removal of tasks not applicable), alteration (modifying tasks to more explicitly reflect the application to a particular effort), or addition (adding tasks to satisfy program requirements).
Tailoring involves selection of the most appropriate, or preferred, documents to be applied, and the precedence of tasks to ensure that the complete task set is integrated, harmonized, and balanced to best achieve total system requirements. Harmonization must include provisions for resolving conflicts among task requirements. This can include procedures ranging from simple notification to notification with solution recommendations and justifications. Each task selected for application must contribute, in a cost-benefit sense, to the final objective. Tasks are not viewed as an end in themselves. The total system approach embodied in this standard provides the process to effect this harmonization.
Tailoring specific tasks requires definition of the depth of detail. level of effort, and the data expected. Tailoring is performed to both breadth and depth based on the program and program phase. Tailoring in breadth of application deals with factors such as types and numbers of systems impacted by the development of a new general application subsystem, the numbers and types of assessments, numbers and types of reviews, and so forth. Tailoring in depth involves decisions concerning the level of detail needed to generate and substantiate the outputs required to satisfy program objectives. The depth of the systems engineering effort varies from program to program in relationship to complexity, uncertainty, urgency, and the willingness to accept risk.
Terms and Designators.
Usage of "Configuration Item'' Designator. Throughout this standard, subsystems, components or other aggregates of hardware and software elements may be considered configuration items.
Usage of "Tasking and Performing Activities''. Throughout this standard, the term "tasking activity" refers to the organization requiring the technical effort. The term "performing activity" refers to that organization doing the technical effort. In other documents the tasking activity is referred to as the "acquirer", "procuring agency", or "customer" and the performing activity is referred to as the "developer" or "supplier."
Usage of "Program". Throughout this standard, the term "program" is used generically to include programs or projects for which systems engineering is tasked or performed.
Usage of "Document" and "Documentation" Throughout this standard, the terms "document" or "documentation" are used to mean a collection of data regardless of its medium.
Order of Precedence. This standard is the top document for a total system approach for the development of products and processes. In the event of a conflict between the text of this standard and any other document, the text of this standard is superseding except for statutory and regulatory requirements.
EIA-IS-632 2015 Edition, July 1, 2015
Systems Engineering