Difference between revisions of "Business or Mission Analysis"

From SEBoK
Jump to navigation Jump to search
(Byline)
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(56 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
----
 
----
'''''Lead Authors:''''' ''Alan Faisandier, Scott Jackson,'' '''''Contributing Authors:''''' ''Richard Turner, Garry Roedler, Rick Adcock''
+
'''''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 socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and {{Term|Stakeholder (glossary)|stakeholder}} needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of {{Term|User (glossary)|users}}, {{Term|Acquirer (glossary)|acquirers}}, and {{Term|Customer (glossary)|customers}}.  
+
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.  
  
Mission Analysis (MA) is part of the larger set of {{Term|Concept Definition (glossary)}} activities - the set of systems engineering activities in which the problem space and the needs of the business or enterprise and stakeholders are closely examined. This occurs before any formal definition of the (SoI) is developed but may need to be revisited through the life cycle. In fact, 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. The MA activity focuses on the identification of the primary purpose(s) of the solution (its "mission"), while [[Stakeholder Needs and Requirements]] activity explores what capabilities stakeholders desire in accomplishing the mission and may include some detail on the performance of certain aspects of the solution. MA is often performed iteratively with the [[Stakeholder Needs and Requirements]] activity to better understand the problem (or opportunity) space, as well as the solution space.
+
''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.  
  
== Purpose and Definition ==
+
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.
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA 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.
 
  
MA, in some domains called {{Term|Market Analysis (glossary)|market analysis}} or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission or business function in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution.  
+
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.  
  
MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. MA begins with the business vision and Concept of Operations (ConOps) (IEEE. 1998), and other organization strategic goals and objectives including the mission (or business function). The primary products of MA are Business or Mission Needs, which are supported by preliminary life-cycle concepts—including a preliminary acquisition concept, a preliminary operational concept (OpsCon), a preliminary deployment concept, a preliminary support concept, and a preliminary retirement concept. Business or Mission Needs are then elaborated and formalized into Business or Mission Requirements.  The preliminary operational concept includes the operational scenarios for the mission and the context in which the solution will exist. 
+
== Purpose and Definition ==
 
+
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.
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.
 
  
 
==Principles and Concepts==
 
==Principles and Concepts==
===Mission Analysis and Concept of Operations===
+
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?'')
MA and the terms ConOps and OpsCon are broadly used in U.S. and UK defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed. They take into account the strategic, operational, and tactical aspects of the identified scenarios. ANSI/AIAA G-043A-2012 (ANSI 2012) identifies that the terms ‘concept of operations’ and ‘operational concept’ are often used interchangeably but notes that an important distinction exists because each has a separate purpose and is used to meet different ends. The ConOps is at an organizational level, prepared by enterprise management and refined by business management:
 
 
 
<blockquote>''The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems.'' (ISO/IEC 2011) </blockquote>
 
 
 
The ConOps informs the OpsCon, which is drafted by business management in the Mission Analysis activity and refined by stakeholders in the [[Stakeholder Needs and Requirements]] activity:
 
 
 
<blockquote>''A system OpsCon document describes what the system will do (not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of the to-be-delivered system from the user's viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system characteristics to the acquirer, user, supplier and other organizational elements.'' (ISO/IEC 2011) </blockquote>
 
  
It should be noted that the OpsCon has an operational focus and should be supported by the development of other concepts, including a deployment concept, a support concept, and a retirement concept.  
+
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.  
  
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand:
+
* 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?
*the enterprise ConOps and future mission, business, and operational (MBO) objectives;
+
* ''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.
*the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and
+
* ''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?
*how specific missions or operations are currently conducted and what gaps exist in those areas.
+
* ''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]]).
  
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).
+
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.
  
The notions of mission analysis, ConOps and OpsCon are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, and space with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (ESA 2008).
+
[[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)]]
  
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:
+
There are several outputs of the Business or Mission Analysis process:
  
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia Contributors, 2012)</blockquote>
+
* 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.
  
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the {{Term|Operational Mode (glossary)|operational mode}} (or state of the system), {{Term|Scenario (glossary)|scenario}} (of actions), the enterprise level ConOps and the system level operational concepts, {{Term|Function (glossary)|functions}}, etc. For more explanations about the ConOps and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept," and Annex B, "Concept of Operations" (ISO/IEC 2011).
+
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.
  
===Mission Analysis as Part of Enterprise Strategy Development===
+
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]]).
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including the MA and [[Stakeholder Needs and Requirements]] activities that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions.
 
 
 
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|'''Figure 1. Enterprise Strategy and Concept Development (Roedler 2012).''' Used with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]
 
 
 
As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.
 
  
 
==Process Approach==
 
==Process Approach==
===Activities of the Process===
 
It is necessary to perform the following major activities and tasks during the MA process:
 
#Review and understand the enterprise mission, vision, and ConOps.
 
#Identify and define any gaps and opportunities related to future evolution of the strategy:
 
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.
 
##Analyze the context of the actual political, economic, social, technological, environmental, and legal (PESTAL) factors, while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate {{Term|Architecture Framework (glossary)|architecture framework}} representation, such as the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows 1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B should be included within the concept definition when performing mission analysis and stakeholders needs and requirements.
 
##Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution.
 
#Examine and evaluate the solution space:
 
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).
 
##Identify high level operational modes or states, or potential use cases.
 
##Identify candidate solutions that span the potential solution space, from simple operational changes to various system developments or modifications. 
 
##Identify existing systems, products, and services that may address the need for operational or functional modifications.
 
##Deduce what potential expected services may be needed. The SoI is a potential and not yet existing product, service or enterprise. Additionally, the solution could be an operational change or a change to an existing product or service.
 
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.
 
#Define basic operational concept or market strategy, and/or business models.
 
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.
 
##Collect and enrich needs, expectations, scenarios, and constraints.
 
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.
 
#Evaluate the set of alternatives and select the best alternative.
 
##Perform a trade study of the alternatives to discriminate between the alternatives.
 
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.
 
#Define preliminary deployment concept, preliminary support concept, and preliminary retirement concept.
 
 
===Mission Analysis Artifacts===
 
 
This process may create several artifacts, such as:
 
*recommendations for revisions to the enterprise ConOps;
 
*preliminary operational concept document or inputs;
 
*mission analysis and definition reports (perhaps with recommendations for revisions of the mission);
 
*a set of business needs;
 
*preliminary life-cycle concepts (preliminary operational concept, preliminary deployment concept, preliminary support concept, and preliminary retirement concept;
 
*[[System Analysis|system analysis]] artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);
 
*trade study results (alternatives analysis);
 
*market study/analysis reports; and
 
*a set of business (or mission) requirements (often captured in a business requirement specification).
 
  
===Methods and Modeling Techniques===
+
=== '''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.
  
MA uses several techniques, such as:
+
=== '''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.  
*use case analysis;
 
*operational analysis;
 
*functional analysis;
 
*technical documentation review;
 
*trade studies;
 
*modeling;
 
*simulation;
 
*prototyping;
 
*workshops, interviews, and questionnaires;
 
*market competitive assessments;
 
*benchmarking; and
 
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).
 
  
==Practical Considerations==
+
There are four steps to defining the problem, threat, or opportunity:
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1.
 
  
<center>
+
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.
{|
 
|+'''Table 1. Major Pitfalls for Mission Analysis.''' (SEBoK Original)
 
!Pitfall
 
!Description
 
|-
 
|Wrong level of system addressed
 
|When delineating the boundaries of the SoI and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the SoI.
 
|-
 
|Operational modes or scenarios missing
 
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the SoI will be used, in which situations, etc.) is often encountered.
 
|}
 
</center>
 
  
 +
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.
  
Proven practices with mission analysis and marketing analysis are presented in Table 2.
+
3.    Clear definition of the problem, threat, or opportunity.
  
<center>
+
4.    Stakeholder concurrence with the problem, threat, or opportunity statement.
{|
 
|+'''Table 2. Mission Analysis Proven Practices.''' (SEBoK Original)
 
!Practice
 
!Description
 
|-
 
|Models of operational scenarios
 
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of SoI (including commercial systems).
 
|-
 
|Models of the context
 
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).
 
|}
 
</center>
 
  
==References==
+
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)
  
===Works Cited===
+
=== '''Define the Mission, Goals, Objectives and Measures''' ===
ANSI/AIAA G-043-2012e, Guide to the Preparation of Operational Concept Documents.
+
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:
  
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.
+
* 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?
  
ESA. 2008. ''Mission Analysis: Towards a European Harmonization.'' Paris, France: European Space Agency. Accessed August 29, 2012. Available at: http://www.esa.int/esapub/bulletin/bulletin134/bul134b_schoenmaekers.pdf.
+
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.
  
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.
+
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)?
  
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Life Cycle Processes - Requirements Engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148:2011.
+
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.
  
NDIA. 2010. “Mission Analysis Committee Charter”. Website of the National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee. Accessed August 29, 2012. Available at: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Mission%20Analysis%20Committee%20Charter.pdf.
+
Examples (derived from INCOSE GtNR 2022):
  
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.
+
* 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.
  
Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).
+
=== '''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.
  
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
+
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?
  
===Primary References===
+
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)]]
ISO/IEC/IEEE. 2015. ''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:2015.
 
  
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]].
+
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.
  
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.
+
=== '''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).
  
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.
+
=== '''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.  
  
===Additional References===
+
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.
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal.'' 2(4) (Fall 1993).  
 
  
Faisandier, A. 2012.  ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.
+
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.
  
Freeman, R. "Chapter 27: Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise," in ''Handbook of Military Industrial Engineering.'' A.B. Badiru and M.U. Thomas (eds). Boca Raton, FL, USA: Taylor & Francis Group, CRC Press.
+
=== '''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==
  
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.
+
===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.
  
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.
+
INCOSE. 2022. ''INCOSE Needs and Requirements Manual (NRM)'', version 1.1. INCOSE-TP-2021-002-01.
  
Kaplan, R.S. and D.P. Norton. 2008. “Developing the Strategy: Vision, Value Gaps, and Analysis,” Balanced Scorecard Report. Cambridge, MA, USA: Harvard Business School Publishing, Jan-Feb 2008.
+
INCOSE. 2022. ''INCOSE Guide to Needs and Requirements (GtNR)'', version 1. INCOSE-TP-2021-003-01
  
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC.'' 14(2) (October 1984).  
+
===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.
  
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.  
+
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.
  
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." ''Software Engineering''. New York, NY: McGraw-Hill.
+
INCOSE. 2022. ''INCOSE Needs and Requirements Manual (NRM)'', version 1.1. INCOSE-TP-2021-002-01.
  
MITRE. 2011. "Concept Development."  ''Systems Engineering Guide.'' Accessed 9 March 2012 at [http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/ http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/].
+
INCOSE. 2022. ''INCOSE Guide to Needs and Requirements (GtNR)'', version 1. INCOSE-TP-2021-003-01
  
MITRE. 2011. "Requirements Engineering." ''Systems Engineering Guide.'' Accessed 9 March 2012 at [http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/ http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/].
+
===Additional References===
 
+
None.  
MITRE. 2011. "Stakeholder Assessment and Management." ''Systems Engineering Guide.'' Accessed 9 March 2012 at [http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html/ http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html/].
 
 
 
Shupp, J.K. 2003. “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures.” Proceedings of INCOSE 13th International Symposium, July 2003.
 
 
----
 
----
<center>[[Concept Definition|< Previous Article]] | [[Concept Definition|Parent Article]] | [[Stakeholder Needs and Requirements|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.1, released 31 October 2019'''</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