Thing as a System

Once a thing has been identified as a system-of-interest and the stakeholders have been identified, a system description can be created. The System Description provides a number of views of a system-of-interest. The following picture shows the views contained in a System Description.

The System Description includes the following sections representing views of the system-of-interest:

• System Name and Class
• System Purpose
• System Properties
• System Stakeholders and their concerns
• System Environment (Context)
• System Structure (Pattern of Organization)
• System Behavior (Structural Changes)
• Correspondences
• Decisions and Rationale
• References

The System Description: System (Abstract) is included in this document. This document highlights the contents of the views and provides guidance for creating system descriptions. In addition, the System Description is used to:

• Establish a set of terminology about a thing in the context of a System (Abstract)

• Identify the concepts and relationships used to shape the System (Abstract) AVPD

• Establishes the system properties that are derived through the interaction of the system elements

• Provides the foundation for further understanding of the thing as a system using the thing body of knowledge.

The system description may contain a System Breakdown Structure that is used to identify some patterns within the system that allow other system-of-interest to be identified:

• Network of systems

• Hierarchy of systems.

Each of the identified systems within a network or hierarchy of systems may become a system-of-interest and may have its own system description.

These system descriptions may also identify the type of system that can form the basis for the system. These types are typically found in a system classification approach. This provides consistency within and across system within an environment.

The system description also provides a common focus for terminology, perspectives, viewpoints and views of the system for relevant sets of stakeholders. These perspectives, and viewpoints are typically defined within an Architecture Description Framework.

NOTE: The original thought for a system description of any system came from the Root Definition used in the Soft Systems Methodology (SSM), from Peter Checkland. (See Root Definition Template). The template for any system went through a number of iterations until the architecture approach for an abstract system was found.