06 July 2015

System Definition – SEBOK (31)

After the determination of the need for a new or modified system, system definition activities are conducted to describe the system in detail. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected development cycle model. These consist of the definition of system requirements, the definition of the logical and physical system architecture, and system analysis. During and/or at the end of each iteration, gap analysis is performed to insure that all system requirements have been mapped to the architecture and design.

System definition activities build on the artifacts and decisions from concept definition, primarily the articulation of the mission of the system of interest (SoI), the needs and requirements of stakeholders, and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to system realization. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.

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:

• System Requirements

• Architectural Design: Logical

• Architectural Design: Physical

• System Analysis

System Views and System Elements

To engineer a system, a set of engineering elements, characteristics, and properties have to be defined. These elements can be grouped in several views as follows:

• needs and requirements view,

• architecture view,

• boundary and interface view, or

• system breakdown view.

Each of these views is described in the following sections.

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:

• The purpose states the relevance of the system within the context of use.

• The mission expresses the set of services the system provides, the main and global transformation it performs, and how it fulfills a capability or need for the enterprise.

• The objectives are elements that quantify the mission as a set of measurable data related to space, time and effectiveness.

• 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 scenario and describes how these actions are related to each other, as well as what they exchange with the elements of the context.

All these elements are refined iteratively until a comprehensive view of the system within its context is obtained. They are used to elicit needs, to define stakeholder requirements, then system requirements.

Architecture View

There are several architectural representations or views/models of the system:

1.- The logical architecture supports the logical operation of the system all along its life cycle, and includes as a minimum functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of functions and dynamic structures that describe how the mission is performed (behavior).

2.- The physical architecture is a set of system elements performing functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles).

The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture is defined.

Boundary and Interface View

Boundary of the system depends on what engineers include within the scope of the system and outside of it. This view encompasses

1.- Input-Output Flow (glossary) exchanged between the system and elements of its context of use (functional interface)

2.- Physical Interface (glossary) (physical connections) that support these exchanges.

Interactions are modeled and defined using operational scenarios.

System breakdown View

Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements.

Because a system element is primarily a system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive.

Top-down and recursive approach to system decomposition

System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a "building block", a notion introduced in (ANSI/EIA 1998), also called "system block".

Stakeholder requirements and system requirements exist at all layers of the SBS. In (ISO/IEC. 2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of system requirements through levels of abstraction.