N2 chart

Last updated
N chart example. N2 chart example.jpg
N chart example.

The N2 chart or N2 diagram (pronounced "en-two" or "en-squared") is a chart or diagram in the shape of a matrix, representing functional or physical interfaces between system elements. It is used to systematically identify, define, tabulate, design, and analyze functional and physical interfaces. It applies to system interfaces and hardware and/or software interfaces. [2]

Contents

The N-squared chart was invented by the systems engineer Robert J. Lano, while working at TRW in the 1970s and first published in a 1977 TRW internal report. [3]

Overview

The N2 diagram has been used extensively to develop data interfaces, primarily in the software areas. However, it can also be used to develop hardware interfaces. The basic N2 chart is shown in Figure 2. The system functions are placed on the diagonal; the remainder of the squares in the N × N matrix represent the interface inputs and outputs. [4]

Figure 2. N2 chart definition. N2 chart definition.JPG
Figure 2. N2 chart definition.
Figure 3. N2 Chart Key Features. N2 Chart Key Features.jpg
Figure 3. N2 Chart Key Features.

Where a blank appears, there is no interface between the respective functions. Data flows in a clockwise direction between functions (e.g., the symbol F1 → F2 indicates data flowing from function F1, to function F2). The data being transmitted can be defined in the appropriate squares. Alternatively, the use of circles and numbers permits a separate listing of the data interfaces. The clockwise flow of data between functions that have a feedback loop can be illustrated by a larger circle called a control loop. The identification of a critical function is also shown in Figure 3, where function F4 has a number of inputs and outputs to all other functions in the upper module. A simple flow of interface data exists between the upper and lower modules at functions F7 and F8. The lower module has complex interaction among its functions. The N2 chart can be taken down into successively lower levels to the hardware and software component functional levels. In addition to defining the data that must be supplied across the interface, the N2 chart can pinpoint areas where conflicts could arise. [4]

N2 charts building blocks

Number of entities

The "N" in an N2 diagram is the number of entities for which relationships are shown. This N × N matrix requires the user to generate complete definitions of all interfaces in a rigid bidirectional, fixed framework. The user places the functional or physical entities on the diagonal axis and the interface inputs and outputs in the remainder of the diagram squares. A blank square indicates that there is no interface between the respective entities. Data flows clockwise between entities (i.e., the symbol F1 → F2, in Figure 4, indicates data flowing from function F1 to function F2; the symbol F2 → F1 indicates the feedback). That which passes across the interface is defined in the appropriate squares.

The diagram is complete when the user has compared each entity to all other entities. The N2 diagram should be used in each successively lower level of entity decomposition. Figure 1 illustrates directional flow of interfaces between entities within an N2 diagram. (In this case, the entities are functions.)

Functions on the diagonal

Figure 4. N diagram. 10 N2 Diagram.jpg
Figure 4. N diagram.

In the example on the right, N equals 5. The five functions are on the diagonal. The arrows show the flow of data between functions. So if function 1 sends data to function 2, the data elements would be placed in the box to the right of function 1. If function 1 does not send data to any of the other functions, the rest of the boxes to right of function 1 would be empty. If function 2 sends data to function 3 and function 5, then the data elements would be placed in the first and third boxes to the right of function 2. If any function sends data back to a previous function, then the associated box to the left of the function would have the data elements placed in it. The squares on either side of the diagonal (not just adjacent squares) are filled in with appropriate data to depict the flow between the functions. If there is no interface between two functions, the square that represents the interface between the two functions is left blank. Physical interfaces would be handled in the same manner, with the physical entities on the diagonal rather than the functional entities.

Contextual and administrative data

Each N2 diagram shall contain at a minimum the following contextual and administrative data:

N2 diagrams are a valuable tool for not only identifying functional or physical interfaces, but also for pinpointing areas in which conflicts may arise with interfaces so that system integration proceeds smoothly and efficiently.

Figure 5. N diagram building blocks. 11 N2 Diagram Illustration.jpg
Figure 5. N diagram building blocks.

Figure 5 presents information in an N2 diagram, which complements the Functional flow block diagram. Notice that in this illustration, there are no data elements or triggers. The figure illustrates the context between functions at different levels of the model.

Examples

Figure 6 is an example of the diagram's appearance when cells are populated with data. [5]

System Engineering Functional N2 Diagram.jpg

See also

Related Research Articles

<span class="mw-page-title-main">Computer program</span> Instructions to be executed by a computer

A computer program is a sequence or set of instructions in a programming language for a computer to execute. It is one component of software, which also includes documentation and other intangible components.

In software engineering, multitier architecture is a client–server architecture in which presentation, application processing and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.

<span class="mw-page-title-main">Programmable logic controller</span> Programmable digital computer used to control machinery

A programmable logic controller (PLC) or programmable controller is an industrial computer that has been ruggedized and adapted for the control of manufacturing processes, such as assembly lines, machines, robotic devices, or any activity that requires high reliability, ease of programming, and process fault diagnosis.

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

Structured systems analysis and design method (SSADM) is a systems approach to the analysis and design of information systems. SSADM was produced for the Central Computer and Telecommunications Agency, a UK government office concerned with the use of technology in government, from 1980 onwards.

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

In computing and systems design, a loosely coupled system is one

  1. in which components are weakly associated with each other, and thus changes in one component least affect existence or performance of another component.
  2. in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.
<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.

The term conceptual model refers to any model that is formed after a conceptualization or generalization process. Conceptual models are often abstractions of things in the real world, whether physical or social. Semantic studies are relevant to various stages of concept formation. Semantics is fundamentally a study of concepts, the meaning that thinking beings give to various elements of their experience.

<span class="mw-page-title-main">Design structure matrix</span>

The design structure matrix (DSM; also referred to as dependency structure matrix, dependency structure method, dependency source matrix, problem solving matrix (PSM), incidence matrix, N2 matrix, interaction matrix, dependency map or design precedence matrix) is a simple, compact and visual representation of a system or project in the form of a square matrix.

Glossary of Unified Modeling Language (UML) terms provides a compilation of terminology used in all versions of UML, along with their definitions. Any notable distinctions that may exist between versions are noted with the individual entry it applies to.

Object-oriented design (OOD) is the process of planning a system of interacting objects to solve a software problem. It is a method for software design. By defining classes and their functionality for their children, each object can run the same implementation of the class with its state.

<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">V-model (software development)</span> Software development methodology

In software development, the V-model represents a development process that may be considered an extension of the waterfall model and is an example of the more general V-model. Instead of moving down linearly, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.

<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">Functional flow block diagram</span> Flow Diagram

A functional flow block diagram (FFBD) is a multi-tier, time-sequenced, step-by-step flow diagram of a system's functional flow. The term "functional" in this context is different from its use in functional programming or in mathematics, where pairing "functional" with "flow" would be ambiguous. Here, "functional flow" pertains to the sequencing of operations, with "flow" arrows expressing dependence on the success of prior operations. FFBDs may also express input and output data dependencies between functional blocks, as shown in figures below, but FFBDs primarily focus on sequencing.

<span class="mw-page-title-main">Structure chart</span> Chart

A structure chart (SC) in software engineering and organizational theory is a chart which shows the breakdown of a system to its lowest manageable levels. They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module's name. The tree structure visualizes the relationships between modules.

In feature-oriented software development, feature-oriented software development program cubes (FOSD program cubes) are n-dimensional arrays of functions (program transformations) that represent n-dimensional product lines. A program is a composition of features: a base program is augmented with increments in program functionality, called features, to produce a complex program. A software product line (SPL) is a family of related programs. A typical product line has F0 as a base program, and F1..Fn as features that could be added to F0. Different compositions of features yield different programs. Let + denote the feature composition operation. A program P in SPL might have the following expression:

<span class="mw-page-title-main">Simantics System Dynamics</span>

Simantics System Dynamics is a ready-to-use system dynamics modelling and simulation software application for understanding different organizations, markets, and other complex systems and their dynamic behavior.

References

  1. John Azzolini (2000). Introduction to Systems Engineering Practices. July 2000.
  2. The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION Archived 2009-01-14 at the Wayback Machine 4.4 VERSION 3.1 06/06/06.
  3. Lano, R. (1977). The N2 Chart. TRW Software Series, Redondo Beach, CA.
  4. 1 2 3 4 NASA (1995). "Techniques of Functional Analysis". In: NASA Systems Engineering Handbook Archived 2008-12-17 at the Wayback Machine June 1995. p.142.
  5. Federal Aviation Administration (2006). System Engineering Functional N2 Diagram