System Definition

Topics

The topics contained within this knowledge area include:

• Fundamentals of System Definition
• Stakeholder Requirements
• System Requirements
• Architectural Design
• System Analysis

---

1. Introduction to System Definition Knowledge Area

The SEBOK divides the traditional life cycle process steps into four stages. This chapter will discuss the definition stage.

System definition is the set of technical creative activities of systems engineering (SE). It 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 and stakeholders’ requirements, system requirements, architectural design, and system analysis. Mission analysis and stakeholders’ requirements focus on the identification and definitions of stakeholders' needs, the development of operational and environmental conditions, operational concepts, and the definition of applicable constraints. These elements then are used for the development of system requirements that consists of the translation of the stakeholders’ requirements into system requirements. These system requirements are then utilized as inputs to the architectural design, which includes functional, dynamic, and physical architectures in addition to temporal and decision levels. System Analysis studies are performed to evaluate and select potential system elements that compose the system and to compare potential architectures and to select the most suitable one. Finally, System Analysis provides a “best value” balanced solution involving all the relevant engineering elements (stakeholders’ requirements, system requirements, and architectural design characteristics).

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.

The System Definition activities are grouped and described as generic processes that are performed iteratively and concurrently depending of the selected development or life cycle. The activities of a process are not performed only on a sequential mode but they may interact with activities of other related processes.

The complete definition of a system-of-interest is generally achieved considering decomposition layers of sub-systems (systems) and of end products (system elements). In each decomposition layer and for each system, the System Definition processes are applied recursively.

Note: To facilitate readers' understanding of the standard 145 ISO/IEC. 2008 (see § 9), Figure 1 shows the relative position of the Technical Knowledge Areas (KA) of this SEBoK with respect to the processes as stated in the standard.

FIGURE 1

---

2. Fundamentals – Process approach

2.1. Top-down and recursive approach of system decomposition

2.1.1. Engineering elements related to the notion of system

The notion of system is defined and discussed in part 2 of the SEBoK. One implements in the present chapter those concepts and definitions providing more details to engineering a generic system. To engineer any kind of system, a set of engineering elements and characteristics have to be identified and/or defined. These elements can be grouped in several views such as:

• The needs and requirements view - The following characteristics provide a global understanding of the system in its context of use and seen as a black box.
  • Purpose – The purpose states the relevance of the system within the context of use. The purpose is the answer to the questions “Why does the system exist? What is the relevance of its existence within the context? What is the usage of the system?”
  • Mission – The mission expresses the set of services the system provides, the main and global transformation it performs. The mission is the answer to the questions “What is the system expected to do? What it does? What is it transforming? What service it provides?”
  • Objectives – The objectives are elements that quantify the mission, as a set of measurable data related to space, time and effectiveness. The objectives are the answers to the questions: “How many inputs are transformed into outputs? What are the measures of effectiveness? How many times? How often? How many, etc.? ”
  • Operational concept or operational scenario(s) – The expression of the mission is generally an abstraction of a set of actions performed by the system within its context of use and under operational conditions. This set of actions is called operational scenarios and describes how these actions are related to each others and what they exchange with the elements of the context.

All these four elements are analysed and refined iteratively till obtaining a comprehensive view of the system within its context. They are used to elicit the needs, to define the Stakeholders Requirements and then the System Requirements.

• The architectural view - Two complementary aspects of the system provide the fundamental basis of the existence of the system:
  • The functional architecture which is a structure of functions that enables the system to perform all identified operational scenarios, all along its life cycle. Operational scenarios refine the mission into a collection of functions and dynamic structures that describe how the mission shall be performed.
  • The physical architecture which is a set of components performing the functions of the system. Those components can be either material or immaterial (sub-systems, or system elements such as equipments made of hardware, software and/or human roles).

These two architectures are mapped onto each other. The interactions of the components are defined by interfaces whose complexity strongly depends on the way these two architectures are designed.

• The boundary and interface view – The boundary of the system depends on what the system engineer includes within the scope of the system and outside of it. This view encompasses the input/output flows exchanged between the system and the elements of its context of use (functional interface), and the physical connections (physical interface) that support these exchanges. Interactions between the system and the elements of its context of use are modelled and defined using the operational scenarios.

• The breakdown view – Facing the potential number of end products (system elements) that constitute the physical architecture of the system, sets of end products can be grouped to form sub-systems. So, the decomposition of the system-of-interest (highest level) may include several layers of systems (intermediate levels of systems) until technological end products so called system elements (lowest level) are defined. Because a sub system is primarily a system, it can be viewed and characterized in its turn using the three previous views in its own context. But the context of a (sub) system can be viewed as a system. So the notion of system as described and defined here is recursive. Rather than using the terms hierarchical decomposition levels one prefers using the term encapsulation of systems as Russian dolls image.

2.1.2. Recursive usage and iteration of engineering processes

Because the notion of system is recursive all along the decomposition in layers of systems, the processes used to engineer and define a system should be recursive. Every instantiation of processes …

TO BE CONTINUED

2.2. Bottom-up approach of system definition

TO BE WRITTEN

2.3. Re-use of components and reverse engineering

Most of the time, systems incorporate existing components. This re-use constraint has to be identified as a requirement as soon as possible and carefully taken into account during the definition of the system. There are three general cases when re-using components:

• Case 1: The requirements of the component are up-to-date and the component will be re-used with no modification required:
  • the system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used component;
  • if the component is not adapted, costs, complexity, and risks will increase.

• Case 2: The requirements of the component are up-to-date and the component will be re-used with possible modifications:
  • the system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used component;
  • the design of the re-used component, including its test reports and other documentation, will be evaluated and potentially redesigned.

• Case 3: The requirements are not up-to-date or do not exist:
  • it is necessary to reverse engineer the component to identify its boundaries, interfaces, functions, performances, and behavior. This is a difficult activity since the extant documentation for the re-used component is likely unavailable or insufficient;
  • reverse engineering is expensive in time and money; risks are increased.

Re-use involves additional risks that can be significant for the project (costs, deadlines, complexity). Disappointment is all the more severe because of the widespread false idea that "re-use = 0 Dollars".

2.4 Ontology for System Definition

Ontology is the set of entities presupposed by a theory (Collins English Dictionary). SE, and in particular system definition, can be considered a theory because it is based on mathematical concepts, even if it is not always described as such. A SE ontology can be defined considering the following path.

SE provides engineers with an approach based on a set of concepts (i.e. stakeholder, requirement, function, scenario, component, etc.) and generic processes. Each process is composed of a set of activities and tasks federated around a theme or a purpose. A process describes “what to do” using the concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, composed themselves of elementary tasks; they describe the “how to do”. The activities and tasks of SE are transformations of generic data using the predefined concepts. Those generic data are called Entities, Classes, or Types. Each entity is characterized by specific attributes, and each attribute can get different values. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical relationships. These relationships allow the engineer to link the entities between themselves (traceability) and to follow the logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum or maximum number of entities in order to make the relationship valid. Additional information may be found in (Oliver, Kelliher, and Keegan 1997).

The set of SE entities and their relationships form an ontology also called Engineering Meta-model. Such an approach is used and defined in the standard. ISO/IEC. 2007 The benefits of using an ontology are many. The ontology allows or forces:

• use of a standardized vocabulary, using the right names and avoiding using synonyms in the processes, methods, and modeling techniques;
• reconcilement of the vocabulary used in different modeling techniques and methods;
• the automatic appearance of traceability of requirements when implemented in databases, SE tools or workbenches, and also the quick identification of the impacts of modifications in the engineering data set;
• checks of the consistency and completeness of engineering data, etc.

An Engineering Meta-model can be represented using Entity-Relationship Diagrams or Classes Diagrams. The Figure 2 shows a synthetic view of a simplified Engineering Meta-model. A set of major entities, attributes, and relationships are suggested and defined in the following sections.

FIGURE 2

TO BE CONTINUED WITH ACTIONS RELATED TO COMMENT 2156

---

3. Fundamentals – Requirements and Design

3.1. Problem and Solution Areas

Inside the System Definition activities, the Systems Engineering discipline makes a significant distinction between the definition of the problem and the design of the solution. Too often, the design team will develop solutions elements ("how the system must be done") without sufficiently defining the problem to be solved and the constraints to respect ("what the system must do"). To correctly engineer a system, it is necessary to differentiate the activities that treat the problem area in terms of needs, expectations, constraints, and requirements from those that treat the solution area in terms of functional, behavioral, physical design. Nevertheless, the two must work together.

3.2. Different understandings of “requirements” in Systems Engineering

The term “requirement” is often used inconsistently at different points during the engineering of a system. This is why a qualifier is added while considering following kinds of requirements: stakeholder requirement, system requirement, derived requirement, and specified requirement. Every kind of these requirements represents a single notion, and different dedicated activities for their definition are considered during engineering. The Figure 3 helps to identify the different kinds of requirements and their relationships and to use the right set of terms during engineering.

INSERT THE NEW FIGURE 3 + COMMENT 259

All along the engineering of the system, several transformations concerning these kinds of requirements are performed:

• The more or less well-expressed needs, expectations, and other constraints imposed by the customer, users, and other stakeholders are transformed into stakeholder requirements, which represent the stakeholders’ view of the system. This transformation is performed using the stakeholders' requirement definition process (see section 3.3.4.3).
• The stakeholders’ requirements are transformed into system requirements, which represent the designer's view of the system. This transformation is performed using the system requirements definition process, called requirements analysis process in ISO/IEC 15288 (ISO/IEC 2008) (see section 3.3.5.3).
• The system requirements are transformed into specified requirements (also called Design Characteristics), which represent the system as designed. This transformation is performed using the architectural design process (see section 3.3.6.3).

In summary, the key purpose of the requirements engineering activity is to translate all stakeholders’ needs into an integrated and coherent set of well-formed System Requirements, which are then used to design the system. Applying the same perspective from the lowest levels of the design, requirements should be traceable back to the requirements from which they were derived or allocated, iteratively, to the original Stakeholders’ Requirements. For additional explanations about the differences between stakeholder, user, and customer, and between those kinds of requirements, refer to (Martin 1997, chapter 2).

ADD ACTION RELATED TO COMMENTS 3100 & 3101

3.3. System Design

ADD ACTION RELATED TO COMMENTS 2130a, 233, 1149, 3102, 2558, 923, 468, 2054

3.4. Iteration and interaction of requirements and design processes

ADD ACTION RELATED TO COMMENTS 2321, 3099, 1182

---

8. Practical Considerations (global to the KA)

THIS TEXT SHOULD BE PLACED AT THE END OF THE KA ... BUT THERE IS NO TOPIC FOR THAT !

Pitfalls - There is a common mistake made by system developers who skip the design of intermediate levels of the system hierarchy. This mistake consists of allocating the system requirements of the SOI level directly onto the sub-systems or the system elements of lower levels without any study and/or transformation. The effect of this practice obliges the designers of the components of the last level to imagine what could be expected by the users of the system without having the complete understanding of what the sub-systems or system elements shall do or shall be. The proven practice is to understand and implement the considerations explained in section 3.3.3.2. The traceability of requirements is ensured through the different system-blocks according to the diagram below (see Figure 14).

FIGURE 14

ADD ACTION RELATED TO COMMENT 1646

---

9. Primary References

ADD ACTION RELATED TO COMMENT 753b

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

Blanchard, B. S., and W. J. Fabrycky. 2005. Systems engineering and analysis. Prentice-hall international series in industrial and systems engineering. 4th ed. Englwood Cliffs, NJ, USA: Prentice-Hall.

Faisandier, A. 2011. Engineering and architecting multidisciplinary systems. www.mapsysteme.com/uk.

Hooks, I. F., and K. A. Farry. 2000. Customer-centered products: Creating successful products through smart requirements management. New York, NY: American Management Association.

INCOSE. 2010. INCOSE systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.

ISO/IEC. June 2010. Software and systems engineering -- life cycle processes -- requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC CD 29148.

ISO/IEC. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).

ADD ACTION RELATED TO COMMENT 1150

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.

Maier, M., and E. Rechtin. 2002. The art of systems architecting. 2nd ed. Boca Raton, FL, USA: CRC Press.

Martin, J. N. 1997. Systems engineering guidebook: A process for developing systems and products. 1st ed. Boca Raton, FL, USA: CRC Press.

NASA. December 2007. Systems engineering handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY: McGraw-Hill.

Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. Systems engineering leading indicators guide, version 2.0. San Diego, CA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.

Thome, B. 1993. Systems engineering, principles & practice of computer-based systems engineering. New York, NY: Wiley.

van Lamsweerde, A. 2009. Requirements engineering. New York, NY: Wiley.

TO BE COMPLETED

---

10. Additional References and Reading

Buede, D. M. 2009. The engineering design of systems: Models and methods. 2nd ed. Hoboken, NJ: John Wiley & Sons Inc.

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

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

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 misison analysis. Reliability Engineering & System Safety 45 (3): 299-309.

Marca, D. A., and C. L. McGowan. 1987. SADT: Structured analysis and design techniques. Software engineering. New York, NY: McGraw-Hill.

TRADOC. 1999. Systems approach to training management, processes, and products. Ft. Monroe, VA, USA: U.S. Army Training and Doctrine Command (TRADOC), TRADOC 350-70.

U.S. Army. 1997. Army field manual: Staff organization and operations. Washington, DC: U.S. Department of the Army, FM 101-5.

TO BE COMPLETED

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.

---

Article Discussion

[Go to discussion page]