Difference between revisions of "Business or Mission Analysis"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
 
(230 intermediate revisions by 15 users not shown)
Line 1: Line 1:
−
==Introduction, Definition and Purpose==
 
−
'''Introduction''' - The starting point of engineering a system is the definition of the problem to be solved. The stakeholders’ requirements represent the view of the [[User (glossary)|users (glossary)]], [[Acquirer (glossary)|acquirers (glossary)]], and customers of the problem. An important set of activities has to be performed to establish a set of stakeholders’ requirements for a system that can provide the services needed by the acquirer, the users, and the other stakeholders in a defined environment. This section provides knowledge about the notions of needs, expectations, stakeholders’ requirements, concept of operations, and the related systems engineering activities and methods. The set of Stakeholder Requirements represents one of the major outcomes of these activities. For better understanding of this chapter, it is recommended that you read first the Introduction to [[System Definition]] Knowledge Area and the topic [[Fundamentals of System Definition]].
 
−
 
−
 
−
'''Definition and Purpose''' - An initial presentation of stakeholders’ intention is not necessarily a requirement, since it has not been defined, analyzed, or determined to be feasible. This intention is distinguished from a requirement as being (stakeholder) needs, goals or objectives. The distinction between requirements and needs is related to which system is concerned; for example, a [[Requirement (glossary)]] for a system may be allocated to a software element of the system, viewed as needs by the supplier of this software element, and further elaborated as (a) requirement(s) for this software element.
 
−
 
−
An important aspect of engineering is “requirements engineering.” Some activities gathered under this term include:
 
−
*the capture of the needs, goals, and objectives of the various [[Stakeholder (glossary)|Stakeholders (glossary)]];
 
−
*the preliminary identification of the engineering elements of this [[System of Interest (SoI) (glossary)]] in terms of purpose, expected mission, services or operations, objectives, exchanges, and physical interfaces with the objects of its context of use;
 
−
*the enrichment of the needs through the analysis of these first engineering elements of the system, in particular what is called the “mission analysis”;
 
−
*the transformation of these needs into clear, concise, and verifiable Stakeholder Requirements applicable to the System of Interest;
 
−
*the analysis and translation of the Stakeholder Requirements into a set of System Requirements (see topic [[System Requirements]]).
 
−
 
−
Requirements engineering is performed in an iterative manner with the other life cycle processes and recursively through the system design hierarchy.
 
−
 
−
 
 
----
 
----
 +
'''''Lead Authors:''''' ''Garry Roedler'' '''''Contributing Authors:''''' ''Richard Turner, Alan Faisandier, Scott Jackson, Rick Adcock''
 +
----
 +
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}}.
  
−
==Principles about Stakeholder Requirements==
+
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.
−
===From capture of needs to the Stakeholder Requirements definition===
 
−
Several steps are necessary to state the maturity of the needs, from "real needs" to reaching a realized solution (that could be called "realized needs"). The Figure 1 below presents the “Cycle of needs” as it can be deduced from Professor Shoji Shiba and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering purposes.
 
  
−
[[File:SEBoKv05_KA-SystDef_Cycle_of_needs.png|500px|center|Cycle of Needs]]
+
== Purpose and Definition ==
 +
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.
  
−
Figure 1. Cycle of needs (Faisandier, 2011)
+
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.
  
 +
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. 
  
−
This figure shows these steps and the position of the Stakeholder Requirements and System Requirements in the engineering cycle:
+
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.
−
#'''Real needs''' are those that lie behind any perception, and indeed may not be perceived at all; they are conditioned by the context in which people live. As an example, a generic need could be “identify infectious diseases easily”. It often looks like a simple action.
 
−
#'''Perceived needs''' are based on a person’s awareness (possibly imperfect) that something is wrong, that there is a lack of something, that there is something that could improve a situation, or that there are business / investment / market opportunities. Perceived needs are often presented as a list of disorganized expectations, often resulting from an analysis of the usage conditions for the considered action. Following on from the example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, point of care, hospital, human dispensary)". Since the real need is seldom expressed, the richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.
 
−
#'''Expressed needs''' originate from perceived needs in the form of generic actions or constraints, and are typically prioritized.  For example, if safety is the top concern, the expressed need “Protect the operator against contamination” may take priority over other expressed needs, such as “Assist in the execution of tests.” Here the analysis of the expected mission or services in terms of operational scenarios takes place.
 
−
#'''Retained needs''' are selected from a more or less important number of expressed needs. The selection uses the prioritization of expressed needs in order to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a System-of-Interest. The retained needs are generally called "Stakeholder Requirements,” and exploration of potential solutions must start from this step. The various solutions suggested at this step are not yet products but describe means of satisfying the Stakeholder Requirements. Each potential solution imposes constraints on the future System of Interest.
 
−
#'''Specified needs''', generally called “System Requirements”, are the translation of the stakeholders’ requirements to represent the view and expression of the supplier of the problem, having in mind potential feasible solutions. The expression of the System Requirements means that potential solutions as systems exist or can be developed, manufactured, or bought.
 
−
#'''Realized needs''' are the [[Product (glossary)]], [[Service (glossary)]]  or [[Enterprise (glossary)]]realized, taking into account every System Requirement (and hence Stakeholder Requirement).
 
  
 +
==Principles and Concepts==
 
===Mission Analysis and Concept of Operations===
 
===Mission Analysis and Concept of Operations===
−
The notions of Mission Analysis and Concept of Operations originated from Defense organizations to define the tasks and actions performed within the context of military operations, taking into account the strategic, operational, and tactical aspects of a given situation.
+
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:
−
 
−
*'''Mission analysis''' is the process used to identify all unit missions and critical collective tasks. Collective tasks must be identified to determine exactly what the unit must be trained in to support accomplishment of unit missions.  (TRADOC. 1999) appendix A, specifically references for AR 25-30, The Army Integrated Publishing and Printing Program; FM 25-100, Training the Force; FM 25-101, Battle Focused Training; and FM 100-23, Peace Operations. Etc.
 
  
−
*'''The concept of operations''' is a clear, concise statement of where, when, and how the commander intends to concentrate combat power to accomplish the mission.  It broadly outlines considerations necessary for developing a scheme of maneuver. (U.S. Army. 1997), pages 1-268.
+
<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:
  
−
These notions are also used in industrial sectors such as aviation administrations and aeronautic transportation, health care systems, Space, etc. with adapted definitions and/or terms, such as operational concepts, utilization/usage concept and/or technological concept. Examples include:
+
<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>
  
−
*“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 (European Space Agency).
+
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.  
−
 
 
−
*In a large-scale system, such as chemical and nuclear plants, the system functional requirement changes during its operation and its component must also play various roles depending on the system state. Since the logical relation between the system and its components changes during system operation, phased mission analysis (PMA) must be introduced into their reliability analysis (Kohda, Wada, and Inoue. 1994) pages 299-309.
 
  
 +
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 enterprise ConOps and future mission, business, and operational (MBO) objectives;
 +
*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
 +
*how specific missions or operations are currently conducted and what gaps exist in those areas.
  
−
Anywhere these notions are used, it is evident that they are based on fundamental concepts such as [[Operational Mode (glossary)]] (or operational state of the system), Scenario (of actions), operational concepts, functions (provided services), etc. In other words, the system encounters different states during its utilization or operation (Operational Modes). During each state scenarios of services are performed (operational concept); therefore, a scenario is a sequence of actions, functions or services. This means that during the Stakeholder Requirements definition, the description of operational scenarios is a powerful means of identifying the expected or required services of the future system. On the other hand, if the expected services are (pre) defined, the expression of Operational Scenarios provides the expected behavior of the system in use; that is to say, how the user intends to use the system in its various operational modes. For more explanations about the notion of Concept of Operations, refer to (IEEE.1998). Useful information can be found in (ISO/IEC. 2011) Annex A (System Operational Concept) and Annex B (Concept of Operations).
+
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).
  
−
===Classification of Stakeholder Requirements===
+
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).
−
Several classifications of stakeholder requirements are possible. ISO/IEC 29148, section 9.4.2.3 (ISO/IEC. 2011) provides interesting elements for classification. These classifications of Stakeholder Requirements have the goal to facilitate the classification of the System Requirements and, subsequently, to prepare the design and validation activities. One possible way to classify the Stakeholder Requirements is under the following categories as indicated in Table 1.
 
  
−
[[File:SEBoKv05_KA-SystDef_Example_Stakeholder_Requirements_Classification.png|750px|center]]
+
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:
  
 +
<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>
  
−
Table 1 – Example of Stakeholder Requirements classification
+
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).
  
 +
===Mission Analysis as Part of Enterprise Strategy Development===
 +
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 - Stakeholder Requirements==
 
−
===Purpose and principles of the approach===
 
−
The purpose of the Stakeholder Requirements Definition Process is to identify all the needs and expectations from every stakeholder (acquirer, users, and others) and to define the Stakeholder Requirements that express the intended interaction the System of Interest will have with its operational environment. They are the reference against which each resulting operational service is validated.
 
−
 
 
−
Needs and expectations are collected through stakeholders' interviews (including user surveys), technical documents, feedback from the Verification Process and the Validation Process, and from outcomes of the System Analysis Process.  (ISO/IEC. 2008)
 
−
 
 
−
From these needs, the stakeholders’ requirements can be developed. To get a complete set of needs, expectations, and, finally, Stakeholder Requirements, it is necessary to consider the System of Interest in various stages across its typical life cycle. Every system has its own stages of life, from the initial need to the disposal; these may include transfer for use or deployment, normal use in operation, production, maintenance, and disposal. For each stage, a list of all actors having an interest in the future system is identified. Those actors are called [[Stakeholder (glossary)|Stakeholders (glossary)]]. The aim is to get every stakeholder point of view for every stage of the system life in order to establish the list of Stakeholder Requirements as exhaustively as possible.
 
−
 
 
−
An example is provided in the Table 2 below:
 
−
 
 
−
[[File:SEBoKv05_KA-SystDef_Stakeholders_Identification_Based_on_Life.png|600px|center|Stakeholders Identification Based on Life Cycle Stages]]
 
−
 
 
−
Table 2. Stakeholders Identification Based on Life Cycle Stages
 
−
 
 
−
 
 
−
Considering and questioning the classification, as presented in the previous section, allows completion of the set of Stakeholder Requirements.
 
−
 
 
−
A synthesis of the potential System of Interest that could satisfy the Stakeholder Requirements is established by defining its major objectives and its [[Purpose (glossary)]], [[Mission (glossary)]], or services.
 
−
 
 
 
===Activities of the Process===
 
===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.
  
−
Major activities and tasks performed during this process include:
+
===Mission Analysis Artifacts===
−
#Eliciting or capturing the stakeholders' needs, expectations, and requirements; determining the purpose, mission, or services and the major objectives of the potential System of Interest.
 
−
#Analyzing the acquirers’ and users' needs and defining the corresponding Stakeholder Requirements, including the definition of operational/utilization concepts or [[Scenario (glossary)|Scenarios (glossary)]].
 
−
#Exploring, analyzing, and identifying the needs and expectations of the other stakeholders (the list of the stakeholders depends on the system life cycle), including various life cycle constraints.
 
−
#Verifying the quality, completeness of each Stakeholder Requirement and the consistency of the set of Stakeholder Requirements.
 
−
#Validating the content and relevance of each Stakeholder Requirement with the corresponding stakeholder representative providing [[Rationale (glossary)]] of the existence of the requirement.
 
−
#Identifying potential [[Risk (glossary)|Risks (glossary)]] (or threats and hazards) that could be generated by the Stakeholder requirements.
 
−
#Synthesizing, recording and managing the Stakeholder Requirements and potential associated Risks.
 
−
 
 
−
 
 
−
===Artifacts and Ontology Elements===
 
−
This process may create several artifacts such as:
 
−
#Stakeholder Requirements Document
 
−
#Organizational Concept of Operations
 
−
#System Operational Concept
 
−
#Stakeholder Interview Report
 
−
#Stakeholder Requirements Database
 
−
#Stakeholder Requirements Justification Document (for traceability purpose)
 
−
 
 
−
 
 
−
This process handles the ontology elements of Table 3.
 
−
 
 
−
[[File:SEBoKv05 KA-SystDef ontology elements stakeholder requirements.png|600px|center|Main Ontology Elements as Handled within Stakeholder Requirements Definition]]
 
−
 
 
−
Table 3. Main ontology elements as handled within Stakeholder Requirements definition TO BE CHANGED
 
−
 
 
−
 
 
−
The main relationships between ontology elements are presented in Figure 2.
 
−
 
 
−
[[File:SEBoKv05_KA-SystDef_Stakeholder_Requirements_relationships.png|400px|center|Stakeholder Requirements Relationships with Other Engineering Elements]]
 
−
 
 
−
Figure 2. Stakeholder Requirements relationships with other engineering elements (Faisandier, 2011)
 
−
 
 
−
===Checking and correctness of Stakeholder Requirements===
 
−
Stakeholder Requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics which can be used to check Stakeholder Requirements. In general, Stakeholder Requirements should have characteristics as described in section "Presentation and Quality of Requirements" in the topic [[System Requirements]].
 
  
−
Determining the correctness of Stakeholder Requirements requires user-domain expertise which would involve one or more subject matter experts if system engineering team does not have stakeholder domain expertise.
+
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===
 
===Methods and Modeling Techniques===
−
It is strongly recommended that the engineers consider several different techniques or methods for identifying needs, expectations, and requirements during the elicitation activity to better accommodate the diverse set of requirements sources, including:
 
−
*Structured workshops with brainstorming
 
−
*Interviews and questionnaires
 
−
*Observation of environment or work patterns (e.g., time and motion studies)
 
−
*Technical documentation review
 
−
*Market analysis or competitive system assessment
 
−
*Simulations, prototyping, and modeling
 
−
*Benchmarking processes and systems
 
−
*Organizational analysis techniques (e.g., Strengths, Weaknesses, Opportunities, Threats - SWOT analysis, product portfolio)
 
−
*Quality Function Deployment (QFD), which can be used during the needs analysis. QFD is a technique for deploying the "Voice of the Customer.” It provides a fast way to translate customer needs into requirements.
 
−
*Use Case diagram of SysML
 
−
*Context diagram based on Block diagram of SysML
 
−
*Functional Flow Block Diagram
 
  
 +
MA uses several techniques, such as:
 +
 +
*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==
−
 
+
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1.  
−
==Application to Product systems, Service systems, Enterprise systems==
 
−
 
 
−
The classification of Stakeholder Requirements may have differences between those types of systems.
 
−
 
 
−
----
 
−
 
 
  
−
==Practical Considerations about Stakeholder requirements==
+
<center>
−
Some major pitfalls encountered with definition of Stakeholder Requirements are indicated in Table 4.
+
{|
 +
|+'''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>
  
−
[[File:SEBoKv05_KA-SystDef_pitfalls_Stakeholder_Requirements.png|600px|center|Major Pitfalls with Definition of Stakeholder Requirements]]
 
  
−
Table 4. Major pitfalls with definition of Stakeholder Requirements
+
Proven practices with mission analysis and marketing analysis are presented in Table 2.
  
−
 
+
<center>
−
 
+
{|
−
The following proven practices with Stakeholder Requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development - see Table 5.
+
|+'''Table 2. Mission Analysis Proven Practices.''' (SEBoK Original)
−
 
+
!Practice
−
[[File:SEBoKv05_KA-SystDef_practices_Stakeholder_Requirements.png|600px|center|Proven Practices with Definition of Stakeholder Requirements]]
+
!Description
−
 
+
|-
−
Table 5. Proven practices with definition of Stakeholder Requirements
+
|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==  
 
==References==  
−
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
 
  
−
===Citations===
+
===Works Cited===
−
List all references cited in the article.  Note:  SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
+
ANSI/AIAA G-043-2012e, Guide to the Preparation of Operational Concept Documents.
  
−
TRADOC. 1999. Systems approach to training management, processes, and products. Ft. Monroe, VA, USA: U.S. Army Training and Doctrine Command (TRADOC), TRADOC 350-70.  
+
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.
  
 +
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.
  
−
U.S. Army. 1997. Army field manual: Staff organization and operations. Washington, DC: U.S. Department of the Army, FM 101-5.
+
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.
  
 +
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.
  
−
Kohda, T., M. Wada, and K. Inoue. 1994. A simple method for phased mission analysis. Reliability Engineering & System Safety 45 (3): 299-309.  
+
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.
  
 +
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.
  
−
IEEE. 1998. Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document. Institute of Electrical and Electronics Engineers, IEEE 1362:1998.
+
Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).
  
−
 
+
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.
−
ISO/IEC. 2011. Systems and software engineering - Life cycle processes - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC FDIS 29148.  
 
−
 
 
−
 
 
−
ISO/IEC. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).
 
  
 
===Primary References===
 
===Primary References===
−
All primary references should be listed in alphabetical order.  Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ ([[title]]).  Please do not include version numbers in the links.
+
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. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).
 
−
 
 
−
 
 
−
ISO/IEC. 2011. Systems and software engineering - Life cycle processes - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC FDIS 29148.  
 
−
 
 
  
−
INCOSE. 2010. INCOSE systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.  
+
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].
  
 +
INCOSE. 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.
  
−
van Lamsweerde, A. 2009. Requirements Engineering. New York, NY: Wiley.
+
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.
  
 
===Additional References===
 
===Additional References===
−
All additional references should be listed in alphabetical order.
+
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).  
−
 
 
−
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. 2011. Engineering and architecting multidisciplinary systems. (expected--not yet published).
 
−
 
 
−
 
 
−
IEEE. 1998. Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document. Institute of Electrical and Electronics Engineers, IEEE 1362:1998.
 
−
 
 
−
 
 
−
Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010. Systems Engineering, 3rd ed. London: Springer.
 
  
 +
Faisandier, A. 2012.  ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.
  
−
Kano, N. 1984. Attractive quality and must-be quality. Quality JSQC 14 (2) (October 1984).  
+
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.
  
 +
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.
  
−
Kohda, T., M. Wada, and K. Inoue. 1994. A simple method for phased mission analysis. Reliability Engineering & System Safety 45 (3): 299-309.  
+
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.
  
 +
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.
  
−
Marca, D. A., and C. L. McGowan. 1987. SADT: Structured analysis and design techniques. Software engineering. New York, NY: McGraw-Hill.  
+
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC.'' 14(2) (October 1984).  
  
 +
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.
  
−
TRADOC. 1999. Systems approach to training management, processes, and products. Ft. Monroe, VA, USA: U.S. Army Training and Doctrine Command (TRADOC), TRADOC 350-70.  
+
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." ''Software Engineering''. New York, NY: McGraw-Hill.
  
 +
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/].
  
−
U.S. Army. 1997. Army field manual: Staff organization and operations. Washington, DC: U.S. Department of the Army, FM 101-5.
+
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/].
  
 +
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.
 
----
 
----
−
====Article Discussion====
+
<center>[[Business and Mission Analysis|< Previous Article]] | [[Business and Mission Analysis|Parent Article]] | [[Stakeholder Needs Definition|Next Article >]]</center>
  
−
[[{{TALKPAGENAME}}|[Go to discussion page]]]
 
−
<center>[[Fundamentals of System Definition|<- Previous Article]] | [[System Definition|Parent Article]] | [[System Requirements|Next Article ->]]</center>
 
−
==Signatures==
 
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
 +
[[Category:Concept Definition]]
 +
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>

Latest revision as of 22:02, 18 November 2023

Lead Authors: Garry Roedler Contributing Authors: Richard Turner, Alan Faisandier, Scott Jackson, Rick Adcock

The starting point of engineering any system-of-interestsystem-of-interest (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and stakeholderstakeholder 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 usersusers, acquirersacquirers, and customerscustomers.

Mission Analysis (MA) is part of the larger set of concept definitionconcept definition 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.

Purpose and Definition

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 market analysismarket 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.

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.

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

Mission Analysis and Concept of Operations

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:

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)

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:

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)

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.

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 enterprise ConOps and future mission, business, and operational (MBO) objectives;
  • 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
  • how specific missions or operations are currently conducted and what gaps exist in those areas.

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

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

In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:

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

Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the operational modeoperational mode (or state of the system), scenarioscenario (of actions), the enterprise level ConOps and the system level operational concepts, functionsfunctions, 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).

Mission Analysis as Part of Enterprise Strategy Development

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.

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

Activities of the Process

It is necessary to perform the following major activities and tasks during the MA process:

  1. Review and understand the enterprise mission, vision, and ConOps.
  2. Identify and define any gaps and opportunities related to future evolution of the strategy:
    1. Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.
    2. 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 architecture frameworkarchitecture 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.
    3. Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution.
  3. Examine and evaluate the solution space:
    1. Identify the main stakeholders (customers, users, administrations, regulations, etc.).
    2. Identify high level operational modes or states, or potential use cases.
    3. Identify candidate solutions that span the potential solution space, from simple operational changes to various system developments or modifications.
    4. Identify existing systems, products, and services that may address the need for operational or functional modifications.
    5. 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.
  4. 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.
  5. Define basic operational concept or market strategy, and/or business models.
    1. From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.
    2. Collect and enrich needs, expectations, scenarios, and constraints.
    3. Validate the mission of any potential SoI in the context of any proposed market strategy or business model.
  6. Evaluate the set of alternatives and select the best alternative.
    1. Perform a trade study of the alternatives to discriminate between the alternatives.
  7. Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.
  8. 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 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

MA uses several techniques, such as:

  • 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

Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1.

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.


Proven practices with mission analysis and marketing analysis are presented in Table 2.

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

References

Works Cited

ANSI/AIAA G-043-2012e, Guide to the Preparation of Operational Concept Documents.

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.

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.

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.

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.

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.

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.

Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).

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.

Primary References

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. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.

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

Lamsweerde, A. van. 2009. Requirements Engineering: From System Goals to UML Models to Software Specifications. New York, NY, USA: Wiley.

Additional References

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.

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.

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.

Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. Systems Engineering. 3rd ed. London, UK: Springer.

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.

Kano, N. 1984. "Attractive Quality and Must-Be Quality." Quality JSQC. 14(2) (October 1984).

Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." Reliability Engineering & System Safety. 45(3): 299-309.

Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." Software Engineering. New York, NY: McGraw-Hill.

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

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

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

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.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&oldid=69414"