Difference between revisions of "Business or Mission Analysis"

From SEBoK
Jump to navigation Jump to search
(RWG updates - draft)
Tag: visualeditor
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(41 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
----
 
----
−
'''''Lead Authors:''''' ''Tami Katz'' '''''Contributing Authors:''''' ''Lou Wheatcraft''
+
'''''Lead Author:''''' ''Tami Katz'' '''''Contributing Authors:''''' ''Lou Wheatcraft, Mike Ryan''
 
----
 
----
−
The starting point of engineering any {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) is understanding the organizational objectives behind the development of the SoI, which is the objective of the {{Term|Concept Definition (glossary)}} set of activities.   
+
The primary start to the engineering of any {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) is to obtain an understanding the objectives behind the development of the SoI, which is performed as part of the {{term|Concept Definition (glossary)|Concept Definition}} process.   
  
−
The first concept definition activity is the Business or Mission Analysis, which defines the problem, threat, or opportunity, as well as the mission, goals, objectives, and measures that will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. This effort is typically performed by the organization’s strategic and business operations levels and focuses on the identification of the primary purpose(s) of the SoI (its "mission").  The second concept definition activity is called [[Stakeholder Needs and Requirements]] definition, which explores what capabilities are needed to accomplish the mission. 
+
''Business or Mission Analysis'', the first process performed in Concept Definition, establishes a definition of the overall strategic problem or opportunity and identification of potential solution classes to address the problem (or take advantage of an opportunity) (ISO/IEC/IEEE 15288).  The solution could be a new system, a change to an existing system, a service, an operational change or some other solution.  
  
−
Business or Mission Analysis is often performed iteratively with the [[Stakeholder Needs and Requirements]] definition activity to better understand the problem (or opportunity) space, as well as options of solution space.  
+
This analysis effort identifies the primary purpose(s) of the SoI (its "{{term|Mission (glossary)|mission}}").  The second Concept Definition process is called [[Stakeholder Needs Definition]], which explores what {{term|Capability (glossary)|capabilities}} are needed to accomplish the mission or the intended use of the system. 
 +
 
 +
Business or Mission Analysis is often performed iteratively with the [[Stakeholder Needs Definition]] process to better understand the {{term|Problem (glossary)|problem}} space, as well as options in the {{term|Solution (glossary)|solution}} space.  
  
 
== Purpose and Definition ==
 
== Purpose and Definition ==
−
The purpose of Business or Mission Analysis is to understand a mission or market problem, threat or opportunity, establish the objectives and measures of success of a potential solution that could address the problem or take advantage of an opportunity. This analysis is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.  This effort is done prior to project formation to define the problem space as input to the project team's efforts.
+
The purpose of Business or Mission Analysis is to understand a mission or market problem, {{term|Threat (glossary)|threat}}, or {{term|Opportunity (glossary)|opportunity}}, and to establish the goals, objectives and measures of success of a potential solution class. This consists of a strategic analysis related to emerging needs, capability gaps, threats, opportunities, and potential solutions by a project team or by an organization to obtain its business objectives prior to establishing a project team.
  
 
==Principles and Concepts==
 
==Principles and Concepts==
−
For the SoI under development, success depends on the project team's understanding the data that constitutes the purpose of the SoI (why?), acceptability or desirability of a solution (what?), measures (how well?), and the conditions in which the SOI must operate (in what operating environment?)
+
For the SoI under development, success depends on the project team's understanding the data and information that constitutes the purpose of the SoI (''why?''), acceptability or desirability of a solution (''what?''), measures (''how well?''), and the conditions in which the SOI must operate (''in what operating environment?'')
  
−
Prior to project formulation, a project champion and business analyst work with key stakeholders at the organization’s strategic and business operations levels to clearly define the problem or opportunity for which the project team is to address.  Identifying the specific problem or opportunity will enable the project team to understand why the project is worth doing, the system is needed, and the capabilities, functions, performance, and features that are important to the customers, users, and operators of the system. The next step is to identify the mission, goals and objectives (MGOs) based on the defined problem, threat or opportunity, as well as the measures of success.  
+
Prior to SoI development, a project champion works with key stakeholders to clearly define the problem, threat, or opportunity for which the project team is to address.  Identifying the specific problem, threat, or opportunity will enable the project team to understand if the project is worth doing, why the system is needed, and the expected capabilities of the SoI. The next step is to identify the mission, goals, and objectives (MGOs) based on the defined problem, threat or opportunity, as well as the measures of success.  
  
−
* The ''Mission'' statement is based on the analysis of a problem, threat, or opportunity that the project was formed to address and defines the “why” - why does the project exist?  
+
* The ''Mission'' statement is based on the analysis of a problem, threat, or opportunity that the project was formed to address, the expected outcome of the SoI being developed, and defines the “why”. Why does the project exist?  Why is the SoI needed? What value does it bring to the organization?
−
* ''Goals'' are upper-level needs that form the second level of the hierarchy of the integrated set of needs. Goals are elaborated from the mission statement communicating those things that need to be achieved that will result in achieving the mission. Goals allow the organization to divide the mission statement into manageable pieces and promote a shared understanding between the project team and the organization’s strategic and business operations level stakeholders or customers of what will be done to achieve the mission.
+
* ''Goals'' are elaborated from the mission statement to communicate what must be achieved to result in a successful mission. Goals allow the organization to divide the mission statement into manageable pieces and promote a shared understanding between the project team and the business operations level stakeholders of what needs to be done to achieve the mission.
−
* ''Objectives'' are upper-level needs that form the third level of the hierarchy of the integrated set of needs.  Objectives are elaborated from the goals providing more details concerning what must be done to meet the goals that will result in the mission to be achieved i.e., what the project team and the system to be developed need to achieve so the system can fulfill its intended purpose (mission) in its operational environment when operated by its intended users.  
+
* ''Objectives'' are elaborated from the goals to provide more details concerning what must be done that will result in the goals and mission to be achieved. What does the project team need to do to achieve the goals? What does the SoI need to do to achieve the goals?
 +
* ''Measures'' are quantitative metrics used to validate the SoI against the objectives as well as to manage system development across the life cycle, expressed as {{term|Measure of Effectiveness (MoE) (glossary)|Measures of Effectiveness (MOE)}} (reference [[Measurement]]).
  
−
Once the identification of the problem, threats, opportunities, MGOs and measures are done an evaluation of whether to proceed with the SoI is performed at the enterprise level based on analysis of organization objectives.  Upon agreement to proceed with further concept development, the data from the Business and Mission Analysis is provided to the project team to complete the rest of the process (Figure 1).
+
As part of the Business or Mission Analysis effort, an initial assessment by key stakeholders of the SoI {{term|Life Cycle (glossary)|life cycle}} concepts is used to support identification of candidate solution classes. The organization then performs an evaluation of whether to proceed with development of the SoI based on analysis of the data and alignment with the organization's enterprise strategy.  Upon agreement to proceed, the data from the Business and Mission Analysis effort is used by the project team to complete the rest of the concept development process for the SoI, as shown in Figure 1.
  
−
'''Figure 1 here:'''
+
[[File:Figure BusMissAnl-1 SEBoK Original.jpg|thumb|900px|center|'''Figure 1. Business or Mission Analysis addresses the effort to generate project success, which is provided to the project team for further concept definition activities.''' (SEBoK Original)]]
  
−
Define the Problem, Threat, or Opportunity -> Define the Mission, Goals, Objectives (MGOs) and Measures -> project formation
+
There are several outputs of the Business or Mission Analysis process:
  
−
Figure 1. Business or Mission Analysis addresses the effort to generate project success, which is provided to the project team for further concept definition activities. Original SEBoK figure.
+
* identification of major stakeholders,
 +
* definition of the problem, threat, or opportunity to which the project must address,
 +
* elaboration of the MGOs and measures of success,
 +
* identification of preliminary life cycle concepts and the preferred solution classes,
 +
* traceability of strategic problems, threats, opportunities, MGOs, and measures of success to the preferred solution classes, and
 +
* confirmation of organizational support.
  
−
In many cases the identification of the problem, threats, opportunities, MGOs and measures are done at a business enterprise or operations levels, where the initial assessment results in the authorization for a project and associated budget along with an acquisition concept. For the project team responsible for developing the SoI, this means seeking an understanding of this content to ensure the outcomes of the project align with the organizations overall strategy behind developing that particular project.
+
The effort of Business or Mission Analysis is often done at a business enterprise level, where the initial assessment results in the authorization for a project and associated budget along with an acquisition concept. For the project team responsible for developing the SoI, this means seeking an understanding of this content to ensure the outcomes of the project align with the organization's overall strategy and rationale for developing that particular SoI.
  
−
Once the project has been formed the output from the Business or Mission Analysis is then provided to the project organization for use in additional analysis that establishes the overall set of needs (described in [[Stakeholder Needs and Requirements]] definition).
+
The output from the Business or Mission Analysis is then provided to the project team for use in additional analysis that establishes an overall set of {{term|Stakeholder Needs and Requirements (glossary)|needs}} for the solution (described in [[Stakeholder Needs Definition]]).
  
 
==Process Approach==
 
==Process Approach==
−
'''Define the Problem, Threat or Opportunity'''
 
  
−
Identifying the specific problem or opportunity will enable the project team to understand why the project is worth doing, the system is needed, and the capabilities, functions, performance, and features that are important to the customers, users, and operators of the system. The steps to defining the problem or opportunity include:
+
=== '''Identify Major Stakeholders''' ===
 +
During this process the initial stakeholder identification is performed.  This can be captured in a stakeholder register, noting each stakeholder and their involvement with the SoI and project, as well as establishment a ranking of the stakeholders.  This list is expanded upon during [[Stakeholder Needs]] Definition.  At this phase, the stakeholders will often include key members from the organization at the enterprise level.
 +
 
 +
=== '''Define the Problem, Threat, or Opportunity''' ===
 +
Identifying the specific problem, threat or opportunity will enable the project team to understand why the system is needed, and which capabilities, functions, performance, and features that are important to the customers, users, operators, maintainers, and disposers of the system.  
 +
 
 +
There are four steps to defining the problem, threat, or opportunity:
  
−
1.     Identify the organization’s strategic and business operations level stakeholders that are impacted by the problem or threat or those who will benefit by pursuing the opportunity.
+
1.    Identification of the organization’s strategic and business operations level stakeholders that are impacted by the problem or threat or those who will benefit by pursuing the opportunity.
  
−
2.     Work with of these stakeholders to understand how they are impacted by the problem or threat or those that will benefit by pursuing the opportunity.
+
2.    Collaboration with these stakeholders to understand how they are impacted by the problem or threat, or by those that will benefit by pursuing the opportunity.
  
−
3.     Clearly define a statement of the problem, threat, or opportunity.
+
3.    Clear definition of the problem, threat, or opportunity.
  
−
4.     Get stakeholder agreement for the problem, threat, or opportunity statement.
+
4.    Stakeholder concurrence with the problem, threat, or opportunity statement.
  
−
<u>'''Define the Mission, Goals, Objectives and Measures'''</u>
+
Example Problem/Threat/Opportunity statement: Marketing is seeing an increase of work from home personnel that are purchasing more coffee makers.  Existing coffee makers have single functions while consumers want a multi-function hot beverage maker to produce a blend of options like traditional brew or espresso.  There is a huge opportunity if first to market. (INCOSE GtNR 2022)
  
−
To obtain the MGOs and measures, the project champion and business analyst collaborates with the stakeholders that participated in defining the problem or opportunity to better understand what they would view as an acceptable outcome by asking:
+
=== '''Define the Mission, Goals, Objectives and Measures''' ===
 +
To achieve the MGOs and measures, the project champion collaborates with the stakeholders that participated in defining the problem, threat, or opportunity to better understand what they view as an acceptable outcome by asking them a series of questions:
  
 
* How do they define success?
 
* How do they define success?
−
* What measures would the stakeholders use to define success?
+
* What measures would the stakeholders use to determine success?
−
* What is the intended use of the SoI in what operating environment?
+
* What is the intended use of the SoI and in what operating environment?
 
* What capabilities, features, functions, and performance do they need?
 
* What capabilities, features, functions, and performance do they need?
−
* What are their expectations for quality and compliance (with standards and regulations)?
+
* What are their expectations for quality and compliance (such as with standards and regulations)?
 
* What specific outcome(s) do they expect once the SoI is delivered?
 
* What specific outcome(s) do they expect once the SoI is delivered?
 +
* What are the measures of success, e.g., measures of effectiveness (MOE), expected of the SoI?
  
−
For cases where there is no existing SOI (also known as a “green field” project), a common approach is to 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, neutralizing the threat, or the ability to pursue the opportunity.
+
For cases where there is no existing SoI, a common approach is to characterize the “as is” or “present state” in terms of the problem, threat, or opportunity and then characterize the “to be” or “future state” in terms of the resolution of the problem, neutralizing the threat, or the ability to pursue the opportunity.
−
 
 
−
For existing systems that need to be updated (also known as a “brown field” project), a common approach is to list the problems or issues with the existing “as-is” system and the reasons the SOI needs to be changed.  Key information includes what they think needs to be changed and why, and what value will result from the change.  What can the existing SOI no longer do, what performance needs to be improved, what changes need to be made concerning interactions with external systems, what updates are needed as a result of changes to applicable standards and regulations.
 
−
 
 
−
It is also important to understand different perspectives.  The problem/threat/opportunity, MGOs, and measures from a business perspective (developing organization or customer organization) may be different than the consumer’s perspective, thus both must be addressed.  The consumer does not care about the developing organizations profits, time to market, market share, etc.   The consumer cares about how the resulting product meets their needs.  Thus, there will be several sets of problem/threat/opportunity, MGOs, and measures that need to be defined and met by the project team from both a business perspective and a consumer perspective of the product to be developed.  This may lead to conflicts, e.g., product price vs. profitability and market share.
 
−
 
 
−
Example (from INCOSE Guide to Needs and Requirements):
 
−
 
 
−
'''Problem/Threat/Opportunity:''' Marketing is seeing an increase of stay-at-home workers, purchasing more coffee makers.  Existing coffee makes have single functions while consumers want a multi-function hot beverage maker to get a blend of options like traditional brew or espresso.  There is a huge opportunity if first to market.
 
−
 
 
−
'''Mission Statement: ''' Provide a home-based, one-stop, hot beverage facility.
 
−
 
 
−
'''Consumer Goals:'''
 
−
 
 
−
CG1) Obtain home brew coffee quickly
 
−
 
 
−
CG2) Obtain consistent output of brewed coffee
 
−
 
 
−
CG3) Eliminate the need for multiple appliances by including additional features such a variety of hot beverages (traditional brew, espresso, and teas)
 
−
 
 
−
CG4) Easy to use and maintain
 
−
 
 
−
CG5) Highly reliable and long lasting
 
−
 
 
−
'''Business Goals:'''
 
−
 
 
−
BG1) Reduce time to market
 
−
 
 
−
BG2) Increase profitability
 
−
 
 
−
BG3) Increase market share
 
−
 
 
−
'''Business Objectives:'''
 
  
−
O1) Stock store shelves within one year
+
For existing systems that need to be updated, a common approach is to list the problems or issues with the existing “as-is” system and the reasons it needs to be changed.  Key information includes what value they believe will result from the change by addressing: What can the existing SoI no longer do, what performance needs to be improved, what changes need to be made concerning interactions with external systems, what updates are needed as a result of changes to applicable standards and regulations, what updates are needed as a result of changes in the operational environment or new threats (e.g., security)?
  
−
O2) Generate coffee and espresso (including steamer/frothier)
+
It is also important to understand different perspectives.  The problem, threat, or opportunity, MGOs, and measures from a business perspective may be different than the user’s perspective, both must be addressed.  The user does not necessarily care about the developing organization's profits, time to market, market share, etc., they care about how the resulting SoI meets their needs.  Thus, there could be several sets of MGOs and measures that need to be defined and met by the project team from both a business perspective and a user perspective of the SoI to be developed.  This may lead to conflicts, e.g., product price vs. profitability vs. market share, which need to be prioritized based on the organizational enterprise strategy. 
  
−
O3) Maximize reusability of existing company assets
+
Examples (derived from INCOSE GtNR 2022):
  
−
O4) Increase market share of Company X sales regions
+
* Mission statement: Increase revenue by providing a home-based, one-stop, multi-function hot beverage maker.
 +
* Consumer Goals: Product a blend of options. Obtain home brew beverage quickly.
 +
* Consumer Objective: Options of brew or expresso. Receive finished home brew coffee within minutes upon request.
 +
* Consumer-focused Measure: Finished home brew provided within 2 minutes of activation at the selected temperature. Rationale: Consumer survey results.
 +
* Business Goals: Increase revenue. Increase market share.
 +
* Business Objective: Increase market share of Company X sales regions.
 +
* Business-focused Measure: Improve current market share of Company X sales regions by 20%. Rationale: Aligns with the enterprise strategic vision.
  
−
'''Consumer-focused Measures:'''
+
=== '''Capture Preliminary Life Cycle Concepts''' ===
 +
Life cycle concepts, such as the {{term|Operational Concept (glossary)|operational concept}}, define what the SoI needs to do and how well during its intended use in the expected operational environment, from multiple perspectives.  This includes various use cases with expected interactions with external systems, identification of drivers and constraints, expected risks to success in the context of the MGOs and measures.
  
−
M1) 99% accuracy within temperature based on user temperature option selected
+
Preliminary life cycle concepts are defined by the organization and include preliminary concepts for acquisition, development, manufacturing or coding, verification, validation, deployment, operations, support, and retirement. Operational concepts include high level operational modes or states, operational scenarios, potential use cases, misuse cases, loss scenarios, or usage within a proposed business strategy. These concepts enable feasibility analysis and evaluation of solution options. For example, concerning acquisition and development how much of the development effort will be done inhouse or outsourced to a supplier? Who will be the overall integrator? If development is done in house, what are the concepts for the supply chain for parts and components?
  
−
M2) 99% accuracy within duration based on type of beverage selected
+
In a {{term|Model-Based Systems Engineering (MBSE) (glossary)|Model-Based Systems Engineering}} effort, these life cycle concepts are generated using mission analysis, such as defining use cases associated with users and life cycle stage (Figure 2). Reference [[Model-Based Systems Engineering (MBSE)]] for more information regarding usage of MBSE.[[File:Figure BusMissAnl-3 SEBoK Original.jpg|thumb|900px|center|'''Figure 2. Example Life Cycle Concepts Using MBSE Approaches.''' (SEBoK Original)]]
  
−
M3) 10-year service life
+
The life cycle concepts will be further refined within the stakeholder needs definition process.  As part of the preliminary life cycle concepts, candidate solution classes are suggested for a possible range of approaches to address the MGOs, as part of a [[Functional Architecture]] definition activity.
  
−
'''Business-focused Measures:'''
+
=== '''Identify Uncertainties and Risks''' ===
 +
The preliminary life cycle concepts include some level of uncertainty.  This leads to risks which need to be identified and managed using the [[Risk Management]] process.  These risks may also serve as inputs to the generation of additional life cycle concepts (such as addressing cyber security or hazards to successful operation). 
  
−
M4) 40% per unit profit
+
=== '''Identify Preliminary Concepts of the Solution Space, Including Alternatives''' ===
 +
A solution class refers to the means of achieving a solution. Examples include development of a new system, modifying or upgrading an existing system, leveraging multiple existing systems, or generating operational changes.
  
−
M5) Greater than 50% market share of Company X sales regions
+
Possible solution classes to address the problem, threat, or opportunity are assessed against the preliminary life cycle concepts, MGOs and measures. Feasibility of a solution class and its capability to meet the strategic needs are key decision criteria, as well as feasibility considerations in terms of cost, schedule, technology, legal, ethical, environmental, sustainability, etc. The [[Decision Management]] process is used to evaluate alternatives and to guide selection. The assessment of alternatives can include modeling, simulation, analytical techniques, or expert judgment to understand the risks, feasibility, and value of the alternative solution classes.
  
 +
The conclusion of this effort results in the identification of preliminary concepts of the solution space, including alternatives, which are traceable to the organization defined problems/threats/opportunities and MGOs/measures.
  
−
==Practical Considerations==
+
=== '''Assessment of Continuation of Effort''' ===
−
pending 
+
Upon the conclusion of the Business or Mission Analysis process the organization performs an evaluation on whether to commence with development of the SoI.  The key determination is alignment with the enterprise strategy.  If the effort is to be continued, a project team will take the outcomes of the Business or Mission Analysis effort and commence with the [[Stakeholder Needs Definition]] activity.
−
 
 
 
==References==  
 
==References==  
  
 
===Works Cited===
 
===Works Cited===
−
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 Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023.
 +
 
 +
INCOSE. 2022. ''INCOSE Needs and Requirements Manual (NRM)'', version 1.1. INCOSE-TP-2021-002-01.
  
−
INCOSE. 2022. INOSE Guide to Needs and Requirements Manual, version 1. INCOSE-TP-2021-003-01
+
INCOSE. 2022. ''INCOSE Guide to Needs and Requirements (GtNR)'', version 1. INCOSE-TP-2021-003-01
  
 
===Primary References===
 
===Primary References===
 
ISO/IEC/IEEE. 2023. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023.
 
ISO/IEC/IEEE. 2023. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023.
  
−
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. ''INCOSE Needs and Requirements Manual (NRM)'', version 1.1. INCOSE-TP-2021-002-01.
 +
 
 +
INCOSE. 2022. ''INCOSE Guide to Needs and Requirements (GtNR)'', version 1. INCOSE-TP-2021-003-01
  
 
===Additional References===
 
===Additional References===
 
None.  
 
None.  
 
----
 
----
−
<center>[[Business and Mission Analysis|< Previous Article]] | [[Business and Mission Analysis|Parent Article]] | [[Stakeholder Needs Definition|Next Article >]]</center>
+
<center>[[System Concept Definition|< Previous Article]] | [[System Concept Definition|Parent Article]] | [[Stakeholder Needs Definition|Next Article >]]</center>
  
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
−
[[Category:Concept Definition]]
+
[[Category:System Concept Definition]]
−
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
+
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>

Latest revision as of 22:52, 2 May 2024

Lead Author: Tami Katz Contributing Authors: Lou Wheatcraft, Mike Ryan

The primary start to the engineering of any system-of-interestsystem-of-interest (SoI) is to obtain an understanding the objectives behind the development of the SoI, which is performed as part of the Concept DefinitionConcept Definition process.

Business or Mission Analysis, the first process performed in Concept Definition, establishes a definition of the overall strategic problem or opportunity and identification of potential solution classes to address the problem (or take advantage of an opportunity) (ISO/IEC/IEEE 15288). The solution could be a new system, a change to an existing system, a service, an operational change or some other solution.

This analysis effort identifies the primary purpose(s) of the SoI (its "missionmission"). The second Concept Definition process is called Stakeholder Needs Definition, which explores what capabilitiescapabilities are needed to accomplish the mission or the intended use of the system.

Business or Mission Analysis is often performed iteratively with the Stakeholder Needs Definition process to better understand the problemproblem space, as well as options in the solutionsolution space.

Purpose and Definition

The purpose of Business or Mission Analysis is to understand a mission or market problem, threatthreat, or opportunityopportunity, and to establish the goals, objectives and measures of success of a potential solution class. This consists of a strategic analysis related to emerging needs, capability gaps, threats, opportunities, and potential solutions by a project team or by an organization to obtain its business objectives prior to establishing a project team.

Principles and Concepts

For the SoI under development, success depends on the project team's understanding the data and information that constitutes the purpose of the SoI (why?), acceptability or desirability of a solution (what?), measures (how well?), and the conditions in which the SOI must operate (in what operating environment?)

Prior to SoI development, a project champion works with key stakeholders to clearly define the problem, threat, or opportunity for which the project team is to address.  Identifying the specific problem, threat, or opportunity will enable the project team to understand if the project is worth doing, why the system is needed, and the expected capabilities of the SoI. The next step is to identify the mission, goals, and objectives (MGOs) based on the defined problem, threat or opportunity, as well as the measures of success.

  • The Mission statement is based on the analysis of a problem, threat, or opportunity that the project was formed to address, the expected outcome of the SoI being developed, and defines the “why”. Why does the project exist?  Why is the SoI needed? What value does it bring to the organization?
  • Goals are elaborated from the mission statement to communicate what must be achieved to result in a successful mission. Goals allow the organization to divide the mission statement into manageable pieces and promote a shared understanding between the project team and the business operations level stakeholders of what needs to be done to achieve the mission.
  • Objectives are elaborated from the goals to provide more details concerning what must be done that will result in the goals and mission to be achieved. What does the project team need to do to achieve the goals? What does the SoI need to do to achieve the goals?
  • Measures are quantitative metrics used to validate the SoI against the objectives as well as to manage system development across the life cycle, expressed as Measures of Effectiveness (MOE)Measures of Effectiveness (MOE) (reference Measurement).

As part of the Business or Mission Analysis effort, an initial assessment by key stakeholders of the SoI life cyclelife cycle concepts is used to support identification of candidate solution classes. The organization then performs an evaluation of whether to proceed with development of the SoI based on analysis of the data and alignment with the organization's enterprise strategy. Upon agreement to proceed, the data from the Business and Mission Analysis effort is used by the project team to complete the rest of the concept development process for the SoI, as shown in Figure 1.

Error creating thumbnail: File missing
Figure 1. Business or Mission Analysis addresses the effort to generate project success, which is provided to the project team for further concept definition activities. (SEBoK Original)

There are several outputs of the Business or Mission Analysis process:

  • identification of major stakeholders,
  • definition of the problem, threat, or opportunity to which the project must address,
  • elaboration of the MGOs and measures of success,
  • identification of preliminary life cycle concepts and the preferred solution classes,
  • traceability of strategic problems, threats, opportunities, MGOs, and measures of success to the preferred solution classes, and
  • confirmation of organizational support.

The effort of Business or Mission Analysis is often done at a business enterprise level, where the initial assessment results in the authorization for a project and associated budget along with an acquisition concept. For the project team responsible for developing the SoI, this means seeking an understanding of this content to ensure the outcomes of the project align with the organization's overall strategy and rationale for developing that particular SoI.

The output from the Business or Mission Analysis is then provided to the project team for use in additional analysis that establishes an overall set of needsneeds for the solution (described in Stakeholder Needs Definition).

Process Approach

Identify Major Stakeholders

During this process the initial stakeholder identification is performed. This can be captured in a stakeholder register, noting each stakeholder and their involvement with the SoI and project, as well as establishment a ranking of the stakeholders. This list is expanded upon during Stakeholder Needs Definition. At this phase, the stakeholders will often include key members from the organization at the enterprise level.

Define the Problem, Threat, or Opportunity

Identifying the specific problem, threat or opportunity will enable the project team to understand why the system is needed, and which capabilities, functions, performance, and features that are important to the customers, users, operators, maintainers, and disposers of the system.

There are four steps to defining the problem, threat, or opportunity:

1.    Identification of the organization’s strategic and business operations level stakeholders that are impacted by the problem or threat or those who will benefit by pursuing the opportunity.

2.    Collaboration with these stakeholders to understand how they are impacted by the problem or threat, or by those that will benefit by pursuing the opportunity.

3.    Clear definition of the problem, threat, or opportunity.

4.    Stakeholder concurrence with the problem, threat, or opportunity statement.

Example Problem/Threat/Opportunity statement: Marketing is seeing an increase of work from home personnel that are purchasing more coffee makers.  Existing coffee makers have single functions while consumers want a multi-function hot beverage maker to produce a blend of options like traditional brew or espresso.  There is a huge opportunity if first to market. (INCOSE GtNR 2022)

Define the Mission, Goals, Objectives and Measures

To achieve the MGOs and measures, the project champion collaborates with the stakeholders that participated in defining the problem, threat, or opportunity to better understand what they view as an acceptable outcome by asking them a series of questions:

  • How do they define success?
  • What measures would the stakeholders use to determine success?
  • What is the intended use of the SoI and in what operating environment?
  • What capabilities, features, functions, and performance do they need?
  • What are their expectations for quality and compliance (such as with standards and regulations)?
  • What specific outcome(s) do they expect once the SoI is delivered?
  • What are the measures of success, e.g., measures of effectiveness (MOE), expected of the SoI?

For cases where there is no existing SoI, a common approach is to characterize the “as is” or “present state” in terms of the problem, threat, or opportunity and then characterize the “to be” or “future state” in terms of the resolution of the problem, neutralizing the threat, or the ability to pursue the opportunity.

For existing systems that need to be updated, a common approach is to list the problems or issues with the existing “as-is” system and the reasons it needs to be changed.  Key information includes what value they believe will result from the change by addressing: What can the existing SoI no longer do, what performance needs to be improved, what changes need to be made concerning interactions with external systems, what updates are needed as a result of changes to applicable standards and regulations, what updates are needed as a result of changes in the operational environment or new threats (e.g., security)?

It is also important to understand different perspectives.  The problem, threat, or opportunity, MGOs, and measures from a business perspective may be different than the user’s perspective, both must be addressed.  The user does not necessarily care about the developing organization's profits, time to market, market share, etc., they care about how the resulting SoI meets their needs.  Thus, there could be several sets of MGOs and measures that need to be defined and met by the project team from both a business perspective and a user perspective of the SoI to be developed.  This may lead to conflicts, e.g., product price vs. profitability vs. market share, which need to be prioritized based on the organizational enterprise strategy.

Examples (derived from INCOSE GtNR 2022):

  • Mission statement: Increase revenue by providing a home-based, one-stop, multi-function hot beverage maker.
  • Consumer Goals: Product a blend of options. Obtain home brew beverage quickly.
  • Consumer Objective: Options of brew or expresso. Receive finished home brew coffee within minutes upon request.
  • Consumer-focused Measure: Finished home brew provided within 2 minutes of activation at the selected temperature. Rationale: Consumer survey results.
  • Business Goals: Increase revenue. Increase market share.
  • Business Objective: Increase market share of Company X sales regions.
  • Business-focused Measure: Improve current market share of Company X sales regions by 20%. Rationale: Aligns with the enterprise strategic vision.

Capture Preliminary Life Cycle Concepts

Life cycle concepts, such as the operational conceptoperational concept, define what the SoI needs to do and how well during its intended use in the expected operational environment, from multiple perspectives. This includes various use cases with expected interactions with external systems, identification of drivers and constraints, expected risks to success in the context of the MGOs and measures.

Preliminary life cycle concepts are defined by the organization and include preliminary concepts for acquisition, development, manufacturing or coding, verification, validation, deployment, operations, support, and retirement. Operational concepts include high level operational modes or states, operational scenarios, potential use cases, misuse cases, loss scenarios, or usage within a proposed business strategy. These concepts enable feasibility analysis and evaluation of solution options. For example, concerning acquisition and development how much of the development effort will be done inhouse or outsourced to a supplier? Who will be the overall integrator? If development is done in house, what are the concepts for the supply chain for parts and components?

In a Model-Based Systems EngineeringModel-Based Systems Engineering effort, these life cycle concepts are generated using mission analysis, such as defining use cases associated with users and life cycle stage (Figure 2). Reference Model-Based Systems Engineering (MBSE) for more information regarding usage of MBSE.

Error creating thumbnail: File missing
Figure 2. Example Life Cycle Concepts Using MBSE Approaches. (SEBoK Original)

The life cycle concepts will be further refined within the stakeholder needs definition process. As part of the preliminary life cycle concepts, candidate solution classes are suggested for a possible range of approaches to address the MGOs, as part of a Functional Architecture definition activity.

Identify Uncertainties and Risks

The preliminary life cycle concepts include some level of uncertainty. This leads to risks which need to be identified and managed using the Risk Management process. These risks may also serve as inputs to the generation of additional life cycle concepts (such as addressing cyber security or hazards to successful operation).

Identify Preliminary Concepts of the Solution Space, Including Alternatives

A solution class refers to the means of achieving a solution. Examples include development of a new system, modifying or upgrading an existing system, leveraging multiple existing systems, or generating operational changes.

Possible solution classes to address the problem, threat, or opportunity are assessed against the preliminary life cycle concepts, MGOs and measures. Feasibility of a solution class and its capability to meet the strategic needs are key decision criteria, as well as feasibility considerations in terms of cost, schedule, technology, legal, ethical, environmental, sustainability, etc. The Decision Management process is used to evaluate alternatives and to guide selection. The assessment of alternatives can include modeling, simulation, analytical techniques, or expert judgment to understand the risks, feasibility, and value of the alternative solution classes.

The conclusion of this effort results in the identification of preliminary concepts of the solution space, including alternatives, which are traceable to the organization defined problems/threats/opportunities and MGOs/measures.

Assessment of Continuation of Effort

Upon the conclusion of the Business or Mission Analysis process the organization performs an evaluation on whether to commence with development of the SoI. The key determination is alignment with the enterprise strategy. If the effort is to be continued, a project team will take the outcomes of the Business or Mission Analysis effort and commence with the Stakeholder Needs Definition activity.

References

Works Cited

ISO/IEC/IEEE. 2023. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023.

INCOSE. 2022. INCOSE Needs and Requirements Manual (NRM), version 1.1. INCOSE-TP-2021-002-01.

INCOSE. 2022. INCOSE Guide to Needs and Requirements (GtNR), version 1. INCOSE-TP-2021-003-01

Primary References

ISO/IEC/IEEE. 2023. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023.

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 (NRM), version 1.1. INCOSE-TP-2021-002-01.

INCOSE. 2022. INCOSE Guide to Needs and Requirements (GtNR), version 1. INCOSE-TP-2021-003-01

Additional References

None.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&oldid=71643"