System Views (SV) [Physical, Specification or Solution Views]
SV-5 Function to Operational Activity/Service Function Traceability Matrix v1.2

Version 1.2.001 ammendment
This view has been expanded for the Service Orientated community by allowing for Service Functions as well as Operational Activities.
The Function to Operational Activity/Service Function Traceability Matrix (SV-5) provides two alternate views; it addresses the linkage between functions described in SV-4 and Operational Activities specified in OV-5, or the functions in SV-4 and the Service Functions in SOV-5. In DODAF v1.5, these two views were called SV-5a and b. The MODAF view is that operational activities and system functions are releted concepts and as long as they are suitably labelled in the SV-5 then there is no need for separate views.
Background:
The SV-5 View depicts the mapping of functions (and, optionally, the resources that provide them) to operational activities or service functions. For operational activities it thus identifies the transformation of an operational need into a purposeful action performed by a system or solution. For service functions it provides the link between the services used at the operational level and the specific functions provided by the resources supporting the services.
During requirements definition, SV-5 plays a particularly important role in tracing the architectural elements associated with system requirements to those associated with user requirements.
Usage:
- Tracing functional system requirements to user requirements
- Tracing solution options to requirements
- Identification of overlaps
Data objects:
The data in an SV-5 can include:
- Function
- Resource
- Operational Activity
- Service function

Relationships Between Key Data Objects (Simplified from M3)
Representation:
- Tabulation
![]()
Detailed Product Description:
A Function to Operational Activity/System Function Traceability Matrix is a specification of the relationships between the set of operational activities/system functions applicable to an Architecture and the set of functions applicable to that Architecture.
The relationship between functions and operational activities/system functions can also be expected to be many-to-many (i.e. one activity/system function may be supported by multiple functions, and one function may support multiple activities/system functions).
The SV-5 View is normally a tabular view of the relationship between functions and activities/system functions in the form of a simple matrix.

Example SV-5
The Framework uses the term Operational Activity in the OVs and the term Function in the SVs to refer to essentially the same kind of thing—both activities and functions are tasks that are performed, accept inputs, and develop outputs. The distinction between an Operational Activity and a Function is a question of “what” and “how”. The Operational Activity is a specification of what is to be done, regardless of the mechanism used. A function specifies how a resource carries it out. For this reason, SV-5 is a signficant view, as it ties together the logical specification in the OV-5 with the physical specification of the SV-4. This logic can also be applied to services, where the service functions are a specification of what is to be done.
The use of SV-5 to support requirements traceability is illustrated below.

Example SV-5 (requirements) (Source: DCSA)
As discussed the functions shown in the SV-5 may be those associated with capability configurations. More focused SV-5 View Products might be used to specifically trace system functions to operational activities/service functions if desired.
A richer version of the tabular SV-5 view allows the implementation status of each function to be shown. In this variant view each function-to-activity mapping is described by a ‘traffic light’ symbol that may indicate the status of the system support. These symbols are usually coloured circles with:
- a Red colour indicating that the functionality is planned but not developed
- a Yellow colour indicating that partial functionality has been provided (or full functionality provided but system has not been fielded)
- a Green colour indicating that full functionality has been provided to the field
- a blank cell indicates that there is no system support planned for an Operational Activity, or that a relationship does not exist between the Operational Activity and the system function.

Example SV-5 (showing implementation status)
Care should be taken when publishing an SV-5 with status information. Any product should clearly state the date of publication, so that users can see when status information is old.
SV-5 may be further adorned with the Resources (e.g. systems, roles & capability configurations) that conduct the functions. The architect may also wish to hide the functions in an SV-5 so that the table simply shows the mapping from Resources to Operational Activities/Service Functions:

Variant SV-5 (systems mapped to operational activities)
Another form of Hybrid SV-5 may be produced which shows Capabilities instead of Operational Activities/Service Functions. This information is derivable only when Operational Activities/Service Functions are conducted by Nodes that are traced back to Capabilities (see OV-2).
Page version 1.2.001, dated 5th August 2008