System Concept Definition: Difference between revisions
m (Cdhoffman moved page Business and Mission Analysis to Concept Definition over a redirect without leaving a redirect: CM request - change approved 14 Jan 2024. ) |
(Added more RWG content, blended in original content) |
||
| Line 1: | Line 1: | ||
---- | ---- | ||
'''''Lead Author:''''' ''Tami Katz'' '''''Contributing Authors:''''' ''Lou Wheatcraft, Mike Ryan'' | '''''Lead Author:''''' ''Tami Katz'' '''''Contributing Authors:''''' ''Garry Roedler, Rick Adcock, Lou Wheatcraft, Mike Ryan'' | ||
{{Term|Concept (glossary)|Concept}} Definition is the set of systems engineering (SE) activities in which the problem space as well as the needs and requirements of the business (or enterprise) and {{Term|Stakeholder (glossary)|stakeholders}} are closely examined. Concept Definition begins before any formal definition of the {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) is developed. | {{Term|Concept (glossary)|Concept}} Definition is the set of systems engineering (SE) activities in which the problem space as well as the needs and requirements of the business (or enterprise) and {{Term|Stakeholder (glossary)|stakeholders}} are closely examined. Concept Definition begins before any formal definition of the {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) is developed. | ||
| Line 8: | Line 6: | ||
The Concept Definition activities include ''Business or Mission Analysis'' and ''Stakeholder Needs Definitio''n. With these two Concept Definition activities, business or enterprise decision makers, as well as additional key stakeholders, describe ''what'' a solution should accomplish and ''why'' it is needed. Both ''why'' and ''what'' need to be answered before consideration is given to ''how'' the problem will be addressed (i.e., what type of solution will be implemented) and ''how'' the solution will be defined and developed. | The Concept Definition activities include ''Business or Mission Analysis'' and ''Stakeholder Needs Definitio''n. With these two Concept Definition activities, business or enterprise decision makers, as well as additional key stakeholders, describe ''what'' a solution should accomplish and ''why'' it is needed. Both ''why'' and ''what'' need to be answered before consideration is given to ''how'' the problem will be addressed (i.e., what type of solution will be implemented) and ''how'' the solution will be defined and developed. | ||
The specific activities and sequence of Concept Definition activities, their involvement with the | The specific activities and sequence of Concept Definition activities, their involvement with the lifecycle activities of any system, will be dependent upon the type of {{Term|Life Cycle Model (glossary)|lifecycle model}} being utilized. See [[Applying Life Cycle Processes]] for further discussion of the concurrent, iterative and recursive nature of these relationships. | ||
== Topics== | == Topics== | ||
| Line 19: | Line 17: | ||
There are two primary activities discussed under Concept Definition: Business or {{Term|Mission Analysis (glossary)|Mission Analysis}} and the definition of [[Stakeholder Needs and Requirements|Stakeholder Needs:]] | There are two primary activities discussed under Concept Definition: Business or {{Term|Mission Analysis (glossary)|Mission Analysis}} and the definition of [[Stakeholder Needs and Requirements|Stakeholder Needs:]] | ||
#The [[Business or Mission Analysis]] activity establishes the problem or opportunity being addressed which could result in a new or modified product, service or enterprise. This process also includes identification of major stakeholders, the mission, goals and objectives of the SoI, the measures of success, identification of business needs and requirements, and identification of the SoI | #The [[Business or Mission Analysis]] activity establishes the problem or opportunity being addressed which could result in a new or modified product, service or enterprise. This process also includes identification of major stakeholders, the mission, goals and objectives of the SoI, the measures of success, identification of business needs and requirements, and identification of the SoI lifecycle concepts. | ||
#The [[Stakeholder Needs and Requirements|Stakeholder Needs]] Definition activity uses the inputs of the Business or Mission Analysis effort to identify an integrated set of needs [add new glossary term] based on inputs from the major stakeholders, as well as analysis of the | #The [[Stakeholder Needs and Requirements|Stakeholder Needs]] Definition activity uses the inputs of the Business or Mission Analysis effort to identify an integrated set of needs [add new glossary term] based on inputs from the major stakeholders, as well as analysis of the lifecycle concepts, drivers, constraints, and risks. | ||
The products and artifacts produced during Concept Definition are then used in the {{Term|System Definition (glossary)|System Definition}} process, as shown in Figure 1. | The products and artifacts produced during Concept Definition are then used in the {{Term|System Definition (glossary)|System Definition}} process, as shown in Figure 1. | ||
| Line 28: | Line 26: | ||
The SEBoK Part 2 provides guidance on how {{Term|Systems Thinking (glossary)|systems thinking}} is applicable to concept definition efforts, and in [[Identifying and Understanding Problems and Opportunities]]. Additional guidance is also provided in the INCOSE Needs and Requirements Manual. | The SEBoK Part 2 provides guidance on how {{Term|Systems Thinking (glossary)|systems thinking}} is applicable to concept definition efforts, and in [[Identifying and Understanding Problems and Opportunities]]. Additional guidance is also provided in the INCOSE Needs and Requirements Manual. | ||
==Drivers of Concept Definition== | |||
There are many considerations associated with concept definition activities, which are further elaborated below. | |||
=== The Role of Architecture Development during Concept Definition === | |||
The concept definition activities of Business or {{Term|Mission Analysis (glossary)|Mission Analysis}} and [[Stakeholder Needs and Requirements|Stakeholder Needs]] Definition occur concurrently with the processes of [https://sebokwiki.org/wiki/System_Architecture System Architecture Definition]. The activities to address a full set of needs includes identification of SoI lifecycle concepts, external interfaces and constraints, as well as candidate solutions and an exploration of the logical architecture. | |||
=== Drivers of Solution on Problem Definition === | |||
Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. System Analysis activities are used to provide the link between problems and solutions. | |||
There are two paradigms that drive the ways in which concept definition is done: push and pull. The pull paradigm is based on providing a solution to an identified problem or gap, such as a missing mission capability for defense or infrastructure. The push paradigm is based on creating a solution to address a perceived opportunity, such as the emergence of an anticipated product or service that is attractive to some portion of the population (i.e. whether a current market exists or not). This can impact other lifecycle processes, such as in verification and validation, or alpha/beta testing as done in some commercial domains. | |||
As systems generally integrate existing and new system elements in a mixture of push and pull, it is often best to combine a bottom-up approach with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities that must be provided in order to define applicable interface requirements and constraints. This is discussed in [https://sebokwiki.org/wiki/Applying_Life_Cycle_Processes Applying Life Cycle Processes]. | |||
=== New System or Modification of Existing System === | |||
The activities of Concept Definition determine whether the enterprise strategic goals and business needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. | |||
For a new system, organization or customer has decided to start with a “blank piece of paper”. This may be referred to as a Green-field system, and analysis efforts during concept definition characterize the as-is or present-state of the organization in terms of the problem, threat, or opportunity and then characterize the to-be or future-state of the organization in terms of the resolution of the problem, threat, or the ability to pursue the opportunity. | |||
There are cases where an existing system can be evolved or transformed into the desired system. This may be referred to as a Brown-field system, and the data that has been established for the original system can be used as inputs into the analysis efforts during concept definition activities. The heritage system may have been developed for other purposes, the analysis effort will explore the problem space and possible solutions in the gaps of the original system to address the problem, threat or opportunity. | |||
==References== | ==References== | ||
| Line 34: | Line 51: | ||
===Primary References=== | ===Primary References=== | ||
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. | |||
INCOSE. 2023. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0. | INCOSE. 2023. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0. | ||
INCOSE. 2022. INOSE Needs and Requirements Manual, version 1.1. INCOSE-TP-2021-002-01. | INCOSE. 2022. INOSE Needs and Requirements Manual, version 1.1. INCOSE-TP-2021-002-01. | ||
ISO/IEC/IEEE. 2023. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2023. | ISO/IEC/IEEE. 2023. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2023. | ||
===Additional References=== | ===Additional References=== | ||
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons. | |||
ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. | |||
Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E). <nowiki>http://www.hitchins.net/</nowiki> EmergenceEtc.pdf. | |||
INCOSE. 2022. INOSE Guide to Needs and Requirements Manual, version 1. INCOSE-TP-2021-003-01 | INCOSE. 2022. INOSE Guide to Needs and Requirements Manual, version 1. INCOSE-TP-2021-003-01 | ||
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007. | |||
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight. (April 2010): 41-43. | |||
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105. | |||
---- | ---- | ||
Revision as of 17:11, 19 February 2024
Lead Author: Tami Katz Contributing Authors: Garry Roedler, Rick Adcock, Lou Wheatcraft, Mike Ryan
Concept Definition is the set of systems engineering (SE) activities in which the problem space as well as the needs and requirements of the business (or enterprise) and stakeholders are closely examined. Concept Definition begins before any formal definition of the system-of-interest (SoI) is developed.
The Concept Definition activities include Business or Mission Analysis and Stakeholder Needs Definition. With these two Concept Definition activities, business or enterprise decision makers, as well as additional key stakeholders, describe what a solution should accomplish and why it is needed. Both why and what need to be answered before consideration is given to how the problem will be addressed (i.e., what type of solution will be implemented) and how the solution will be defined and developed.
The specific activities and sequence of Concept Definition activities, their involvement with the lifecycle activities of any system, will be dependent upon the type of lifecycle model being utilized. See Applying Life Cycle Processes for further discussion of the concurrent, iterative and recursive nature of these relationships.
Topics
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This Concept Definition KA contains the following topics:
See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 as well as topics covered in Part 3.
Concept Definition Activities
There are two primary activities discussed under Concept Definition: Business or Mission Analysis and the definition of Stakeholder Needs:
- The Business or Mission Analysis activity establishes the problem or opportunity being addressed which could result in a new or modified product, service or enterprise. This process also includes identification of major stakeholders, the mission, goals and objectives of the SoI, the measures of success, identification of business needs and requirements, and identification of the SoI lifecycle concepts.
- The Stakeholder Needs Definition activity uses the inputs of the Business or Mission Analysis effort to identify an integrated set of needs [add new glossary term] based on inputs from the major stakeholders, as well as analysis of the lifecycle concepts, drivers, constraints, and risks.
The products and artifacts produced during Concept Definition are then used in the System Definition process, as shown in Figure 1.
[insert Figure here]
Figure 1. Concept Definition establishes the purpose and expectations of the SoI, which is used as input the System Definition Process. Original SEBoK figure derived from ISO 15288-2023.
The SEBoK Part 2 provides guidance on how systems thinking is applicable to concept definition efforts, and in Identifying and Understanding Problems and Opportunities. Additional guidance is also provided in the INCOSE Needs and Requirements Manual.
Drivers of Concept Definition
There are many considerations associated with concept definition activities, which are further elaborated below.
The Role of Architecture Development during Concept Definition
The concept definition activities of Business or Mission Analysis and Stakeholder Needs Definition occur concurrently with the processes of System Architecture Definition. The activities to address a full set of needs includes identification of SoI lifecycle concepts, external interfaces and constraints, as well as candidate solutions and an exploration of the logical architecture.
Drivers of Solution on Problem Definition
Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. System Analysis activities are used to provide the link between problems and solutions.
There are two paradigms that drive the ways in which concept definition is done: push and pull. The pull paradigm is based on providing a solution to an identified problem or gap, such as a missing mission capability for defense or infrastructure. The push paradigm is based on creating a solution to address a perceived opportunity, such as the emergence of an anticipated product or service that is attractive to some portion of the population (i.e. whether a current market exists or not). This can impact other lifecycle processes, such as in verification and validation, or alpha/beta testing as done in some commercial domains.
As systems generally integrate existing and new system elements in a mixture of push and pull, it is often best to combine a bottom-up approach with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities that must be provided in order to define applicable interface requirements and constraints. This is discussed in Applying Life Cycle Processes.
New System or Modification of Existing System
The activities of Concept Definition determine whether the enterprise strategic goals and business needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution.
For a new system, organization or customer has decided to start with a “blank piece of paper”. This may be referred to as a Green-field system, and analysis efforts during concept definition characterize the as-is or present-state of the organization in terms of the problem, threat, or opportunity and then characterize the to-be or future-state of the organization in terms of the resolution of the problem, threat, or the ability to pursue the opportunity.
There are cases where an existing system can be evolved or transformed into the desired system. This may be referred to as a Brown-field system, and the data that has been established for the original system can be used as inputs into the analysis efforts during concept definition activities. The heritage system may have been developed for other purposes, the analysis effort will explore the problem space and possible solutions in the gaps of the original system to address the problem, threat or opportunity.
References
Works Cited
None.
Primary References
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.
INCOSE. 2023. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
INCOSE. 2022. INOSE Needs and Requirements Manual, version 1.1. INCOSE-TP-2021-002-01.
ISO/IEC/IEEE. 2023. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023.
Additional References
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.
ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes.
Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E). http://www.hitchins.net/ EmergenceEtc.pdf.
INCOSE. 2022. INOSE Guide to Needs and Requirements Manual, version 1. INCOSE-TP-2021-003-01
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007.
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight. (April 2010): 41-43.
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.