Use of MODAF
System requirements analysis with MODAF
This article does not attempt an exhaustive description of the way in which MODAF supports system requirements definition and analysis within MOD. Many of the observations contained in the article on user requirements analysis also apply to system requirements definition.
The Acquisition Operating Framework (AOF) should be consulted for full details of system requirements definition in the MoD.
Models in the System Viewpoint represent alternate realisations in terms of equipment capability of the operational capabilities expressed through models in the Operational Viewpoint and in the User Requirements.
In MODAF, the System Viewpoint primarily addresses the specification of the system capability needed (rather than implementation details). Having said that, recent changes have improved the ability for MODAF modellers to represent configuration of capability that include people as well as systems and platforms. See the article on Defence Lines of Development. This article will focus on equipment specification.
System specification models refine the expression of needs at the operational level in the following three ways:
- the functional needs can be represented in terms of a model of the system functionality (which will focus on the SV-4 functional flow diagrams)
- the structural requirements may be represented using the SV-1 view
- the performance and behavioural requirements may be represented using behavioural models (captured in the SV-10 suite of views).
Maintaining a trace to the models reflecting the user requirements is essential. The key mechanisms for achieving this within MODAF are:
- SV-5 which maps functions in the System Viewpoint to activities in the Operational Viewpoint (for functional traceability)
- SV-1 which maps capability configurations in the System Viewpoint to nodes in the Operational Viewpoint (for structural traceability).
One important way that architectural modelling supports system specification is in terms of system boundary definition. Boundary definition is a process that often requires a significant degree of stakeholder engagement; the standardised views provided by MODAF provide ideal support for this interactive process. The system boundary can be represented using overlays on views such as SV-1 (structural boundary) and SV-4 (functional boundary). More detail can be provided of the boundary in views such as SV-2 (interface specification), SV-3 (system-to-system mapping) and SV-6 (system data exchange requirements).
Definition of system-level interface requirements is another subject for which there is guidance through the Acquisition Management System. Within the System Viewpoint, MODAF supports interface analysis in a number of ways:
- the SV-2 views can add detail to the structural specification (SV-1) in regard to interface specification; specifically, details of the required protocols can be captured
- SV-1, SV-4, SV-6 and SV-11 form a linked set of views that support a coherent model of system data and boundary-crossing exchanges; when system behavioural models are included this set can be extended to include SV-10c.
In respect of these interface requirements, the linkage between SV-6 and OV-3 provides a further degree of traceability to the operational models that provide capability context to the system requirements.
System specification is not just a top-down process of decomposing the relevant parts of the required operational capability. Particularly in the context of NEC, there will be constraints and legacy capabilities that will influence the specification. MODAF helps to address this by using models of legacy capability to specify where the system boundary should lie and what the data and services are that cross the boundary.
Another aspect of system specification is the construction of test scenarios. The SV-10 behavioural models provide opportunities here for the development of test scenarios that are linked in with the system models that express system behaviour.
Use of MODAF in this way should improve the quality of system specifications by:
- explicitly tying system requirements to the (models of) user requirements which provide context for those specifications
- enabling early agreement to be reached on the system boundary
- understanding the specification implications of constraints and legacy capability
- ensuring that the information-related requirements are captured in a coherent manner
- providing test scenarios linked to the system requirements.
In addition to these benefits, the specification models may support stakeholder engagement in respect of system trade-offs.
Page version 1.1, dated 4th April 2007