Business or Mission Analysis
The starting point of engineering any system of interest (soi) is the understanding of the socio-economical and technological context where potential problems or opportunities reside. The stakeholders’ needs, expectations and requirements represent the problem or the opportunity from the viewpoint of users, acquirers, and customers. An important set of activities called Mission Analysis (MA), also known as Strategic Analysis, should be performed iteratively with Stakeholder Needs and Requirements to better understand the problem space and solution space while establishing a set of Stakeholder Requirements for a potential SoI or other solution that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment.
Purpose and Definition
The purpose of Mission Analysis (MA) (glossary) is to understand a problem or opportunity of an enterprise, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem to be solved or opportunity.
Mission Analysis, in some domains is known as Strategic Analysis (glossary) or market analysis , is:
MA is the identification, characterization, and assessment of an operational problem/opportunity of the enterprise. It is the definition of a need in the problem-space that frames the solution both in terms of direct application to the mission/business function, and 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. It characterizes the operational need in terms of mission requirements and environment/context together with the enterprise concept of operations and operational scenarios. The primary products of MA are the Concept of Operations of the enterprise, 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 that address the Stakeholder Needs to determine the alternative approach (among both materiel and non-materiel solution alternatives). 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 concept of operations (conops) are broadly used in defense and aerospace organizations to analyze and define how the enterprise is intended to operate and the major operations or operational scenarios that are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. Mission analysis is a type of strategic analysis related to technical needs and solutions that can be applied to any organization that evolves its strategy for its business objectives.
- In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering leaders interact with enterprise leaders to understand the enterprise concept of operations and future mission/business/operational (MBO) objectives, characterization of the concept and objectives (i.e., constraints, mission/operational scenarios, tasks, resources, risks, assumptions, related missions/operations), how specific missions/operations are carried out today, what gaps exist in those areas, and 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 one approach to optimize for specific characteristics (e.g., 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 from those alternatives. (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division)
- “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 of the business with using 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 the future business and systems. (ISO/IEC/IEEE 29148)”
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. 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 (European Space Agency).
In commercial sectors, MA is often primarily performed as Market Analysis. Wikipedia defines Market Analysis as:
- “A market analysis 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, 02/12/12]
Anywhere these notions are used, it is evident that they are based on fundamental concepts such as operational mode (or state of the system), scenario (of actions), enterprise level concept of operations and system level operational concepts, functions (providing services), etc. For more explanations about notion of Concept of Operations, refer to (ISO/IEC.2011). Useful information can be found in (ISO/IEC. 2011) Annex A (System Operational Concept) and Annex B (Concept of Operations).
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 these. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and Stakeholder Needs and Requirements, that are involved in an iterative manner to fully develop the strategy and define the future capabilities and solutions. As the enterprise evolves the strategy, it is essential to do the supporting mission analysis or strategic analysis for each element of the enterprise to determine their readiness to achieve their 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 for impacts and trends and the internal enterprise for its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities and threats. As the problem space is defined, Stakeholder Needs and Requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, future state for core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. (See Stakeholder Needs and Requirements for more information.) Finally, MA is engaged again to examine the solution space. Candidate solutions are identified that span the potential solution space, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand the feasibility and value, and select the best alternative.
Process Approach - Stakeholder Requirements
Purpose and principles of the approach
The purpose of the Stakeholder Requirements Definition Process is to identify the needs and expectations from every stakeholder (acquirer, users, regulator, and others) and to define the Stakeholder Requirements that express the intended interactions that 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 stakeholders . 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:
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 , mission , or services.
Activities of the Process
Major activities and tasks performed during this process include:
- 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 scenarios .
- 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 of the existence of the requirement.
- Identifying potential risks (or threats and hazards) that could be generated by the Stakeholder requirements.
- Synthesizing, recording and managing the Stakeholder Requirements and potential associated Risks.
Artifacts
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 elements of Table 3.
The main relationships between elements are presented in Figure 2.
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 the system engineering team does not have stakeholder domain expertise.
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
Practical Considerations about Stakeholder requirements
Some major pitfalls encountered with definition of Stakeholder Requirements are indicated in Table 4.
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.
References
Works Cited
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." Reliability Engineering & System Safety 45(3): 299-309.
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. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
ISO/IEC/IEEE. 2011. 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.
Primary References
ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.
INCOSE. 2011. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
Lamsweerde, A. van. 2009. Requirements Engineering. 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. 2011 (unpublished). Engineering and Architecting Multidisciplinary Systems.
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.
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," in Software Engineering. New York, NY: McGraw-Hill.