Difference between revisions of "Business and Mission Analysis"

Latest revision as of 21:59, 18 November 2023

Lead Author: Garry Roedler, Contributing Author: Rick Adcock

ConceptConcept Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and stakeholdersstakeholders are closely examined. The activities are grouped and described as generic processes which include Mission Analysis and Stakeholder Needs and Requirements. Concept Definition begins before any formal definition of the system-of-interestsystem-of-interest (SoI) is developed.

Mission AnalysisMission Analysis focuses on the needs and requirements of business or enterprise — that is, on defining the problem or opportunity that exists (in what is often called the problem space or problem situation), as well as understanding the constraints on and boundaries of the selected system when it is fielded (in what is often called the solution space). The Stakeholder Needs and RequirementsStakeholder Needs and Requirements process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. In these two Concept Definition activities, business or enterprise decision makers and other 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.

If a new or modified system is needed, then System DefinitionSystem Definition activities are performed to assess the system. See Life Cycle Processes and Enterprise Need for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in Concept Definition to the system and system element level of abstraction addressed in System Definition.

The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of life cycle modellife cycle 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 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: Mission AnalysisMission Analysis and the definition of Stakeholder Needs and RequirementsStakeholder Needs and Requirements:

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 assist business or enterprise decision makers to define the problem space, identify the stakeholders, develop preliminary operational concepts, and distinguish 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 encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business requirements.
The Stakeholder Needs and Requirements activity 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, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives.

Mission Analysis takes the business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives. Figure 1 in the Mission Analysis topic depicts this interaction. The products and artifacts produced during Concept Definition are then used in System DefinitionSystem Definition.

The different aspects of how systems thinkingsystems thinking is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of hard systemhard system and soft systemsoft system approaches depending on the type of problem or class of solution is discussed in Identifying and Understanding Problems and Opportunities and the contrast between top-down and bottom-up approaches in Synthesizing Possible Solutions.

Drivers of Solution on Problem Definition: Push Versus Pull

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 AnalysisSystem 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 life cycle 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 elementssystem 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.

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. 2015. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. 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:2015.

ISO/IEC/IEEE. 2011. 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

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.

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.

< Previous Article | Parent Article | Next Article > SEBoK v. 2.9, released 20 November 2023

@@ Line 1: / Line 1: @@
-Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)]] is developed. [[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. [[Stakeholder Needs and Requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.
+----
+'''''Lead Author:''''' ''Garry Roedler'', '''''Contributing Author:''''' ''Rick Adcock''
+----
+{{Term|Concept (glossary)|Concept}} Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and {{Term|Stakeholder (glossary)|stakeholders}} are closely examined. The activities are grouped and described as generic processes which include Mission Analysis and Stakeholder Needs and Requirements. Concept Definition begins before any formal definition of the {{Term|System-of-Interest  (glossary)|system-of-interest}} (SoI) is developed.
-Mission analysis examines ''why'' a solution is desired; what problem or opportunity it will address.  Stakeholder needs and requirements describe ''what'' a solution should accomplish.  Both ''why'' and ''what'' need to be answered before any consideration of ''how'' the problem will be addressed (i.e., what type of solution) and ''how'' the solution will be defined and developed.  If the chosen solution is a new or modified system, then [[System Definition]] activities are performed to define the system.
+{{Term|Mission Analysis (glossary)|Mission Analysis}} focuses on the needs and requirements of business or enterprise — that is, on defining the problem or opportunity that exists (in what is often called the problem space or problem situation), as well as understanding the constraints on and boundaries of the selected system when it is fielded (in what is often called the solution space).  The {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}} process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. In these two Concept Definition activities, business or enterprise decision makers and other 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.
-Various authors use different terms to describe these phases.  For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''
+If a new or modified system is needed, then {{Term|System Definition (glossary)|System Definition}} activities are performed to assess the system. See [[Life Cycle Processes and Enterprise Need]] for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in Concept Definition to the system and system element level of abstraction addressed in System Definition.
-To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].
+The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of {{Term|Life Cycle Model (glossary)|life cycle model}} being utilized.  See [[Applying Life Cycle Processes]] for further discussion of the concurrent, iterative and recursive nature of these relationships.
 ==Topics==
-The topics contained within this knowledge area include:
+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]]
+*[[Business or 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 as well as topics covered in Part 3.
 ==Concept Definition Activities==
-There are two primary activities discussed under concept definition:  [[Mission Analysis|mission analysis]] and the definition of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]:
+There are two primary activities discussed under concept definition: {{Term|Mission Analysis (glossary)|Mission Analysis}} and the definition of {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}}:
-*[[Mission Analysis]] initiates the life cycle of a potential [[System of Interest (SoI) (glossary)|system of interest (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.
-*[[Stakeholder Needs and Requirements]] works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of 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.
-The products and artifacts produced during concept definition are then used in [[System Definition]].
+# [[Business or Mission Analysis|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 assist business or enterprise decision makers to define the problem space, identify the stakeholders, develop preliminary operational concepts, and distinguish 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 encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business requirements.
+#The [[Stakeholder Needs and Requirements]] activity 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, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives.
-===Top-Down Approach: from Problem to Solution===
+Mission Analysis takes the business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives.  Figure 1 in the [[Business or Mission Analysis|Mission Analysis]] topic depicts this interaction.  The products and artifacts produced during Concept Definition are then used in {{Term|System Definition (glossary)|System Definition}}.
-In a top-down approach, [[Concept Definition|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 System-Of-Interest) is needed to fulfill the need.  The [[System Definition|system definition]] activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for [[System Realization|system realization]], [[System Deployment and Use|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]] and the definition of [[Stakeholder Needs and Requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements (glossary)]] that consist of the refinement and translation of the [[Stakeholder Requirement (glossary)|stakeholder requirements (glossary)]] into [[System Requirement (glossary)|system (technical) requirements]]. 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]] studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties).  For the concept definition, an appropriate architecture framework representation can be useful, such as DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.
+The different aspects of how {{Term|Systems Thinking (glossary)|systems thinking}} is applicable to concept definition are discussed in SEBoK Part 2.  In particular, the use of a combination of {{Term|Hard System (glossary)|hard system}} and {{Term|Soft System (glossary)|soft system}} approaches depending on the type of problem or class of solution is discussed in [[Identifying and Understanding Problems and Opportunities]]  and the contrast between top-down and bottom-up approaches in [[Synthesizing Possible Solutions]].
-===Bottom-Up Approach: Evolution of the Solution===
+==Drivers of Solution on Problem Definition: Push Versus Pull==
-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 evaaluated and 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 to adapt to a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. [[Reverse Engineering (glossary)|Reverse engineering (glossary)]] 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, please see [[System 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.  {{Term|System Analysis (glossary)|System Analysis}} activities are used to provide the link between problems and solutions.
-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.
+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 life cycle processes, such as in verification and validation, or alpha/beta testing as done in some commercial domains.
-===Separation and Iteration between Problem and Solution===
+As systems generally integrate existing and new {{Term|System Element (glossary)|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]].
-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 (glossary)]], 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.
-For more details about systems approaches, please see the [[Systems Approach Applied to Engineered Systems | Systems Approach Applied to Engineered Systems]] Knowledge Area.  In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and ''A 21st Century Systems Methodology'' (Hitchins 2007) are recommended.
 ==References==
 ===Works Cited===
-Kossiakoff, A, and W. Sweet.  2009.  ''Systems Engineering: Principles and Practice.''  Hoboken, NJ, USA: John Wiley and Sons.
+None.
-Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.''  Hoboken, NJ, USA: John Wiley & Sons.
+===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.
-Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight''  (April 2010): 41-43.
+INCOSE. 2015. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
-===Primary References===
+ISO/IEC/IEEE. 2015. ''[[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]]:2015.
-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. 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]].
-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.
+===Additional References===
+Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.
-ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.
-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).
+''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.
-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. 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.
-===Additional References===
+NASA. 2007. ''Systems Engineering Handbook''. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
-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.
 ----
-<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center>
+<center>[[Measurement|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Business or Mission Analysis|Next Article >]]</center>
-==Comments from SEBoK 0.5==
-This article is new to the SEBoK for version 0.75.  As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article.  Please see the discussion prompts below.
-{{DISQUS}}
+<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
 [[Category:Part 3]][[Category:Knowledge Area]]