The SvcV-5 “Operational Activity to Services Traceability Matrix” addresses the linkage between service functions described in SvcV-4 “Service Functionality DEscription” and Operational Activities specified in OV-5a “Operational Activity Decomposition Tree” or OV-5b “Operational Activity Model”. The SvcV-5 depicts the mapping of service functions (and, optionally, the capabilities and performers that provide them) to operational activities and thus identifies the transformation of an operational need into a purposeful action performed by a service solution. 
During requirements definition, the SvcV-5 plays a particularly important role in tracing the architectural elements associated with system function requirements to those associated with user requirements.
The intended usage of the SvcV-5 includes: 
- Tracing service functional requirements to user requirements
- Tracing solution options to requirements
- Identification of overlaps or gaps
An SvcV-5 is a specification of the relationships between the set of operational activities applicable to an Architectural Description and the set of service functions applicable to that Architectural Description. The relationship between operational activities and service functions can also be expected to be many-to-many (i.e., one activity may be supported by multiple functions, and one function may support multiple activities). The service functions shown in the SvcV-5 may be those associated with capabilities and performers. More focused SvcV-5 models might be used to specifically trace system functions to operational activities if desired. 
DoDAF uses the term Operational Activity in the OVs and the term Service Function in the SVs to refer to essentially the same kind of thing-both activities and service functions are tasks that are performed, accept inputs, and develop outputs. The distinction between an Operational Activity and a Service 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 Service Function specifies how a resource carries it out. For this reason, the SvcV-5 is a significant model, as it ties together the logical specification in the OV-5a Operational Activity Decomposition Tree or OV-5b Operational Activity Model with the physical specification of the SvcV-4 Services Functionality Description. Service Functions can be carried out by Resources. 
The SvcV-5 is generally presented as a matrix of the relationship between service functions and activities. The SvcV-5 can show requirements traceability with Operational Activities on one axis of a matrix, the System Functions on the other axis, and with an X, date, or phase in the intersecting cells, where appropriate. An alternate version of the tabular SvcV-5 can allow the implementation status of each function to be shown. In this variant model, each service function-to-operational activity mapping is described by a traffic light symbol that may indicate the status of the service support. DoDAF V2.0 does not prescribe a presentation technique. These symbols are usually colored circles with the following possible representations: 
- Red may indicate that the functionality is planned but not developed
- Yellow may indicate that partial functionality has been provided (or full functionality provided but system has not been fielded)
- Green may indicate that full functionality has been provided to the field
- A blank cell may indicate that there is no service support planned for an Operational
- Activity, or that a relationship does not exist between the Operational Activity and the Service Function
|DoDAF Viewpoint Matrix|
- The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
- DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.
AcqLinks and References:
-  DoDAF Architecture Framework Version 2.02
- DoD Architecture Framework Working Group Version 1.0, Volume 1: Definition and Guideline, 9 Feb 04 (Old Version)
- DoD Architecture Framework Version 1.0, Volume 2: Product Description, 9 Feb 04 (Old Version)
- Website: DoDAF Architecture Framework – DoD Deputy Chief Information Officer
- Website: DoDAF Version 2.02 Journal