Difference between revisions of "System Definition"

From SEBoK
Jump to navigation Jump to search
Line 4: Line 4:
 
*[[Fundamentals of System Definition|fundamentals of system definition]];
 
*[[Fundamentals of System Definition|fundamentals of system definition]];
 
*[[Mission Analysis and Marketing Analysis]];
 
*[[Mission Analysis and Marketing Analysis]];
*[[Mission Analysis and Stakeholders Requirements|mission analysis and stakeholder requirements]];
+
*[[Stakeholders Requirements]];
 
*[[System Requirements|system requirements]];
 
*[[System Requirements|system requirements]];
*[[Architectural Design|architectural design]]; and
+
*[[Logical Architecture Design]];
 +
*[[Physical Architecture Design]]; and
 
*[[System Analysis|system analysis]].
 
*[[System Analysis|system analysis]].
  

Revision as of 14:41, 12 January 2012

Systems Definition encompasses the activities in the systems engineering process that precede system realization.

Topics

The topics contained within this knowledge area include:



System Definition Activities

System definition is the set of technical creative activities of systems engineering (SE). The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected development cycle model . The processes involved with system definition include mission analysis, stakeholder requirements, system requirements, architectural design, and system analysis topics. The system definition processes and activities are also applied recursively at each successive level of the system hierarchy. See the discussion of iteration and recursion in the Part 3 Introduction: Systems Engineering and Management.

Top-Down Approach: from the Problem to the Solution

In a top-down approach, the system definition activities are focused primarily on understanding the problem, the conditions that constrain the system, and the design of solutions. The outcomes of the system definition are used for the system realization, system deployment and use, and product and service life management. In this approach, system definition includes the activities that are completed primarily in the front-end portion of the system design and the design itself. These consist of mission analysis, stakeholders’ requirements, system requirements, architectural design, and system analysis. Top-down activities can be sequential, iterative, or evolutionary.

  • Mission analysis and stakeholder requirements focus on the identification and definition of stakeholders' needs, the development of operational and environmental conditions, of operational concepts, and the definition of applicable constraints.
  • These elements are then used for the development of system requirements that consist of the refinement and translation of the stakeholders’ requirements into system (technical) requirements.
  • These system requirements are then used as inputs for the architectural design, which includes functional architecture , dynamic behavior, and physical architecture .
  • System analysis studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis provides a best value, balanced solution involving all the relevant engineering elements (stakeholder requirements, system requirements, and architectural design properties).

Bottom-Up Approach and Evolution of the Solution

Engineers are led to reconsider the system definition in order to modify or adapt some structural, functional, or temporal properties during the product and service life cycle because the context of use evolves or for the purpose of improving existing solutions. reverse engineering is often necessary to enable the systems engineer to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that the systems engineer understands the SoI before beginning modification.

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.

Separation and Iteration Between the Problem Area and the Solution Area

Problem definition and solution design depend on each other. Solutions should respond 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 (system elements), a bottom-up approach is used 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, read “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and A 21st Century Systems Methodology (Hitchins 2007).

Ontologies

System definition depends on good ontological structure. See the discussion in Systems Engineering and Management.


References

Citations

Faisandier, A. 2011 (unpublished). Engineering and Architecting Multidisciplinary Systems.

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

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

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008.

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

Additional References

Faisandier. 2011 (unpublished). Engineering and Architecting Multidisciplinary Systems.

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

ISO. 2007. Systems Engineering and Design. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.

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

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.


<- Previous Article | Parent Article | Next Article ->