System context diagram

Last updated

Example of a system context diagram. NDE Context Diagram (vector).svg
Example of a system context diagram.

A system context diagram in engineering is a diagram that defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it. [2] This diagram is a high level view of a system. It is similar to a block diagram.

Contents

Overview

System context diagrams show a system, as a whole and its inputs and outputs from/to external factors. According to Kossiakoff and Sweet (2011): [3]

System Context Diagrams ... represent all external entities that may interact with a system ... Such a diagram pictures the system at the center, with no details of its interior structure, surrounded by all its interacting systems, environments and activities. The objective of the system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of systems requirements and constraints.

System context diagrams are used early in a project to get agreement on the scope under investigation. [4] Context diagrams are typically included in a requirements document. These diagrams must be read by all project stakeholders and thus should be written in plain language, so the stakeholders can understand items within the document.

Building blocks

Context diagrams can be developed with the use of two types of building blocks:

For example, "customer places order." Context diagrams can also use many different drawing types to represent external entities. They can use ovals, stick figures, pictures, clip art or any other representation to convey meaning. Decision trees and data storage are represented in system flow diagrams.

A context diagram can also list the classifications of the external entities as one of a set of simple categories [5] (Examples: [6] ), which add clarity to the level of involvement of the entity with regards to the system. These categories include:

Alternatives

The best system context diagrams are used to display how a system interoperates at a very high level, or how systems operate and interact logically. The system context diagram is a necessary tool in developing a baseline interaction between systems and actors; actors and a system or systems and systems. Alternatives to the system context diagram are:

Example of an Architecture Interconnect Diagram. Greater Yellowstone Rural ITS Architecture Interconnect Diagram.jpg
Example of an Architecture Interconnect Diagram.

Most of these diagrams work well as long as a limited number of interconnects will be shown. Where twenty or more interconnects must be displayed, the diagrams become quite complex and can be difficult to read. [7]

See also

Related Research Articles

<span class="mw-page-title-main">Data model</span> Model that organizes elements of data and how they relate to one another and to real-world entities.

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.

In software and systems engineering, the phrase use case is a polyseme with two senses:

  1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
  2. A potential scenario in which a system receives an external request and responds to it.

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure Programing language.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

<span class="mw-page-title-main">Data modeling</span> Creating a model of the data in a system

Data modeling in software engineering is the process of creating a data model for an information system by applying certain formal techniques.

<span class="mw-page-title-main">Information model</span>

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

<span class="mw-page-title-main">Department of Defense Architecture Framework</span> Enterprise architecture framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

<span class="mw-page-title-main">IDEF0</span>

IDEF0, a compound acronym, is a function modeling methodology for describing manufacturing functions, which offers a functional modeling language for the analysis, development, reengineering and integration of information systems, business processes or software engineering analysis.

A conceptual model is a representation of a system. It consists of concepts used to help people know, understand, or simulate a subject the model represents. In contrast, a physical model focuses on a physical object such as a toy model that may be assembled and made to work like the object it represents.

<span class="mw-page-title-main">IDEF1X</span>

Integration DEFinition for information modeling (IDEF1X) is a data modeling language for the development of semantic data models. IDEF1X is used to produce a graphical information model which represents the structure and semantics of information within an environment or system.

<span class="mw-page-title-main">System Architect</span> Enterprise architecture tool

Unicom System Architect is an enterprise architecture tool that is used by the business and technology departments of corporations and government agencies to model their business operations and the systems, applications, and databases that support them. System Architect is used to build architectures using various frameworks including TOGAF, ArchiMate, DoDAF, MODAF, NAF and standard method notations such as sysML, UML, BPMN, and relational data modeling. System Architect is developed by UNICOM Systems, a division of UNICOM Global, a United States-based company.

Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

<span class="mw-page-title-main">Enterprise modelling</span>

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

<span class="mw-page-title-main">Structured analysis</span>

In software engineering, structured analysis (SA) and structured design (SD) are methods for analyzing business requirements and developing specifications for converting practices into computer programs, hardware configurations, and related manual procedures.

<span class="mw-page-title-main">Misuse case</span>

Misuse case is a business process modeling tool used in the software development industry. The term Misuse Case or mis-use case is derived from and is the inverse of use case. The term was first used in the 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway. It describes the process of executing a malicious act against a system, while use case can be used to describe any action taken by the system.

<span class="mw-page-title-main">ArchiMate</span> Enterprise architecture modeling language

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

<span class="mw-page-title-main">Function model</span>

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions within the modeled system or subject area.

<span class="mw-page-title-main">Semantic data model</span> Database model

Semantic data model (SDM) is a high-level semantics-based database description and structuring formalism (database model) for databases. This database model is designed to capture more of the meaning of an application environment than is possible with contemporary database models. An SDM specification describes a database in terms of the kinds of entities that exist in the application environment, the classifications and groupings of those entities, and the structural interconnections among them. SDM provides a collection of high-level modeling primitives to capture the semantics of an application environment. By accommodating derived information in a database structural specification, SDM allows the same information to be viewed in several ways; this makes it possible to directly accommodate the variety of needs and processing requirements typically present in database applications. The design of the present SDM is based on our experience in using a preliminary version of it. SDM is designed to enhance the effectiveness and usability of database systems. An SDM database description can serve as a formal specification and documentation tool for a database; it can provide a basis for supporting a variety of powerful user interface facilities, it can serve as a conceptual database model in the database design process; and, it can be used as the database model for a new kind of database management system.

<span class="mw-page-title-main">IDEF4</span>

IDEF4, or Integrated DEFinition for Object-Oriented Design, is an object-oriented design modeling language for the design of component-based client/server systems. It has been designed to support smooth transition from the application domain and requirements analysis models to the design and to actual source code generation. It specifies design objects with sufficient detail to enable source code generation.

References

  1. NDE Project Management Archived 7 November 2008 at the Wayback Machine (NPOESS) Data Exploitation web site. 2008.
  2. Manoj Kumar Choubey (2012) IT Infrastructure and Management (For the GBTU and MMTU). p. 53
  3. Alexander Kossiakoff, William N. Sweet (2011). Systems Engineering: Principles and Practices p. 266
  4. Richard Wiener (1998) Journal of Object-oriented Programming. Vol 11. p. 68
  5. Suzanne Robertson, James C. Robertson (2006) Mastering the Requirements Process. Pearson Education, 17 mrt. 2006
  6. System Goal Modelling using the i*: Approach in RESCUE Centre HCI Design, 27 February 2003
  7. 1 2 3 US Department of Transportation, Office of Operations (2006)Regional ITS Architecture Guidance Document. July 2006
  8. Graeme C. Simsion, Graham C. Witt (2005). Data Modeling Essentials. p. 512.