System Views (SV) [Physical, Specification or Solution Views]
SV-4 Functionality Description v1.2
Functionality Descriptions (SV-4) address human and system functionality.
Background:
The primary purposes of SV-4 are to:
- develop a clear description of the necessary data flows that are input (consumed) by and output (produced) by each resource
- ensure that the functional connectivity is complete (i.e. that a resource’s required inputs are all satisfied)
- ensure that the functional decomposition reaches an appropriate level of detail.
The Functionality Description provides detailed information regarding the:
- allocation of functions to resources
- flow of data between functions
The SV-4 is the systems view counterpart to the Activity Model (OV-5) of the operational view.
Usage:
- Description of task workflow
- Identification of functional system requirements
- Functional decomposition of systems
- Relate human and system functions
Data objects:
The data in an SV-4 can include:
- Function
- Resource
- Data Element
Relationships Between Key Data Objects (Simplified from M3)
Representation:
- Topological (Connected Shapes)
- UML Activity Diagram
- UML Activity Diagram (with swimlanes)
- Class / Block Definition Diagram
- Composite Structure / Internal Block Diagram
- SysML Activity Diagram
Detailed Product Description:
The Functionality Description (SV-4) is used to specify the functionality of resources in the architecture. SV-4 is the behavioural counterpart to the SV-1 (in the same way that OV-5 is the behavioural counterpart to OV-2).
The scope of this View may be capability wide, without regard to which resources perform which functions, or it may be resource-specific. Variations may focus on intra- or inter-resource data flows, or may simply allocate functions to resources.
There are two basic ways to depict SV-4:
- The Functional Hierarchy shows a decomposition of functions depicted in a tree structure and is typically used where tasks are concurrent but dependent, such as a production line, for example.
- The Data Flow Diagram shows functions connected by data flow arrows and data stores.
The Functional Hierarchy may be particularly useful in capability-based procurement where it is necessary to model the functions that are associated with particular capability configurations (see SV-1).
SV-4 Hierarchy Schematic
SV-4 Hierarchy Schematic with System Context
Within a system architecture, SV-4 flow diagrams document system functions, the flows of system data between those functions, the internal system data repositories or system data stores, and the external sources and sinks for the system data flows. They may also show how users (depicted as Roles) behave in relation to those systems.
SV-4 Data Flow Schematic
The functions are likely to be related to Operational Activities captured in OV-5. Although there is a correlation between the Operational Activity Model (OV-5) and the functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Function to Operational Activity Traceability Matrix (SV-5), which provides that mapping.
External sources and sinks may be used to represent data sources external to the diagram scope but not external to the Architecture scope (i.e. off-page connectors).
Functions of systems are not limited to internal system functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions that consume or produce system data from/to system functions that belong to external systems. The external system data sources and/or sinks can be used to represent the human that interacts with the system or external systems. The system data flows between the external system data source/sink (representing the human or system) and the HCI, GUI, or interface function can be used to represent human-system interactions, or system-system interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified during development of this View (and recorded in TV-1).
A graphical variant of the SV-4 data flow view may be used with ‘swimlanes’. A system swimlane may be associated with a resource, for example a System, a Capability Configuration (usually based on a Physical Asset) or a Role.
Swimlanes are presented either vertically or horizontally. A function is placed in the swimlane associated with the Resource that it is allocated to in the solution architecture. This provides a graphical means of presenting the interactions between Systems or Capability Configurations (shown through system connections on SV-1) in functional terms. This is a powerful technique for visualising the differences between alternative solution options (which may have a common set of functions).
Example SV-4 Function Description (Swimlanes) (Source: IPT Deskbook)
Version 1.1 of MODAF has also introduced the relationship ‘functions upon’ between Functions and Data Elements. This makes it easier to associate the subject of a function when modelling a data-centric system.
In addition, Function Provision now allows multiple resources to expose the same functionality. In effect this means that resource structures can be modelled (through SV-1) independently from functional structures (through SV-4) and then mapped together. Different solution options may indeed have different mappings between resources and functions.
Page version 1.2, dated 1stJuly 2008