Difference between revisions of "System Concept Definition"

Latest revision as of 22:36, 2 May 2024

Lead Author: Tami Katz Contributing Authors: Lou Wheatcraft, Mike Ryan, Garry Roedler, Rick Adcock

Concept DefinitionConcept 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 stakeholdersstakeholders are closely examined. Concept definition begins before any formal definition of the system-of-interestsystem-of-interest (SoI) is developed.

The Concept Definition activities include Business or Mission Analysis and Stakeholder Needs Definition. Within these two activities the enterprise or project 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 problemproblem will be addressed (i.e., what type of solution will be implemented) and how the solutionsolution will be defined and developed.

Concept Definition Activities

There are two primary activities discussed under Concept Definition: Business or Mission AnalysisBusiness or Mission Analysis and the definition of Stakeholder NeedsStakeholder Needs:

The Business or Mission Analysis activity defines the problem, threatthreat, or opportunityopportunity being addressed which could result in a new or modified product or service. 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 life cycle concepts.
The Stakeholder Needs Definition activity uses the inputs from the Business or Mission Analysis effort to identify an integrated set of needs based on inputs from the major stakeholders, higher-level requirements, and an analysis of the life cycle concepts, drivers, constraints, and risks.

The products and artifacts produced during Concept Definition are then used in the System DefinitionSystem Definition process.

Drivers of Concept Definition

There are many considerations associated with concept definition activities, which are further elaborated below.

The Role of Architecture Development

The activities of Business or Mission Analysis and Stakeholder Needs Definition occur concurrently with the processes of System Architecture Design Definition. The activities to address a full set of needs includes identification of SoI life cycle concepts, external interfaces and constraints, as well as candidate solutions and an exploration of the architecture (logicallogical and functionalfunctional).

Drivers of Solution on Problem Definition

During Concept Definition, the problem definition and solution exploration depend on each other: solutions should be developed to respond appropriately to well-defined problems; and problem definitions should be constrained by what is feasible in the solution space. System analysis is used to provide the links 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 capabilitycapability 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 life cycle processes, such as 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, the organization or customer has decided to start with a “blank piece of paper”. This is often referred to as a green-field system, and analysis efforts during concept definition characterize the as-is or present-state of the SoI in terms of the problem, threat, or opportunity and then characterize the to-be or future-state of the SoI in obtaining the resolution of the problem, threat, or opportunity.

An existing system can be evolved or transformed into the desired system. This is often 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 existing system may have been developed for other purposes, the stakeholder needs or the operational environment may have changed, e.g., a change in threats. The analysis effort will explore the problem space and possible solutions to the gaps of the existing system to address the problem, threat or opportunity.

References

Works Cited

None.

Primary References

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. INCOSE 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.

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. 2016. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2016-6105 rev 2.

< Previous Article | Parent Article | Next Article > SEBoK v. 2.10, released 06 May 2024

@@ Line 1: / Line 1: @@
-<html>
+----'''''Lead Author:''''' ''Tami Katz'' '''''Contributing Authors:''''' ''Lou Wheatcraft, Mike Ryan, Garry Roedler, Rick Adcock''
-<meta name="citation_title" content="Concept Definition">
+----'''{{Term|Concept Definition (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.
-<meta name="citation_author" content="Pyster, Art">
-<meta name="citation_author" content="Olwell, David H.">
-<meta name="citation_author" content="Hutchison, Nicole">
-<meta name="citation_author" content="Enck, Stephanie">
-<meta name="citation_author" content="Anthony, James F., Jr.">
-<meta name="citation_author" content="Henry, Devanandham">
-<meta name="citation_author" content="Squires, Alice (eds)">
-<meta name="citation_publication_date" content="2012/11/30">
-<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)">
-<meta name="citation_volume" content="version 1.0.1">
-<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html>
-[[Concept Definition (glossary)]] is the set of systems engineering (SE) activities in which the problem space and the needs of [[Stakeholder (glossary)|stakeholders]] are closely examined. This begins before any formal definition of the [[System-of-Interest  (glossary)|system-of-interest]] (SoI) is developed. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Model (glossary)]].
-[[Mission Analysis (glossary)|Mission analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. It examines why a solution is desired and what problem or opportunity it will address.  [[Stakeholder Requirement (glossary)|Stakeholder needs and requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. It describes ''what'' a solution should accomplish.  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) and ''how'' the solution will be defined and developed.
+The Concept Definition activities include [[Business or Mission Analysis]] and [[Stakeholder Needs Definition]]. Within these two activities the enterprise or project 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 {{term|Problem (glossary)|problem}} will be addressed (i.e., what type of solution will be implemented) and ''how'' the {{term|Solution (glossary)|solution}} will be defined and developed.
-If a new or modified system is needed then [[System Definition (glossary)]] activities are performed to define the system. The specific activities and sequence of concept activities and how they fit into the life cycle activities of any system solutions, will be dependent upon the type of life cycle model being utilized.
-Various authors use different terms to describe these phases.  For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''
-==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 KA contains the following topics:
-*[[Mission Analysis]]
-*[[Stakeholder Needs and Requirements]]
-See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
 ==Concept Definition Activities==
-There are two primary activities discussed under concept definition: [[Mission Analysis (glossary)|mission analysis]] and the definition of [[Stakeholder Requirements (glossary)|stakeholder needs and requirements]]:
+There are two primary activities discussed under Concept Definition: {{Term|Mission Analysis (glossary)|Business or Mission Analysis}} and the definition of {{term|Stakeholder Needs and Requirements (glossary)|Stakeholder Needs}}:
-#[[Mission Analysis]] begins an iteration of the life cycle of a potential SoI that could solve a problem or realize an opportunity for developing a new product, service, or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space. In other words, mission analysis takes the enterprise capability gap or opportunity and defines the problem/opportunity in a manner that provides a common understanding.
-#[[Stakeholder Needs and Requirements]] works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, called "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identifies and defines the needs and requirements of the stakeholders in a manner that enables characterizing the solution alternatives.
-Mission analysis takes the stakeholder's needs and requirements and carries the analysis down from problem space to solution space, including concept, requirement (stakeholder/mission) and boundary or context so that a solution concept (black box level) can be selected from the alternatives.  Figure 1 in the [[Mission Analysis|mission analysis]] topic depicts this interaction.  The products and artifacts produced during concept definition are then used in [[System Definition (glossary)|system definition]].
+#The [[Business or Mission Analysis]] activity defines the problem, {{term|Threat (glossary)|threat}}, or {{term|Opportunity (glossary)|opportunity}} being addressed which could result in a new or modified product or service.  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 life cycle concepts.
+#The [[Stakeholder Needs Definition]] activity uses the inputs from the Business or Mission Analysis effort to identify an integrated set of needs based on inputs from the major stakeholders, higher-level requirements, and an analysis of the life cycle 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.
-The different aspects of [[Systems Thinking (glossary)]] applicable to concept definition are discussed in SEBoK Part 2.  In particular the use of a combination of [[Hard System (glossary)]] and [[Soft System (glossary)]] approaches depending on the type of problem or class of solution is discussed in the [[Identifying and Understanding Problems and Opportunities]] article.
+==Drivers of Concept Definition==
+There are many considerations associated with concept definition activities, which are further elaborated below.
-===Top-Down Approach: from Problem to Solution===
+=== The Role of Architecture Development ===
-In a top-down approach, concept definition activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the SoI) is needed to fulfill the need.  The [[System Definition (glossary)|system definition]] activities use the outcomes of concept definition and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions.
+The activities of [[Business or Mission Analysis]] and [[Stakeholder Needs Definition]] occur concurrently with the processes of [[System Architecture Design Definition]].   The activities to address a full set of needs includes identification of SoI life cycle concepts, external interfaces and constraints, as well as candidate solutions and an exploration of the architecture ({{term|Logical Architecture (glossary)|logical}} and {{term|Functional Architecture (glossary)|functional}}).
-Outcomes of system definition are used for [[System Realization (glossary)|system realization]], [[System Deployment and Use (glossary)|system deployment and use]], and [[Product and Service Life Management|product and service life management]]. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of [[Mission Analysis (glossary)|mission analysis]] and the definition of [[Stakeholder Requirements (glossary)|stakeholder needs and requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements]].
+=== Drivers of Solution on Problem Definition ===
+During Concept Definition, the problem definition and solution exploration depend on each other: solutions should be developed to respond appropriately to well-defined problems; and problem definitions should be constrained by what is feasible in the solution space. System analysis is used to provide the links between problems and solutions.
-These system requirements are then used as inputs for the [[Architectural Design: Logical|logical architecture design]], which includes functional, behavioral, temporal, and physical architectural aspects. [[System Analysis (glossary)|System analysis]] studies are performed to evaluate and select the  most suitable potential system elements. System analysis is intended to provide a best-value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties).
+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 {{term|Capability (glossary)|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 life cycle processes, such as verification and validation, or alpha/beta testing as done in some commercial domains.
-For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These include the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B within the concept definition when performing mission analysis and evaluating stakeholder needs and requirements.
+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]].
-===Bottom-Up Approach: Evolution of the Solution===
+=== 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.
-In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaluated. Engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle for a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions.
+For a new system, the organization or customer has decided to start with a “blank piece of paper”.  This is often referred to as a green-field system, and analysis efforts during concept definition characterize the as-is or present-state of the SoI in terms of the problem, threat, or opportunity and then characterize the to-be or future-state of the SoI in obtaining the resolution of the problem, threat, or opportunity.
-[[Reverse Engineering (glossary)|Reverse engineering]] is often necessary to enable system engineers to (re)characterize the properties of the system-of-interest (SoI) or its elements. This is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, see the [[System Definition]] article.)
-A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[architecture (glossary)|architecture (glossary)]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.
-Bottom-up and top-down approaches can be, and often are, mixed.
-===Drivers of Solutions: Push versus Pull===
-There are two paradigms that drive the concept definition - ''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 a product or service anticipated to be wanted by or attractive to some portion of the population (i.e. whether a current market exists or not).  This can have an effect on other lifecycle processes, as in verification and validation as it is performed in defense industries versus alpha/beta testing done in some commercial domains.
-===Separation and Iteration between Problem and Solution===
-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|System analysis]] activities are used to perform the link between problems and solutions.
-As systems generally integrate existing and new [[System Element (glossary)|system elements]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems.
+An existing system can be evolved or transformed into the desired system.  This is often 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 existing system may have been developed for other purposes, the stakeholder needs or the operational environment may have changed, e.g., a change in threats. The analysis effort will explore the problem space and possible solutions to the gaps of the existing system to address the problem, threat or opportunity.
 ==References==
-===Works Cited===
+===Works Cited ===
-DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.
+None.
-Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.''  Hoboken, NJ, USA: John Wiley & Sons.
-Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight''  (April 2010): 41-43.
-Kossiakoff, A, and W. Sweet.  2009.  ''Systems Engineering: Principles and Practice.''  Hoboken, NJ, USA: John Wiley and Sons.
-The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
-Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
 ===Primary References===
-ANSI/EIA. 1998. ''[[ANSI/EIA 632|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. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
+INCOSE. 2022. ''INCOSE Needs and Requirements Manual'', version 1.1. INCOSE-TP-2021-002-01.
-ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).
+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. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].
 ===Additional References===
-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 Electronical Commission (IEC), ISO/IEC 19760:2003 (E).
+Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology''. Hoboken, NJ, USA: John Wiley & Sons.
-ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.
+ISO/IEC. 2003. ''Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes''.
-Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight''  (April 2010): 41-43.
+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.
-NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
+Jackson, S., D. Hitchins, and H. Eisner. 2010. ''"What is the Systems Approach?" INCOSE Insight''. (April 2010): 41-43.
-Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.''  Hoboken, NJ, USA: John Wiley & Sons.
-Hitchins, D. 2008. http://www.hitchins.net/EmergenceEtc.pdf.).
+NASA. 2016. ''Systems Engineering Handbook''. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2016-6105 rev 2.
-----
-<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center>
-{{DISQUS}}
+----
+<center>[[Measurement|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Business or Mission Analysis|Next Article >]]</center>
+<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
-[[Category:Part 3]][[Category:Knowledge Area]]
+[[Category:Part 3]]
+[[Category:Knowledge Area]]