System Concept Definition: Difference between revisions

From SEBoK Draft
Jump to navigation Jump to search
(RWG draft work in process)
No edit summary
Line 2: Line 2:
'''''Lead Author:''''' ''Tami Katz'' '''''Contributing Author:''''' ''Lou Wheatcraft''
'''''Lead Author:''''' ''Tami Katz'' '''''Contributing Author:''''' ''Lou Wheatcraft''
----
----
<s>{{Term|Concept (glossary)|Concept}} Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and {{Term|Stakeholder (glossary)|stakeholders}} are closely examined. The activities are grouped and described as generic processes which include Mission Analysis and Stakeholder Needs and Requirements. Concept Definition begins before any formal definition of the {{Term|System-of-Interest  (glossary)|system-of-interest}} (SoI) is developed.</s>
New Title: Concept Definition


<s>{{Term|Mission Analysis (glossary)|Mission Analysis}} focuses on the needs and requirements of business or enterprise — that is, on defining the problem or opportunity that exists (in what is often called the problem space or problem situation), as well as understanding the constraints on and boundaries of the selected system when it is fielded (in what is often called the solution space).  The {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}} process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. In these two Concept Definition activities, business or enterprise decision makers and other stakeholders describe ''what'' a solution should accomplish and ''why'' it is needed.  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.</s> 
{{Term|Concept (glossary)|Concept}} Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and {{Term|Stakeholder (glossary)|stakeholders}} are closely examined. Concept Definition begins before any formal definition of the {{Term|System-of-Interest  (glossary)|system-of-interest}} (SoI) is developed.  


<s>If a new or modified system is needed, then {{Term|System Definition (glossary)|System Definition}} activities are performed to assess the system. See [[Life Cycle Processes and Enterprise Need]] for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in Concept Definition to the system and system element level of abstraction addressed in System Definition.</s>
The Concept Definition activities include Business or Mission Analysis and Stakeholder Needs and Requirements.


<s>The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of {{Term|Life Cycle Model (glossary)|life cycle model}} being utilized.  See [[Applying Life Cycle Processes]] for further discussion of the concurrent, iterative and recursive nature of these relationships.</s>
*The Business or {{Term|Mission Analysis (glossary)|Mission Analysis}} process focuses on defining the problem or opportunity that exists, as well as understanding the life cycle concepts, constraints on and boundaries of the SoI.
*The {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}} process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution.


New material here:
With these two Concept Definition activities, business or enterprise decision makers and other stakeholders describe ''what'' a solution should accomplish and ''why'' it is needed.  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. 


New Title: Concept Definition: Business or Mission Analysis
The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of {{Term|Life Cycle Model (glossary)|life cycle model}} being utilized.  See [[Applying Life Cycle Processes]] for further discussion of the concurrent, iterative and recursive nature of these relationships.


Business and Mission Analysis is the first step in the Concept Definition Stage, which establishes the overall strategic problem or opportunity, characterizes the solution space with life cycle concepts, and determine potential solution class(es) that can address a problem or take advantage of an opportunity [ISO 15288-2023].                  
The Concept Definition provides input into the {{Term|System Definition (glossary)|System Definition}} activities (System Requirements Definition, System Architecture Definition, and Design Definition) to generate the SoI design.  


Glossary items to Add/edit, from INCOSE NRM:
== Topics==
 
''An '''entity''' is a single item to which a concept, need, or requirement applies: an organization, business unit, project, supplier, service, procedure, SOI (system, subsystem, system element), product, process, or stakeholder class (user, operator, tester, maintainer, etc.)''
 
''A '''concept''' is a textual or graphic representation that concisely expresses how an entity can satisfy the problem, threat, or opportunity it was defined to address within specified constraints with acceptable risk that provides a business capability in terms of people, process, and products. ''
 
A '''''set of lifecycle concepts''''' includes multiple concepts across the lifecycle of how the organization (and entities within an organization) expect to manage, acquire, define, develop, build/code, integrate, verify, validate, transition, install, operate, support, maintain, and retire the system that provides a business capability in terms of people, process, and products.
 
''A '''need statement''' is the result of a formal transformation of one or more lifecycle concepts into an agreed-to expectation for an entity to perform some function or possess some quality within specified constraints with acceptable risk.'' 
 
''A '''requirement statement''' is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for an entity to perform some function or possess some quality within specified constraints with acceptable risk.''
 
'''''Green field''''' system development is when a new system is being developed where there is not an adequate predecessor system.  There may be other similar systems, but the organization or customer has decided to start with a “blank piece of paper”.  For example, an organization is building a new medical diagnostic device. There may be other similar devices in the market or not, but the organization is implementing an innovative approach or technology in this new device.
 
'''''Brown field''''' systems are legacy or heritage systems where there is an existing predecessor system, which can be evolved or transformed into the desired system. This is often the case in consumer products where the organization periodically produces revisions or updates to existing products or new product models for the upcoming year.  
 
==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:  
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:  
*[[Business or Mission Analysis|<s>Business or Mission Analysis</s>]]
*[[Business or Mission Analysis]]
*[[Stakeholder Needs and Requirements|<s>Stakeholder Needs and Requirements</s>]]
*[[Stakeholder Needs and Requirements]]
*x
*x
*System Requirements
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.
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.


==Establishing the Purpose of Developing the System of Interest==
==Concept Definition Activities==
<s>There are two primary activities discussed under concept definition: {{Term|Mission Analysis (glossary)|Mission Analysis}} and the definition of {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}}:</s>
There are two primary activities discussed under concept definition: Business or {{Term|Mission Analysis (glossary)|Mission Analysis}} and the definition of {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}}:


# <s>[[Business or Mission Analysis|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 assist business or enterprise decision makers to 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 encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business requirements.</s>
#[[Business or Mission Analysis|Mission Analysis]] begins
#<s>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.</s>
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 assist business or enterprise decision makers to 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 encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business requirements.
# 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.


<s>Mission Analysis takes the business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives.  Figure 1 in the [[Business or Mission Analysis|Mission Analysis]] topic depicts this interaction.  The products and artifacts produced during Concept Definition are then used in {{Term|System Definition (glossary)|System Definition}}.</s>
<s>Mission Analysis takes the business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives.  Figure 1 in the [[Business or Mission Analysis|Mission Analysis]] topic depicts this interaction.  The products and artifacts produced during Concept Definition are then used in {{Term|System Definition (glossary)|System Definition}}.</s>
Line 52: Line 35:




'''''"Define the Why" by establishing the Problem, Threat, or Opportunity and Mission, Goals, Objectives, and Measures.'''''
Identifying the specific problem or opportunity will enable the project team to understand why the project is worth doing, the system is needed, and the capabilities, functions, performance, and features that are important to the customers, users, and operators of the system. The steps to defining the problem or opportunity include:
1.     Identify the organization’s strategic and business operations level stakeholders that are impacted by the problem or threat or those who will benefit by pursuing the opportunity.
2.     Work with of these stakeholders to understand how they are impacted by the problem or threat or those that will benefit by pursuing the opportunity.
3.     Clearly define a statement of the problem, threat, or opportunity.
4.     Get stakeholder agreement for the problem, threat, or opportunity statement.
Once the problem, threat, or opportunity has been defined, recorded, and agreed to, the project champion and business analyst will collaborate with the stakeholders that participated in identifying and defining the problem or opportunity to better understand what they would view as an acceptable outcome.
·        How do they define success?
·        What measures would the stakeholders use to define success?
·        What is the intended use of the SOI in what operating environment?
·        What capabilities, features, functions, and performance do they need?


·        What are their expectations for quality and compliance (with standards and regulations)?
·        What specific outcome(s) do they expect once the SOI is delivered?
The project champion or business analyst will do a “gap” analysis comparing the “as-is” current state to the “to be” or “future state”.  The result is the identification of the changes that need to be made to the existing “as-is” state that will result in the “to be” or “future state”, the value of these changes, and the expected ROI.  
Guiding questions in this step to be addressed are:
1.    What measures would the stakeholders use to define success?
2.    What is their intended use of the system in what operating environment?
3.    What capabilities, features, functions, performance, quality, and compliance do they need from the delivered system of interest (SOI)?
==<s>Drivers of Solution on Problem Definition: Push Versus Pull</s>==
<s>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.  {{Term|System Analysis (glossary)|System Analysis}} activities are used to provide the link between problems and solutions.</s> 
<s>There are two paradigms that drive the ways in which concept definition is done: ''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 impact other life cycle processes, such as in verification and validation, or alpha/beta testing as done in some commercial domains.</s>
<s>As systems generally integrate existing and new {{Term|System Element (glossary)|system elements}} in a mixture of push and pull, it is often best to combine a bottom-up approach 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.  This is discussed in [[Applying Life Cycle Processes]].</s>


==References==
==References==


===Works Cited===
===Works Cited ===
None.
None.


===Primary References===
===Primary References===
To do - Clean this up:
To do - Clean this up:
<s>ANSI/EIA. 1998. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.</s>


INCOSE. 2023. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
INCOSE. 2023. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
Line 115: Line 50:


ISO/IEC/IEEE. 2023. ''[[ISO/IEC/IEEE 15288|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]]:2023. [to do - ensure link is updated to 2023 writeup]
ISO/IEC/IEEE. 2023. ''[[ISO/IEC/IEEE 15288|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]]:2023. [to do - ensure link is updated to 2023 writeup]
<s>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]].</s>


===Additional References===
===Additional References===
Line 136: Line 69:
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>


[[Category:Part 3]][[Category:Knowledge Area]]
[[Category:Part 3]]
[[Category:Knowledge Area]]

Revision as of 21:23, 21 November 2023

Lead Author: Tami Katz Contributing Author: Lou Wheatcraft

New Title: Concept Definition

ConceptConcept Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and stakeholdersstakeholders are closely examined. Concept Definition begins before any formal definition of the system-of-interestsystem-of-interest (SoI) is developed.

The Concept Definition activities include Business or Mission Analysis and Stakeholder Needs and Requirements.

  • The Business or Mission AnalysisMission Analysis process focuses on defining the problem or opportunity that exists, as well as understanding the life cycle concepts, constraints on and boundaries of the SoI.
  • The Stakeholder Needs and RequirementsStakeholder Needs and Requirements process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution.

With these two Concept Definition activities, business or enterprise decision makers and other stakeholders describe what a solution should accomplish and why it is needed. 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.

The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of life cycle modellife cycle model being utilized. See Applying Life Cycle Processes for further discussion of the concurrent, iterative and recursive nature of these relationships.

The Concept Definition provides input into the System DefinitionSystem Definition activities (System Requirements Definition, System Architecture Definition, and Design Definition) to generate the SoI design.

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: Business or Mission AnalysisMission Analysis and the definition of Stakeholder Needs and RequirementsStakeholder Needs and Requirements:

  1. 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 assist business or enterprise decision makers to 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 encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business requirements.

  1. 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 business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the 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 DefinitionSystem Definition.

The different aspects of how systems thinkingsystems thinking is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of hard systemhard system and soft systemsoft system approaches depending on the type of problem or class of solution is discussed in Identifying and Understanding Problems and Opportunities and the contrast between top-down and bottom-up approaches in Synthesizing Possible Solutions.



References

Works Cited

None.

Primary References

To do - Clean this up:

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

INCOSE. 2022. INOSE Needs and Requirements Manual, version 1.1. INCOSE-TP-2021-002-01.

ISO/IEC/IEEE. 2023. 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:2023. [to do - ensure link is updated to 2023 writeup]

Additional References

To do - Clean this up:

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

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). http://www.hitchins.net/EmergenceEtc.pdf.

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.

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