Use of MODAF
User requirements analysis with MODAF
This article does not attempt an exhaustive description of the way in which MODAF supports user requirements definition and analysis within MOD. That subject is described in detail within the Interoperability for Communication and Information Services section in the Acquisition Operating Framework. A companion article addresses MODAF support to system requirements definition.
What this article does do is describe how the MODAF concepts support the key principles of requirements definition for defence systems.
At the higher end of the spectrum (e.g. capabilities and systems of systems), the strategic views provide the platform for establishing the capability needs. It is important to recognise that, in a managed enterprise, the capability needs will change over time. These changes are captured in the StV-3 view. At a given point in time within the enterprise timeline, the capability needs – as represented in a column within a StV-3 view – can be expressed in terms of the level of capability performance required. The OV-1c tabular view can be used to capture these levels of capability as they evolve over time.
The models within the Operational Viewpoint then reflect the capability needs at a given point in the enterprise timeline. They refine the needs expressed at the strategic level in three complementary ways:
- the functional needs can be represented in terms of a model of the business process (which will focus on the OV-5 activity diagrams)
- nodes (captured in the OV-2 view) provide a focus for the operational requirements which can cover both functional and non-functional aspects
- behavioural models (addressed using the OV-6 views) provide a focus for operational requirements covering operational behaviour (e.g the need for the capability to respond in a particular manner to specific events).
As an example, there may be distinct nodes modelled that represent the air and ground segment of a capability that is known to have a significant airborne component. The air segment node will be the focus for non-functional requirements that will express the mobility and survivability needs of this segment (among others) that will be quite distinct from those associated with the ground segment. This use of models (to reflect the principal operational concepts) is not solutioneering because having an airborne component may be a fundamental element of the capability need.
One important way that architectural modelling supports requirements definition is in terms of 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. MODAF now provides support to the concept of a ‘ProblemDomain’ that provides a bounding shape on an OV-2 operational node relationships view. The use of this is envisaged to be that those aspects of the capability that are not subject to change during the acquisition programme are left outside the boundary. These need to be modelled, of course, so that the boundary interoperability requirements can be captured.
Definition of user-level interoperability requirements is another subject for which there is guidance through the Acquisition Management System. Within the Operational Viewpoint, MODAF supports interoperability analysis in a number of ways:
- OV-3 enables information exchange requirements (linked to the needlines between nodes shown on the OV-2) to be tabulated
- OV-2 enables capture of node-to-node interactions that are based on exchange of energy or materiel, not just information
- OV-2, OV-3, OV-5 and OV-7 form a linked set of views that support a coherent model of operational information and boundary-crossing exchanges; when behavioural models are included this set can be extended to include OV-6c.
The functional boundary can also be described in terms of the activities within the OV-5 activity model that the capability of interest will enhance support for.
Another aspect of requirements definition is the construction of test scenarios. The OV-6 behavioural models provide opportunities here for the development of test scenarios that are linked in with the operational models that support the user requirements. Such models both reflect operational requirements (the capability must do X once event E happens) and provide tests of it.
Use of MODAF in this way should improve the quality of requirements definitions by:
- explicitly tying user requirements to strategic level capability needs
- enabling early agreement to be reached on the capability boundary
- providing a validated ‘reference’ model of the business against which the completeness of a requirements defiintion can be assessed (visualisation aids validation)
- ensuring that functional requirements are clearly linked to a validated model of the business processes
- ensuring that the information-related requirements (not just IERs) are captured in a coherent manner and in a way that really reflects the user collaboration needs
- providing test scenarios linked to the user requirements.
Associating an architectural model with a requirements definition also has several benefits:
- it is often easier to gauge the most appropriate level of abstraction in an architectural model (because it tends to be easier to identify when modelling decisions are solutioneering) than is the case with text-based requirements
- the models can then provide a means of testing the completeness of the requirements set.
Page version 1.1, dated 4th April 2007