Business and Mission Analysis

Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the system of interest (soi) is developed. Mission Analysis focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. Stakeholder Needs and Requirements explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.

Mission analysis examines why a solution is desired; what problem or opportunity it will address. Stakeholder needs and requirements describe what a solution should accomplish. Both why and what need to be answered before any consideration of how the problem will be addressed (i.e., what type of solution) and how the solution will be defined and developed. If the chosen solution is a new or modified system, then System Definition activities are performed to define the system.

Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them needs analysis and concept exploration.

To download a PDF of all of Part 3 (including this knowledge area), please click here.

Topics

The topics contained within this knowledge area include:

• Mission Analysis
• Stakeholder Needs and Requirements

Concept Definition Activities

There are two primary activities discussed under concept definition: mission analysis and the definition of stakeholder needs and requirements:

• Mission Analysis initiates the life cycle of a potential system of interest (SoI) that could solve a problem or realize an opportunity for developing a new product, service or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space.
• Stakeholder Needs and Requirements works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of a desired solution to the problem or opportunity, called Stakeholder Needs. The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements.

In other words, Mission Analysis takes the enterprise capability gap or opportunity and defines the problem/opportunity in a manner that provides a common understanding. Stakeholder Needs and Requirements identifies and defines the needs and requirements of the stakeholders in a manner that enables characterizing the solution alternatives. MA then takes the set of needs and requirements and carries the analysis down to the point that the needs and requirements have been transitioned from problem space to solution space including concept, requirement (stakeholder/mission) and boundary or context so that a solution concept (black box level) can be selected from the alternatives. Figure 1 in the mission analysis topic depicts this interaction. The products and artifacts produced during concept definition are then used in System Definition.

Top-Down Approach: from Problem to Solution

In a top-down approach, concept definition activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the System-Of-Interest) is needed to fulfill the need. The system definition activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for system realization, system deployment and use, and product and service life management. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of Mission Analysis and the definition of Stakeholder Needs and Requirements and generally consist of the development of system requirements that consist of the refinement and translation of the stakeholder requirements into system (technical) requirements. These system requirements are then used as inputs for the logical architecture design, which includes functional, behavioral, temporal, and physical architectural aspects. System Analysis studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties). For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These include DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.

Bottom-Up Approach: Evolution of the Solution

In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaaluated and engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the product or service life cycle to adapt to a changing context of use or for the purpose of improving existing solutions. reverse engineering is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, please see System Definition.)

A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design architecture . Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.

Bottom-up and top-down approaches can be, and often are, mixed.

Drivers of Solutions: Push versus Pull

There are two paradigms that drive the concept definition - 'push' and 'pull'. The 'Pull' paradigm is based on providing a solution to an identified problem or gap, such as a missing mission capability for defense or infrastructure. The 'Push' paradign is based on creating a solution to address a perceived opportunity, such as a product or service anticipated to be wanted by or attractive to some portion of the population (whether a current market exists or not).

Separation and Iteration between Problem and Solution

Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. System analysis activities are used to perform the link between problems and solutions.

As systems generally integrate existing and new system elements , a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in System Life Cycle Process Models: Iterative, this is iterative for these evolutionary systems.

For more details about systems approaches, please see the Systems Approach Applied to Engineered Systems Knowledge Area. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and A 21st Century Systems Methodology (Hitchins 2007) are recommended.

References

Works Cited

Kossiakoff, A, and W. Sweet. 2009. Systems Engineering: Principles and Practice. Hoboken, NJ, USA: John Wiley and Sons.

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.

Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight (April 2010): 41-43.

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.

ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.

ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 19760:2003 (E).

ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.

NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.

Additional References

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.

Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight (April 2010): 41-43.

---

< Previous Article | Parent Article | Next Article >

Comments from SEBoK 0.5

This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.

SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus