Difference between revisions of "System Concept Definition"
| Line 30: | Line 30: | ||
# [[Mission Analysis]] begins an iteration of the life cycle of a potential 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 distinguish environmental conditions and constraints that bound the solution space. 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. | # [[Mission Analysis]] begins an iteration of the life cycle of a potential 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 distinguish environmental conditions and constraints that bound the solution space. 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]] works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives. | + | #The [[Stakeholder Needs and Requirements]] activity works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives. |
Mission analysis takes the stakeholder's needs and requirements and carries the analysis down 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|mission analysis]] topic depicts this interaction. The products and artifacts produced during concept definition are then used in [[System Definition (glossary)|system definition]]. | Mission analysis takes the stakeholder's needs and requirements and carries the analysis down 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|mission analysis]] topic depicts this interaction. The products and artifacts produced during concept definition are then used in [[System Definition (glossary)|system definition]]. | ||
Revision as of 17:20, 18 April 2013
<html> <meta name="citation_title" content="Concept Definition"> <meta name="citation_author" content="Pyster, Art"> <meta name="citation_author" content="Olwell, David H."> <meta name="citation_author" content="Hutchison, Nicole"> <meta name="citation_author" content="Enck, Stephanie"> <meta name="citation_author" content="Anthony, James F., Jr."> <meta name="citation_author" content="Henry, Devanandham"> <meta name="citation_author" content="Squires, Alice (eds)"> <meta name="citation_publication_date" content="2012/11/30"> <meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"> <meta name="citation_volume" content="version 1.0.1"> <meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html> Concept definition is the set of systems engineering (SE) activities in which the problem space and the needs of stakeholders are closely examined. This begins before any formal definition of the system-of-interest (SoI) is developed. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected life cycle model.
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. It examines why a solution is desired and what problem or opportunity it will address. Stakeholder needs and requirements explore and define the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. They describes what a solution should accomplish. Both why and what need to be answered before consideration is given to how the problem will be addressed (i.e., what type of solution will be implemented) and how the solution will be defined and developed.
If a new or modified system is needed then system definition activities are performed to assess the system. The specific activities and sequence of concept activities and their involvement in the life cycle activities of any system solutions, will be dependent upon the type of life cycle model being utilized.
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them needs analysis and concept exploration.
Topics
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:
See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 as well as topics covered in Part 3.
Concept Definition Activities
There are two primary activities discussed under concept definition: mission analysis and the definition of stakeholder needs and requirements:
- Mission Analysis begins an iteration of the life cycle of a potential 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 distinguish environmental conditions and constraints that bound the solution space. 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.
- The Stakeholder Needs and Requirements activity works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives.
Mission analysis takes the stakeholder's needs and requirements and carries the analysis down 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.
The different aspects of how systems thinking is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of hard system and soft system approaches depending on the type of problem or class of solution is discussed in the Identifying and Understanding Problems and Opportunities article.
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 the mission context, mission analysis, and the needs to be fulfilled in that context by a new or modified system (i.e., the SoI), and addresses stakeholder needs and requirements.
The system definition activities consider functional, behavioral, temporal, and physical aspects of one or more solutions based on the results of concept definition. System analysis considers the advantages and disadvantages of the proposed system solutions both in terms of how they satisfy the needs established in concept definition, as well as the relative cost, time scales and other development issues. This may require further refinement of the concept definition to ensure all legacy relationships and stakeholders relevant to a particular solution architecture have been considered in the stakeholder requirements.
The outcomes of this iteration between concept definition and system definition define a required system solution and its associated problem context, which are used for system realization, system deployment and use, and product and service life management of one or more solution implementations. In this approach problem understanding and solution selection activities are completed in the front-end portion of system development and design and then maintained and refined as necessary throughout the life cycle of any resulting solution systems. Top-down activities can be sequential, iterative, recursive or evolutionary depending upon the life cycle model.
For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These includes the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B within the concept definition when performing mission analysis and evaluating stakeholder 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 needs are evaluated. 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 for 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, see the System Definition article.
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[Architecture (glossary)|architecture (glossary)]. 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 paradigm is based on creating a solution to address a perceived opportunity, such as the emergence of an anticipated product or service that is attractive to some portion of the population (i.e. whether a current market exists or not). This can have an effect on other lifecycle processes, such as in verification and validation, as it is performed in defense industries versus alpha/beta testing done in some commercial domains.
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 provide 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 that must be provided 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.
References
Works Cited
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.
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.
Kossiakoff, A, and W. Sweet. 2009. Systems Engineering: Principles and Practice. Hoboken, NJ, USA: John Wiley and Sons.
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.
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
Primary References
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.
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.
ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical 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.
Additional References
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 Electrotechnical 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 Electrotechnical Commission (IEC), ISO/IEC 26702:2007.
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight (April 2010): 41-43.
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105. Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.
Hitchins, D. 2008. http://www.hitchins.net/EmergenceEtc.pdf.).
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