MOD Architectural Framework Acquisition Community of ... Acquisition Deskbook v0.9.pdf · MOD Architectural Framework Acquisition Community of Interest ... 3.3.2 Systems Engineering

- 1 -

MODAF-M10-004

MINISTRY OF DEFENCE

MOD Architectural Framework

Acquisition Community of Interest Deskbook

Version 0.9

29 July 2005

Prepared by:-

Approved by:-

CROWN COPYRIGHT 2005.

THIS DOCUMENT IS THE PROPERTY OF HER BRITANNIC MAJESTY’S GOVERNMENT. This material (other than the Royal Arms and departmental or agency logos) may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where this material is being republished or copied to others, the source of the material must be identified and the copyright status acknowledged.

For further information on Crown Copyright policy and licensing arrangements, see the guidance featured on the HMSO website http://www.opsi.gov.uk

- 2 -

RECORD OF CHANGES

This page will be updated and re-issued with each amendment. It provides an authorisation for the amendment and a checklist to the current amendment number.

Issue No. Date Revision Details

Draft 0.1 11 April 2005 First Draft

Draft 0.2 15 June 2005 Incorporation of comments from MODAF Partners team and Acquisition Community of Interest (COI) initial workshop

Draft 0.3 17 June 2005 Incorporation of comments from PDG Standardisation Group and draft Architectural Process

Draft 0.4 8 July 2005 Incorporation of comments from Acquisition COI follow-up workshop and individual reviews, introductory section re-structured, re-formatted and document structure changed by workstream rather than CADMID stage

Version 0.9 29 July 2005 Initial publication, updated with Review comments, and Review Board decisions

- 3 -

Acquisition MODAF Deskbook - Table of Contents

1. Foreword........................................................................................................... 5

2. Introduction ...................................................................................................... 6 2.1 What is MODAF? ........................................................................................ 6 2.2 Guide to Deskbook...................................................................................... 7

2.2.1 Purpose ............................................................................................... 7 2.2.2 Context ................................................................................................ 7 2.2.3 Deskbook Structure.............................................................................. 9

3. MODAF Relationship to Acquisition Business Processes and Activities.. 10 3.1 Architecture Development Process ........................................................... 10

3.1.1 Six-Stage Architecture Development Process.................................... 10 3.1.2 Architectural Data Sources................................................................. 11 3.1.3 Application to Acquisition Process...................................................... 12 3.1.4 Overview of MODAF View use........................................................... 12 3.1.5 Ensuring Views are MODAF compliant - hybrid and modified Views .. 13

3.2 Acquisition Process................................................................................... 13 3.3 Project Management ................................................................................. 15

3.3.1 Form the IPT...................................................................................... 17 3.3.2 Systems Engineering Management Plan............................................ 18 3.3.3 Initial Gate.......................................................................................... 18 3.3.4 Manage dependency risks ................................................................. 19 3.3.5 Main Gate .......................................................................................... 20 3.3.6 Place contract(s) to meet the SRD..................................................... 20 3.3.7 Wind down of IPT............................................................................... 21

3.4 Requirements Management ...................................................................... 22 3.4.1 User Requirements Document (URD) ................................................ 24 3.4.2 Linkage between User and System Requirements............................. 24 3.4.3 System Requirements Document (SRD) ............................................ 25 3.4.4 Integrated Testing, Evaluation and Acceptance ................................. 30

3.5 Systems / Technology............................................................................... 32 3.5.1 Identify technology and procurement options ..................................... 34 3.5.2 Demonstrate ability to deliver integrated capability............................. 36 3.5.3 Technology insertion .......................................................................... 36

3.6 Industry / Suppliers ................................................................................... 37 3.6.1 Involve Industry.................................................................................. 39 3.6.2 System Synthesis .............................................................................. 40 3.6.3 Negotiate contract .............................................................................. 40 3.6.4 Deliver the solution............................................................................. 41 3.6.5 Carry out any agreed upgrades or improvements .............................. 41

3.7 Through-Life Management ........................................................................ 42 3.7.1 TLMP ................................................................................................. 44 3.7.2 Integrated Logistic Support ................................................................ 45

4. Worked Example ............................................................................................ 46 4.1 ISTAR Worked Example Introduction........................................................ 46 4.2 Project Management ................................................................................. 46

4.2.1 Form the IPT...................................................................................... 46 4.2.2 Systems Engineering Management Plan............................................ 47 4.2.3 Initial Gate.......................................................................................... 48

- 4 -

4.2.4 Manage Dependency Risks ............................................................... 48 4.2.5 Main Gate .......................................................................................... 51 4.2.6 Place contract(s) to meet the SRD..................................................... 51 4.2.7 Wind down of IPT............................................................................... 51

4.3 Requirements Management ...................................................................... 51 4.3.1 Develop and Maintain User Requirements Document (URD) ............. 51 4.3.2 Linkage between User and System Requirements............................. 56 4.3.3 Develop and Maintain System Requirements Document (SRD)......... 57 4.3.4 Integrated Testing, Evaluation and Acceptance ................................. 63

4.4 Systems / Technology............................................................................... 64 4.4.1 Identify technology and procurement options ..................................... 64 4.4.2 Demonstrate ability to deliver integrated capability............................. 66 4.4.3 Technology Insertion.......................................................................... 66

4.5 Industry / Suppliers ................................................................................... 66 4.5.1 Involve Industry.................................................................................. 66 4.5.2 System Synthesis .............................................................................. 67 4.5.3 Negotiate Contract ............................................................................. 67 4.5.4 Deliver the solution............................................................................. 67 4.5.5 Carry out any agreed upgrades or improvements .............................. 67

4.6 Through-Life Management ........................................................................ 68 4.6.1 TLMP ................................................................................................. 68 4.6.2 Integrated Logistic Support ................................................................ 68

4.7 UML Example ........................................................................................... 68

5. Document Maintenance ................................................................................. 73

Appendix A: Large-Scale Diagrams..................................................................... 74

- 5 -

1. Foreword

(Generic foreword - championing the use of MODAF, covering mandation issues and policy, emphasis of the benefits of MODAF and an architectural approach – to be written by MOD)

- 6 -

2. Introduction

2.1 What is MODAF?

The MOD Architecture Framework (MODAF) is a framework for conducting Enterprise Architecture activities and provides a means to model, understand, analyse and specify Capabilities, Systems, Systems of Systems (SoS) and Business Processes. This provides a framework within which to integrate the elements needed to deliver a Capability. MODAF consists of the six Viewpoints that are shown in Figure 2-1.

Figure 2-1: MODAF Viewpoints

MODAF uses six Viewpoints, each consisting of a number of modelling Views, to cover the complexity of MOD activities as shown in Figure 2-1. Not all MODAF Viewpoints and Views are needed for every architecture and it is intended that users select appropriate ones in order to most effectively represent their area of interest.

MODAF may be applied across a wide variety of MOD processes, including Capability Management, Acquisition, Operational Analysis, Planning and Through-life Management. Applied appropriately MODAF should be an enabler to the successful delivery of Network Enabled Capability (NEC)1. Amongst the benefits of MODAF within the Acquisition processes are:

• Improved clarity of the context within which a new capability will operate

• Clearer and more comprehensive requirements documents

• Improved ability to resolve interoperability issues between systems

1 CM(IS) NEC Next Steps paper of April 2003

SystemsViewpoint

Articulates system composition and interconnectivity to support system

analysis, and through-life management

Acquisition Viewpoint

Articulates acquisition programme construct, timelines and DLOD status to

inform planning

All Views

Provides pertinent summary information that specifies the architecture product

Strategic Viewpoint

Articulates the long-term strategic picture to support capability management and

equipment planning

TechnicalViewpoint

Articulates policy, standards, guidance & constraints to specify and assure quality

expectations

Operational Viewpoint

Articulates the operational picture to support operational analysis, user requirements

definition, and solution acceptance

- 7 -

• Better understanding of the mapping of system functions to operational needs and hence the ability to conduct improved trade-offs.

2.2 Guide to Deskbook

2.2.1 Purpose

The purpose of this document is to explain to the Acquisition community how to produce MODAF compliant architectures and how the Views within these architectures will support the various elements of the Acquisition lifecycle and processes. It also explains where specialist support and expertise on the use of architectures can be obtained.

2.2.2 Context

The Acquisition Deskbook forms part of the overall suite of MODAF 1.0 baseline documentation as shown in Figure 2-2.

Figure 2-2: MODAF 1.0 Baseline Products

The main elements of the MODAF baseline are:

• Executive Summary – provides a brief summary of the entire MODAF baseline (MODAF-M09-001)

• MODAF Overview – describes what MODAF is, why it should be used and details the process for developing architectures (MODAF-M09-002)

TaxonomyTaxonomy

Meta ModelMeta Model

MODAF Acronyms ListMODAF Acronyms List

COI COI DeskboDeskbo

okok


okok

AcquisitionAcquisitionDeskbookDeskbook


okok


okok

MODAFMODAFCOICOI

DeskbookDeskbook

MODAFMODAF

Technical Technical HandbookHandbook

MODAFMODAF

OverviewOverview

MODAF Executive SummaryMODAF Executive Summary

ViewViewOverviewOverview


MODAF Glossary of TermsMODAF Glossary of Terms

- 8 -

• MODAF Technical Handbook – provides details of the construction of MODAF Views and their relationship to the MODAF meta model (M3) (MODAF- M07-022). This is supported by:

− View Overview – a short summary of each View intended for quick reference by MOD users (MODAF-M07-017)

− Meta Model – used to define the architectural objects that are permitted in MODAF Views and their relationships with each other

− Taxonomy – provides the approved names and definitions for architectural objects to be used within the MOD’s architectures

• MODAF Deskbooks – describe how users within particular communities in the MOD are expected to utilise MODAF architectures to support their processes. Each of the Deskbooks has one or more “quick start guides” that provide an easy reference summary of the relationship of MODAF Views to the community’s processes

For the purpose of describing the relationship of MODAF to MOD’s processes, five Communities of Interest (COIs) have been considered as shown in Figure 2-3 below. Whilst these do not describe the whole of the MOD’s processes2, they do cover the core processes around acquisition and military operations.

Figure 2-3: Community of Interest Deskbook Scope

The high level scope of these COIs is:

• Concepts and Doctrine – the development of analytical concepts (eg Joint HLOC), applied concepts (eg Carrier Strike Concepts) and in-service doctrine, Standard Operating Procedures and Tactical Training Plans

• Customer 1 – the monitoring of capabilities against future needs, building the Equipment Programme (EP) and ownership of User Requirements Documents for new capabilities

2 Further information can be found in the MODAF Overview document (MODAF-M09-002)

C A D M C A D M I T

D I

Concepts & Doctrine

Capability

Management

Operations

Funded Options

Capability Gaps Future Op

Needs

Doctrine

Customer 1 Acquisition

Sustainment

Customer 2

Concepts & Doctrine

- 9 -

• Acquisition – the Acquisition Process is concerned with the development and fielding of new or enhanced military capabilities. The Acquisition Deskbook scope focuses up to the acceptance into service of a fully operational capability.

• Sustainment – the process to maintain and dispose of a military capability within defined parameters throughout its operational life

• Customer 2 – the planning and conducting of operational activities including Core Leadership and Pivotal Management roles as defined in Smart Acquisition3

2.2.3 Deskbook Structure

The remainder of this Deskbook comprises two key sections:

Section 3 - MODAF’s Relationship to the Acquisition Processes and Activities – this section identifies the key business processes and activities of the Concept Assessment Demonstration Manufacture In-Service Disposal (CADMID) cycle and suggests how these align with the MODAF Viewpoints.

Section 4 - Worked Example of MODAF in Acquisition – this section demonstrates how MODAF can be used practically within CADMID.

In addition, the following ‘quick start guides’ are available that summarise key elements of this Deskbook:

• Project Management Guide (MODAF-M10-006)

• Requirements Guide (MODAF-M10-007), and:

− User Requirements Document (URD) Guide (MODAF-M10-003)

− System Requirements Document (SRD) Guide (MODAF-M10-008)

• Systems / Technology Guide (MODAF-M10-009)

• Industry / Supplier Liaison Guide (MODAF-M10-010)

• Through-Life Management Guide (MODAF-M10-011)

3 See Smart Acquisition Handbook, available on the Acquisition Management System (AMS) at http://www.ams.mod.uk/ams/content/handbook/maintext.pdf

- 10 -

3. MODAF Relationship to Acquisition Business Processes and Activities

3.1 Architecture Development Process

3.1.1 Six-Stage Architecture Development Process

The approach to developing a MODAF-compliant architecture is shown in Figure 3-1. This shows how a MODAF user within any community in the MOD goes about establishing the intended use, scope and data requirements, developing the architecture, using this to conduct the required analyses and documenting the results. A more detailed description of this six-stage architecture development process is provided in the Overview of MODAF (MODAF-M09-002).

Figure 3-1: General Process for Building MODAF-Compliant Architectures

In addition to showing the steps that a MODAF user should follow, Figure 3-1 also highlights the MODAF resources that are available to help them and the key interactions that are required with the MODAF governance processes.

One of the key MODAF resources will be the MOD architectural repository (MODAR) that is being defined by the Integration Authority (IA)4. It is intended that this can be used to run queries and extract existing architectural data – such as information on the systems that a new capability has to interface with. It will be essential to the enablement of NEC that all new architectures and updates to existing architectures

4 An initial version of MODAR is currently available, accessible through the IA. Please refer to the MODAF Overview paper (MODAF-M09-002) for further information regarding MODAR and its usage.

User training- MODAF principles

Prerequisites 1. Establish Intended

Use

2. Define Architecture

Scope

3. Develop Data

Requirements

4. Capture Architecture

5. Conduct Analyses

6. Document Results

MODAF Governance

MODAF Users

MODAF Resources

MODAF Baseline

Architectural Use Doc.

Workshop -Determine Architecture Usage

Workshop -Bound Architecture Scope

Workshop -Establish Data Needs

Architectural Scope Doc.

Tool Selection

Data Gathering Plan

BaselineArch. Review

Baseline Architecture

Inform Central Reg.

Query of Avail. Data Sources

Publish Baseline to MODAR

Tool-specific Training

Initial Analysis

Final Analysis

Analysis Review

Finalised Architecture

Finalised Arch. Review

Publish Final Arch. to MODAR

Provide Extant Arch.Data

MODAF Training Material

MODAF Tiger Teams

MODAF Tiger Teams

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Tiger Teams

Certified Tool List

Tool Advice

Hybrid View Development

MODAF Tiger Teams

MODAF Tiger Teams

MODAF Tiger Teams

MODAF Taxonomy

ERM / M3

Workshop -Determine Use Cases

Plan of Time & Resources

- 11 -

are lodged with MODAR to inform others and allow the re-use of new architectural data. Furthermore, the IA provides additional integration services that assist in modelling end-to-end performance and interoperability assurance5.

Another key resource will be the list of certified tools. The MODAF tool certification scheme is still being developed at the time of this MODAF baseline issue, definitive guidance as to tool availability and fit with different COIs is not currently available. Therefore, interim guidance exists on the availability of MODAF convergent tools6.

It is recognised that aggregation of data in MODAR raises classification issues, and some information may be Commercial-in-Confidence from industry suppliers. This data will be handled as per current procedures for data handling and storage, although such considerations must be taken into account prior to publishing any architecture for general use.

In order to facilitate the searching and query of architectures it is essential that the All Views (AV-1 with meta data regarding the architecture and AV-2 with the architecture’s object dictionary) be completed thoroughly for all architectures before they are published. Further information on the All Views can be found in the MODAF View Overview Document. It is worth noting that most architecting tools provide functionality to automatically generate the object dictionary from the description fields as the taxonomy is defined.

The All Views should be completed as early as possible in the architecting process, and therefore may already be defined during creation of the URD Views, prior to the IPT taking over responsibility for the architecting tasks.

3.1.2 Architectural Data Sources

When the development of MODAF architectures is a mature process, an IPT could expect to commence its lifecycle with a comprehensive set of data sources including MODAF architectures supporting the capability definition (Strategic Views), URD and CONEMP (Operational Views), interfacing systems (System Views), applicable standards (Technical Views) and programmatic information (Acquisition Views). Realistically, most IPTs will find some or all of these are missing when they commence their architectural activities and will have to backfill the key elements themselves and validate them with the stakeholders who should have provided them (eg URD Views with Customer 1).

Many architectural products from one acquisition lifecycle stage will form inputs to the architectural activities of the next lifecycle stage. However, it is important that the IPT explicitly repeats the six-stage architectural process for the new stage as the required outcomes; assumptions, scope, data sources etc may have changed between stages. Indeed, it is quite likely that the nature of modelling / Views and the level of granularity will change from one lifecycle stage to the next.

Any team conducting architectural activities in MOD should contact the IA as custodians of the MODAR in order to establish what extant architectural data may

5 Please contact the Integration Authority, DPA, Abbeywood, for further information regarding interoperability services. 6 Interim NEC, CBM and BMS MODAF Modelling Policy, DEC(CCII) File ses 046-05, 1/3/05.

- 12 -

exist or to understand who else may be developing related information – all of which will minimise the degree of nugatory work.

Industry is likely to be involved in the acquisition processes and associated architecture development throughout the lifecycle. IPTs are supported by Industry, and their engagement is initiated by the IPT. MODAF architectures will play several important roles in the process of industry engagement:

• Developing a clearer understanding of requirements and contextual information against which Industry will be bidding. This should enable better estimates to be obtained with lower risk content and hence improved project outcomes in terms of cost and schedule

• Providing a mechanism to document the design solution being provided by Industry so that others may more readily interface with or utilise it – improving interoperability

However, initially at least, it is not expected that Industry will provide documentation of more than its highest level designs in MODAF formats and it will wish to protect its proprietary information and technology. Therefore, it is expected that industry will provide “grey box models”7 of its solutions during the acquisition lifecycle. These models will be expected to provide comprehensive definition of the system interfaces / services, applicable standards and data formats but will not expose more than basic information regarding the internal system functions.

3.1.3 Application to Acquisition Process

The intent is that the architecture development approach should be applied by all acquisition IPTs as they progress through the CADMID / CADMIT lifecycle8 in order to deliver the required new or enhanced military capability.

For Version 1.0 of MODAF, Views have been mapped to Acquisition processes based on a series of engagements with the Acquisition community and an understanding of the CADMID lifecycle. The application of specific MODAF Views to the different elements of Acquisition activity is described in more detail later in this section.

3.1.4 Overview of MODAF View use

MODAF Views support business processes at a variety of different levels - from being the core basis for a business activity, to providing some supplementary guidance to that activity. AcV-2, for example, showing the SoS Acquisition Programmes, is the basis for scheduling decisions regarding selection of technology options. However, it can also be used to analyse the scheduling effect on the system dependencies when considering detailed design options.

7 A “black box model” is one where the inner system workings are not described: only the interfaces, inputs and outputs are published. Slightly more information regarding the workings of the system will be required in MODAF, however not every detail – hence the use of the expression “grey box” 8 Further information on the CADMID / CADMIT lifecycle can be found on the Acquisition Management System (AMS) – http://www.ams.mod.uk. The later sections of this document refer to ‘CADMID’ for ease of reference: the reader should note these could also be applied equally to CADMIT.

- 13 -

MODAF Views may also provide a means of communication between different stakeholders in a process.

Two levels of use have been defined for MODAF Views identified in this Deskbook, reflecting the level of support provided by a View to a particular activity:

• Essential – Views that are essential for use during a particular Acquisition activity

• Highly Desirable – Views that are recommended to inform a particular activity, given that they contain a significant amount of data of value to that activity in the majority of scenarios or circumstances.

The Essential Views are the starting point for any new MODAF user. Highly Desirable Views are more appropriate to users who have experience of MODAF View use and are looking for further ways of using MODAF Views to inform an activity. This may include the need for greater rigour in analysis, or the need to find a way of addressing a specific scenario or circumstance.

Any View may be used in addition to the Essential and Highly Desirable Views at any stage if it helps in the execution of the analysis / task.

3.1.5 Ensuring Views are MODAF compliant - hybrid and modified Views

As identified in Figure 2-1, MODAF provides a discrete set of Views that can be selected to create an architecture. However, it is possible for a user to create Views that look similar to those specified by MODAF, but that are not compliant to MODAF, without understanding the data elements and relationships that MODAF specifies within the View construct.

In brief, a View is considered MODAF compliant when the data elements and relationships within that View are the same as those specified by MODAF, in what is known as the meta-model. Otherwise, the View created is an independent architecture, and cannot claim MODAF compliance. For further information regarding MODAF compliance through the underlying data elements, please refer to the MODAF Technical Handbook (MODAF-M07-022).

A ‘hybrid’ or ‘modified’ View is a MODAF compliant View that deviates in content from a View provided in the MODAF View suite – as shown in Figure 2-1. A hybrid or modified View does not contain the data elements specified by one of the MODAF provided Views, eg StV-3, OV-5 etc, it contains a hybrid combination of the data elements and relationships of one or more MODAF provided Views, eg a combination of SV-1 and SV-2.

3.2 Acquisition Process

This Deskbook describes the architectural processes as they relate to the Acquisition community by reference to the Acquisition process model shown in Figure 3-2. This diagram also shows the key interfaces with the other communities considered within the MODAF Deskbooks. The interface documents are the focus of this diagram; the time element is not represented. The CADMID / CADMIT cycles are to represent acquisition as a whole and not intended to show exactly where the documents fit in to

- 14 -

a particular process stage. This type of information can be found on the Acquisition Management System (AMS)9.

Figure 3-2: Key Elements and Interfaces of Acquisition COI Processes

The Acquisition COI processes interface with all of the other COIs, some of the key inputs and outputs being:

• Concepts and Doctrine – inputs: provides the Acquisition processes with applied concepts that document the operational context and usage of the new capability

• Capability Management – inputs: is responsible for the CRD, URD, associated KURs and their management throughout the lifecycle

• Sustainment – outputs: the Acquisition processes deliver the operational capability and associated documentation to the Sustainment community, including the TLMP and MODAF architecture. In practice, the sustainment activities will normally be conducted by the same IPT as conducted the acquisition processes. There will be a progressive shift of focus as the capability moves from Manufacture into In-Service and the sustainment activities should be considered / planned for from the earliest stages of the CADMID cycle

• Customer 2 – inputs: the Capability Integration Plan (CIP) that defines responsibilities and integration mechanisms across all of the LoDs is developed in conjunction with Customer 2

9 MOD Smart Acquisition Management System http://www.ams.mod.uk

Acquisition

I T

DI

Concepts & Doctrine

Capability

Management

Operations

C A D M

C A D M

Acquisition

Project Management

Requirements

Systems / Technology

Industry

Through Life Management

URD SRD

CapabilityTLMP

CONOP,CONEMP,CONUSE CIP

- 15 -

The role of MODAF architectures in supporting the Acquisition COI processes and its key interfaces with the other COIs is described in the sections that follow, structured according to the main sub-processes shown in Figure 3-2.

3.3 Project Management

This section describes the use of MODAF for the Project Management workstream within the IPT. PRINCE2 is the Project Management methodology used by the MOD. MODAF is intended to support the use of PRINCE2 by standardising some of the information within the PRINCE2 deliverables, not to replace it as a methodology. The key Project Management activities, described in this section, which may be helped by use of MODAF are:

• Forming the IPT

• Systems Engineering Management Plan

• Initial Gate Review

• Management of Dependency Risks

• Main Gate Review

• Placing of contract(s) to meet the SRD

• Winding down the IPT

Figure 3-3 shows the key architectural product for Project Management, Acquisition View AcV-2 System of Systems Acquisition Programmes, and how this fits within the overall process, as shown in Figure 3-2.

- 16 -

Figure 3-3: Key MODAF Relationship to Project Management Activities

AcquisitionProject Management

Requirements


Industry


CONCEPT ASSESSMENT DEMONSTRATION MANUFACTURE IN-SERVICE DISPOSAL

Form the IPT

URD

View Set

Essential View producedoutside this workstreamTV-1

InitialGate

Essential View producedby this workstream

Highly Desirable View producedby this workstream

Highly Desirable View producedoutside this workstream

TLMPAcV-2URD

SV-1OV-2

Managedependency

risks

OV-5StV-5

SRDURD

MainGate

SRD ITEAPTLMP

Placecontract(s) tomeet the SRD

SRD

URD

Wind down ofIPT

Key

TV-1

SV-1 TV-1OV-2

AcV-2

- 17 -

3.3.1 Form the IPT

The IPT may be formed through the Future Business Group (FBG) where the project scope does not match that of an existing IPT. Alternatively, a new system may be allocated to an existing IPT if it fits with that IPT’s current programme of work.

Any MODAF Views created relating to the system so far, as well as other supporting documentation, should be made available to the IPT from the relevant community. This may be Customer 1 with regard to the URD Views; in future it may be FBG or the System of Systems/Cluster Governance organisation (which is currently in development) that might provide Acquisition Views AcV-1 and AcV-2; AfNEC may also in future provide a new IPT with further information regarding the pre-Concept work relating to this system acquisition.

Part of this process includes co-ordination and management of the standards portfolio from System of Systems and URD requirements10. The use of the Technical Viewpoint, and TV-1 in particular, aids this role in tracking the Treaties, Legislation and Standards invoked.

TV-1 will increase in detail throughout CADMID cycle. The core constraints will be identified by Customer 1 in the URD, then the project specific constraints added through the SRD development work by Main Gate. It is expected that many of the core constraints within a capability’s TV-1 will be derived from the core set of the JSP 600 series which define the standards required to converge with DII and in the longer term towards NEC. During the Demonstration and Manufacture Stages, the standards may be refined further (through different, equivalent, standards being chosen and/or increasing in granularity) through contract negotiation and any proprietary standards from the preferred supplier. During the In-Service Stage the Sustainment community will also use and update the TV-1 where appropriate, through to Disposal, when legal or environmental standards may apply. Creation and maintenance of the TV-1 is an essential part of the Requirements process.

Figure 3-4: TV-1 Technical Standards Profile

10 Further information regarding Standardisation and its application to Acquisition can be found on the Acquisition Management System at http://www.ams.mod.uk/ams/content/topics/2616.htm, or by contacting PDG Standardisation.

Service Area Service System Elements

Standard / Policy

Data Transfer TCP/IP BOWMAN IP v6

Messaging Email BISA / Comms

MS Outlook CompliantJSP 324

Operating Systems

Workstations BISA / Control Stations

Data Interchange

Interoperability OMG XMI 2.1


Standard / Policy




Operating Systems


Data Interchange


Service AreaService AreaService Area ServiceServiceService System ElementsSystem

ElementsSystem

ElementsStandard / PolicyStandard / PolicyStandard / Policy

Data TransferData TransferData Transfer TCP/IPTCP/IPTCP/IP BOWMANBOWMANBOWMAN IP v6IP v6IP v6

MessagingMessagingMessaging EmailEmailEmail BISA / CommsBISA / CommsBISA / Comms




Operating SystemsOperating SystemsOperating Systems

WorkstationsWorkstationsWorkstations BISA / Control Stations

BISA / Control Stations


Data InterchangeData InterchangeData Interchange

InteroperabilityInteroperabilityInteroperability OMG XMI 2.1OMG XMI 2.1OMG XMI 2.1

- 18 -

3.3.2 Systems Engineering Management Plan

The Systems Engineering Management Plan (SEMP) forms one of the key project documents, along with the Through-life Management Plan (TLMP) and the Programme Management Plan (PMP).

The SEMP may make use of MODAF Views to illustrate the process to be used by the IPT in delivering the System. It will also record the Systems Engineering process to be followed by the IPT, and therefore, the Views that are planned for creation and analysis. An example of how MODAF Views can be used to illustrate the SEMP, and how the SEMP lays down the use of MODAF within the programme can be found in the Integration Authority SEMP Volume 111.

3.3.3 Initial Gate

The business case to be presented at Initial Gate includes the programme plan and costing for the procurement.

AcV-2, SoS Acquisition Programmes, shall be part of the Initial Gate business case, showing how the outline plan fits in with the delivery of related procurements to deliver the capability as a whole. AcV-2 is not designed to replace the usual Gantt Charts used by the project and programme managers. Rather, the Gantt charts will feed into the AcV-2, such that this View is a high-level summary of the more detailed information contained and managed within the usual Gantt charts. This will enable programmatic information to be presented to a senior audience in a standard format across IPTs. An example AcV-2 is shown in Figure 3-5.

11 Integration Authority Systems Engineering Management Plan Volume 1 – Systems Engineering Process. File name: SEMP vol 1 0.C_1.1_1.doc File ref: IA/06/02/2701

- 19 -

Figure 3-5: AcV-2 SoS Acquisition Programmes

The TLMP shall also inform the costing of the Initial Gate business case, along with its related Views (see Section 3.7 Through-Life Management).

Other Views that shall be used during the Initial Gate review are those that inform the URD (see Customer 1 Deskbook and URD Reference Guide for URD Development).

The overall submission for Initial Gate will be subjected to interoperability and compliance assurance by the IA so as to confirm that adequate consideration has been taken of interoperability issues (eg through Operational View OV-2 and System View SV-1) and compliance with standards including JSP 600 series (using TV-1). This assurance process will normally involve an assessment of the project’s MODAF architecture against those for interfacing systems held within MODAR.

3.3.4 Manage dependency risks

The Smart Acquisition Process refers to risk reduction across the whole procurement activity. Initially, the area where MODAF architectures can provide most assistance is in reducing dependency and interoperability risks.

AcV-2 SoS Acquisition Programmes identifies the main dependencies and timescales, including how the Defence Lines of Development (LoDs) are expected to develop and mature throughout the acquisition cycle. This maturity can be seen through the ‘traffic-light’ status assigned to each LoD, showing how the LoD is planned to mature. Early in the lifecycle, the LoD indicators are likely to be planned

Kestrel needs to come in to service as planned, to avoid a

capability gap arising when SPECS is fully disposed

- 20 -

to be Red or Amber, and as the project or programme moves through the CADMID lifecycle more LoD indicators will be planned to turn Green, as more of the LoDs mature through time. Using the information contained within this View, AcV-2 can be used to analyse the key programme dependency risks, including an assessment of the dependency risks associated with all LoDs.

OV-5 Operational Activity Model (from the URD) and StV-5 Capability to Systems Deployment Mapping (if available from Customer 1, if not the IPT might wish to obtain the relevant information themselves) can be useful to assess the effects of changing the scope of the required capability.

In terms of development risks, the URD and SRD (including their related Views) shall be the main inputs into risk reduction. This will be undertaken partly through the tender process. Depending on the acquisition, this process may take several months or years, during which time the solution and associated risk will be traded off in conjunction with the bidders (and ultimately the preferred bidder). The SO shall be involved with the drawing up of the Invitation To Tender (ITT) and any subsequent Tender Assessments to confirm these documents have the correct Standards Portfolio.

3.3.5 Main Gate

The Main Gate business case is a key deliverable, along with the SRD, from the Assessment Stage. The process and products are similar to those used at Initial Gate but with a higher degree of maturity expected at this stage. Specifically, the SRD, ITEAP and refined TLMP shall feed into this business case, along with the system design synthesis, to inform the decision on whether to proceed.

Again, the overall submission for Main Gate will be subjected to interoperability and compliance assurance by the IA so as to confirm that adequate consideration has been taken of interoperability issues (eg through OV-2 and SV-1) and compliance with standards including JSP 600 series (using TV-1)12. This assurance process will normally involve an assessment of the project’s MODAF architecture against those for interfacing systems held within MODAR.

Security accreditation may also be assessed during the Main Gate submission. Work is ongoing in the area of Information Assurance by DCSA and CSG, among others. The use of MODAF Views for security accreditation purposes is highly desirable, but the way forwards is yet to be agreed.

3.3.6 Place contract(s) to meet the SRD

The SRD forms a key part of the contract, laying down the requirements to be met by the supplier. Therefore, the URD and SRD Views (see sections 3.4.1 and 3.4.3) shall help to illustrate the requirements, and ensure that the IPT and the supplier share the same understanding of the wider capability and system interface requirements, as well as the system functional and performance requirements.

12 The interoperability and compliance assurance process is managed and implemented by IOCA (Interoperability Compliance Assurance). Please contact the IA for further information regarding IOCA assurance.

- 21 -

3.3.7 Wind down of IPT

The architectural element of closing down the IPT shall be to ensure that the final architecture description left after disposal of the system is reflected in MODAR, so that the repository reflects the removal of this system from service.

- 22 -

3.4 Requirements Management

This section describes the use of MODAF for the Requirements Management workstream within the IPT. The key activities for Requirements Management that may be helped by use of MODAF are:

• Develop and Maintain User Requirements Document (URD)

• Maintaining the linkage between User and System Requirements

• Develop and Maintain System Requirements Document (SRD)

• Integrated Testing, Evaluation and Acceptance Plan (ITEAP)

• Acceptance

Figure 3-6 shows the key architectural products for Requirements Management, within the URD and SRD, and how this fits within the overall process, as shown in Figure 3-2.

- 23 -

Figure 3-6: MODAF relationship to Requirements Management


Requirements


Industry



View Set

Essential View producedoutside this workstream




Key

User Requirements Document (URD)

StV-6

OV-1

OV-2

OV-2

OV-3

OV-5

TV-1

OV-3

OV-5

TV-1

Linkage between user andsystem requirements SV-5

SV-4

OV-5

System Requirements Document (SRD)URD

SV-1

SV-2

SV-3

SV-4

SV-6

SV-7

TV-1

NB: The TV-1 contained inthe SRD will be at a lowerlevel than that in the URD.This more detailed TV-1 iscreated by the IPT, basedon the high-level TV-1 in

the URD.

SV-2

SV-6

SV-7

TV-1

Integrated Testing, Evaluation and AcceptancePlan

StV-2

OV-1c

SV-7

SV-3

SRD

OV-7 OV-7

- 24 -

3.4.1 User Requirements Document (URD)

The URD is owned and developed by the Customer 1 community. The finalised Equipment Programme (EP) is used as a basis for the selection and grouping of acquisition programmes. For these programmes, user requirement sets are developed and maintained throughout the acquisition process. The full Capability Management process, culminating in the URD production, is described in the Customer 1 Deskbook13 and the URD Reference Guide14. Other guides are also available15. The Views included in the URD, and provided by Customer 1 to the Acquisition Community, are shown in Figure 3-7 below.

Figure 3-7: URD MODAF Viewpoints through CADMID

Please refer to the Customer 1 Deskbook13 and the URD Reference Guide14 for further information regarding the URD creation process using MODAF.

3.4.2 Linkage between User and System Requirements

It is important to note that the use of these Views is not intended to duplicate or replace use of requirements management tools, such as DOORS. Rather, the use of SV-5 should complement the use of requirements management tools, acting as an ‘at-a-glance’ view of the information in the requirements tool. Several architecture tools are developing interfaces to requirements tools, so that the SV-5 can be automatically generated from the requirements mapping information.

The SV-5 shall be kept updated during SRD development to ensure the linkage with the URD Views is maintained16. SV-5 Operational Activity to Systems Function Traceability Matrix acts as the ‘glue’ between the URD and SRD Views. It is essential

13 MODAF-M10-001 14 MODAF-M10-003 15 For example, DCBM(Army) Guide to URD Development D CBM(A)/07/10/06 14 March 2005 16 As the Views are derived from the underlying data held in the model, the SV-5 should be automatically updated with any changes to underlying data resulting from changes to the URD or SRD.

IG MG

TV-1

OV-2

OV-1

OV-3

OV-5

Operational Viewpoint Suite

StV-6

OV-1


OV-2

OV-1


OV-5

TV-1

OV-3

OV-2

Assessment DemonstrationConcept

��

��

�

StV-6 StV-6

Essential View

Highly Desirable View

- 25 -

to show the operational activities laid down in the URD, and how these are met by the system functions required in the SRD. The SV-5 shall be kept up-to-date in parallel with development of the SRD, to ensure that the SRD Views are kept in-line with the URD Views.

It is also possible to link the functional decomposition in SV-4, Systems Functionality Description, (part of the SRD) with an allocation of functions to systems within the SV-5.

Figure 3-8: SV-5 links the URD and SRD

A high-level analysis of the OV-5, Operational Activity Model, may also be used to show the linkage between operational activities and the systems that support them.

3.4.3 System Requirements Document (SRD)

The Operational Views developed along with the URD during the Concept Stage help inform the development of the System Views and the associated System Requirements Document (SRD). A draft SRD is developed for Initial Gate, and the document is refined during the Assessment Stage, producing an agreed version at Main Gate. Figure 3-9 shows how the MODAF Views that support the SRD mature during the acquisition lifecycle.

Map to SV-4 System Functions

Operational Activities defined in URD

System Functions defined in SRD

- 26 -

Figure 3-9: SRD MODAF Viewpoints through CADMID

The System Requirements are developed from and must be traceable to the User Requirements; therefore, the main input to this process is the URD document and its related Views shown in Figure 3-7. StV-5 (if available) may also be useful in developing the SRD as an aid to identifying system options and interfaces.

The System Viewpoint is the key part of the SRD development. The first step is to derive those functions that need to be implemented within the system, through the essential SV-4 Systems Functionality Description. Analysis of the OV-5 in the URD will provide a key input to this process, to decide which activities are best supported by systems. The SV-5 shall show functional groupings that, depending on the size of the system, may be tendered for separately. It may also be used to identify the data flows required between functions, to enable closely coupled functions to be developed together. Creation of SV-4s requires detailed functional analysis and may usefully be supported by experimentation.

Figure 3-10: SV-4 Systems Functionality Description

IG MG

TV-1

SV-3

SV-1

System Viewpoint Suite

SV-6

TV-1

SV-2


SV-4

SV-7

SV-3

SV-1


SV-4

SV-2

SV-6

SV-7

Essential View


OV-7 OV-7

- 27 -

Interface requirements can now be documented. Prior to Main Gate, it is likely to be only the key external interfaces, which provide interoperability requirements, which will be modelled using the following essential Views:

• SV-1 Systems Interface Description shows the interfaces that the new system needs to support. It also shows the interdependencies with other systems (and therefore other IPTs and/or suppliers), with which the supplier of the new system will need to co-operate. Additionally, it shows the nodes to which the supplier needs to deliver systems, and supports an understanding of its fit within the Concept of Operations (ConOps) through identification of the information needlines

Figure 3-11: SV-1 Systems Interface Description

• SV-2 consists of several sub-Views, described below. These are all key Views to specify and assure interoperability between systems. These may be created at a summary level for the SRD, and then increased in detail by the supplier during their system design:

− SV-2a System Port Specification shows the network protocols at each layer of the network stack for each system port, to which the new system must conform

Figure 3-12: SV-2a System Port Specification

Needlines show interdependencies with other systems, with which the new

system will need to share information

- 28 -

− SV-2b System to System Protocol Stack is used to assess the compatibility of the protocol stacks between multiple interfacing systems in order to provide interoperability assurance

Figure 3-13: SV-2b System-to-System Protocol Stack

− SV-2c System Connectivity Clusters shows how the individual interfaces required can be logically grouped into nodal connections, to identify redundancy in the system of systems, and to reduce the number of point-to-point connections that need to be maintained (thereby reducing maintenance and support costs). This View can be used to assess network performance needs.

Figure 3-14: SV-2c System Connectivity Clusters

• SV-3 System to System Matrix identifies which of the potential communications paths shown graphically in SV-1 form the key system to system interfaces, presenting them in a matrix format to identify all required interfaces

- 29 -

Figure 3-15: SV-3 System-to-System Matrix

• SV-6 Systems Data Exchange Matrix shows the characteristics of the data that will be sent over the interface connections identified in SV-1 and SV-3. This enables network capacity analysis to ensure that the network will have the required bandwidth available to support these interface requirements and may be used to support the development of the system data models. The SV-2 suite of Views will also assist with network analysis activities. The SV-6 should be related to the Information Exchange Requirements laid down in the URD, in OV-3. Again, it is likely that this will be developed by the customer at a high-level within the SRD, and increased in granularity by the supplier during system design.

Figure 3-16: SV-6 Systems Data Exchange Matrix

It should be noted that the development of all of these Views regarding interfacing systems and interoperability will be supported by information on interfacing systems that will be available through MODAR. The IA also provides related services to help develop interoperability requirements.

The performance requirements for each part of the system are then defined in an essential SV-7 Systems Performance Parameters Matrix.

The OV-7 Logical Data Model may need to be developed to reflect the increased level of detail regarding the data and information exchanges emerging during the SRD development, although this is not essential. This is preferable to the creation of

- 30 -

an SV-11 Physical Schema, as the physical schema should be part of the solution design, not the requirements. Please refer to the MODAF View Overview Document for further information regarding these Views.

Finally, refining the TV-1 is essential during SRD development to define the system constraints and to ensure the system conforms to the standards and protocols that will enable interoperability. TV-2, Technical Standards Forecast, may also be updated with new information regarding upcoming standards and protocols. In the future it may be that a family of over-arching TV-1s and TV-2s will be maintained by the appropriate authorities within MOD (for example: an IT TV-1, a health & safety TV-1, a building materials TV-1 etc), from which an IPT will be able to cherry-pick the standards and constraints relevant to their system. Initially, however, IPTs will need to develop their own Technical Views, building on those included in the URD.

The SRD will continue to be updated throughout the CADMID cycle, as trade-offs are undertaken, and the system design matures. The implications of any trade-offs need to be traced all the way up from Systems (through the SRD Views) through the Operational Views (in the URD), up to the effect on the Capability delivery (through the Strategic Views in the Capability Area Plan (CAP)). The Strategic Views StV-2 and StV-3 (where available from Customer 1), should therefore be used in conjunction with the URD and SRD when performing trade-offs. This is done to ensure that when a system trade-off is made, the implications at both Operational and Strategic levels are considered, so that key requirements and constraints are not violated.

3.4.4 Integrated Testing, Evaluation and Acceptance

This section describes the MODAF Views that provide assistance in planning the Test, Evaluation and Acceptance of the System and Capability.

MODAF architectures are particularly suited to the development of Validation and Verification (V&V) Requirements for the ITEAP, by providing the Views that might be used as ‘checklists’ during testing, evaluation and acceptance. Although the ITEAP is intended to support test and evaluation conducted during Demonstration and Manufacture stages it is important that its production and refinement is commenced as early as possible in the CADMID cycle. It will be useful to liase with the IA when developing the ITEAP so as to establish the nature of the test and evaluation facilities that are likely to be available at the time the new capability is likely to commence testing and to synchronise its test and evaluation programme with other relevant systems.

StV-2 Capability Taxonomy (with performance attributes added17) and OV-1c Operational Performance Attributes will both provide sources of acceptance criteria for inclusion within the ITEAP. Both these Views are essential for creation by Customer 1, and so shall be included in the ITEAP as long as they are available.

17 Performance Attributes may be added to a Capability in the MODAF Meta-Model for this View. These may be displayed on the main View or in tabular format as an appendix to the View if they would over-complicate the main View purpose. Please refer to the MODAF Technical Handbook (MODAF-M07-022) for further information regarding Capability attributes.

- 31 -

SV-7 System Performance Parameters Matrix (which forms part of the SRD document suite) is also essential for inclusion in the ITEAP, to identify the performance characteristics against which the system will be accepted.

SV-3 Systems-Systems Matrix may be useful as an ‘at-a-glance’ view of all the systems to which the new system should interface, which can be checked during testing.

In addition, any of the SRD Views may be used as the basis for the V&V Requirements in developing the ITEAP.

- 32 -

3.5 Systems / Technology

This section describes the use of MODAF for the Systems / Technology workstream within the IPT. The key activities for the Systems / Technology workstream that may be helped by use of MODAF are:

• Identification of technology and procurement options

• Demonstration of the ability to deliver integrated capability

• Technology insertion (during the In-Service Stage)

Figure 3-17 shows the key architectural products for the Systems / Technology workstream, and how this fits within the overall process, as shown in Figure 3-2.

- 33 -

Figure 3-17: MODAF Relationship to System / Technology workstream


Requirements


Industry



View Set





Key

Identify technology and procurement options

StV-3

TV-1

SV-9

TV-2

SV-9

TV-2

updated

updated

Demonstrate ability to deliverintegrated capability

OV-2

OV-3

SV-1

SV-7

SV-6

OV-1c

SV-7

Technology insertion

SV-9

TV-2

- 34 -

3.5.1 Identify technology and procurement options

The undertaking of this process described here relates to the current CADMID process. It is understood that this is subject to change with the AfNEC (Acquisition for NEC) work, looking at use of alternative procurement and delivery options (such as more off-the-shelf (OTS) and re-use of existing systems to deliver additional capability). When purchasing Commercial OTS (COTS) equipment it is important not to over-specify the standards – or else additional cost and risk may be transferred back to MOD, negating the benefits of using a COTS solution.

StV-3 Capability Phasing, provided by Customer 1, shows the IPT the broader picture of the overall capability delivery and which other systems are being acquired, upgraded or retired in the time period that the new capability is being procured. This may help inform decisions regarding common technologies and procurement options across a number of related capabilities, such as applications delivering in the same epoch agree on a common target Operating System between themselves.

SV-9, Technology Forecast, informs the IPT of new technology that may become available in the short-, medium- and long-term. If new technology is due to become available during the lifetime of the acquisition process, this will need to be considered as an option. The technology forecast also helps the IPT to avoid technology and system options that would be obsolete by the time the system is put into service. An example SV-9 can be found in Figure 3-1818.

18 Note that the time-periods defined in the example View shown here are representative only. Any timeframe may be defined for the short, medium and long term depending on the overall timeframe for the architecture. The same is true for the timeframes used within the TV-2 View.

- 35 -

Figure 3-18: SV-9 Systems Technology Forecast

The Technical Standards Forecast TV-2 informs the IPT of likely future constraints to their system that are expected to come into force within the CADMID lifecycle. The system may need to adhere to new standards, protocols and legislation due to come into force, therefore this will affect the procurement and technology options for delivery of the new system.

The Systems Performance Parameters Matrix SV-7 may also be an input to this process, as the technology and procurement options available will need to meet the required performance parameters. SV-7 might also be used to include costs for each option, through cost / performance parameters, to feed into the Balance of Investment decision.

Once the technology and procurement options have been identified and reviewed, and those meriting further investigation identified, TV-1 Technical Standards Profile is essential to be created / updated to aid the analysis of these options, and the development of the chosen option.

TV-1 shall show the constraints that apply to each option (with a separate TV-1 created for each option being explored). This feeds into the requirements documents, and informs the options chosen, as, generally, the more constraints on a system the more costly it will be to procure. When populating the TV-1 only use the minimum number of Treaties, Legislation and Standards that underpin the requirements. An example TV-1 is shown in Figure 3-4.

It is essential to keep SV-9 Systems Technology Forecast and TV-2 Technical Standards Forecast updated throughout the CADMID cycle as technology and standards develop, and the future technological landscape becomes clearer. In the longer term it is likely that there will be appropriate authorities responsible for updating and maintaining TV-2s and SV-9s for the MOD. Initially, the IPT will need to maintain their own TV-2 and SV-9 relevant to their system(s), most likely in conjunction with Industry.

Desktops may need upgrade in the long term to take advantage of new processors

- 36 -

3.5.2 Demonstrate ability to deliver integrated capability

Once the option has been chosen during the Concept and Assessment Stages, it must be shown to deliver the requirements during the Demonstration Stage. The following Views will support technology demonstrators / prototypes in demonstrating that the requirements are met by the chosen system solution.

OV-2 Operational Node Connectivity Description and SV-6 Systems Data Exchange Matrix shows how the system will meet the interoperability requirements, to provide an integrated capability.

OV-3 Operational Information Exchange Matrix and SV-1 Systems Interface Description respectively show the Information Exchange Requirements (IERs), which should be included in the contract to ensure integration, and the physical systems that will need to be connected to meet these IERs.

OV-1c Operational Performance Parameters and SV-7 System Performance Parameters Matrix show the required operational and system performance to be delivered by the solution.

3.5.3 Technology insertion

Once the system is in the In-Service Stage, the technology evolution and evolving standards may drive obsolescence of system elements. The TLMP will be updated using inputs from the SV-9 and TV-2 to reflect this changing technology landscape, and upgrades, improvements or replacement initiated through Customer 1 to the IPT as needed.

- 37 -

3.6 Industry / Suppliers

This section describes the use of MODAF for the Industry / Supplier liaison within the IPT. The key activities for the Industry / Suppliers in conjunction with the IPT that may be helped by use of MODAF are:

• Industry involvement

• System synthesis

• Contract negotiation

• Solution delivery

• Carrying out any agreed upgrades or improvements once the system is in the In-Service Stage

Figure 3-19 shows the key architectural products for the Industry / Supplier liaison, and how this fits within the overall process, as shown in Figure 3-2.

- 38 -

Figure 3-19: MODAF Relationship to Industry workstream


Requirements


Industry

Through Life ManagementCONCEPT ASSESSMENT DEMONSTRATION MANUFACTURE IN-SERVICE DISPOSAL

View Set





Key

Involve Industry

OV-1

OV-2

System SynthesisSV-9

TV-2

SRD

Negotiate Contract

URD

SRD

Deliver Solution

Carry out any agreedupgrades or improvements

StV-2

StV-3

SV-8

- 39 -

3.6.1 Involve Industry

The MOD Defence Industrial Policy (2002) provides the framework for MOD’s relationship with the defence industry. It makes clear that, right from the start of acquisition projects, MOD is being more transparent about the factors that affect acquisition decisions. MODAF can play a significant role in this transparency by providing early and clear visibility of the context, constraints and interfaces of the required new capability. As far as possible, these will be made clear to potential bidders at the outset to enable them to frame their bids accordingly. This section describes the Views that are useful in early Industry involvement, should an IPT wish to engage with Industry during the early Stages of Acquisition.

Engaging industry during the first stages of the project cycle is important, for example by seeking industry’s views on initial procurement strategies and their help during the early stages of an evolving requirement.

The Operational Viewpoint is particularly useful in the initial engagement with Industry in identifying the operational context and use cases for the new capability.

OV-1 and OV-2 (where available from Customer 1) shall be used for industry involvement during the Concept Stage.

Customer 1 provides the OV-1 within the URD. It gives the high-level background to the system, as shown in Figure 3-20, Figure 3-21 and Figure 3-22 below. The Concepts and Doctrine Community provides the ConOps, ConEmp and ConUse, which can also be used with Industry during this process.

Figure 3-20: OV-1a High Level Operational Graphic

- 40 -

Figure 3-21: OV-1b High Level Operational Description

Industry opinions on the practicality of the performance requirements in OV-1c, and their resultant effect, should be sought prior to formalising these as requirements.

Figure 3-22: OV-1c Operational Performance Attributes

OV-2 Operational Node Connectivity Description, also provided by Customer 1 within the URD, shows the IERs for the new system, within the operational context, thereby providing industry with a high-level view of the interoperability requirements.

3.6.2 System Synthesis

System prototypes may be developed during the Assessment Stage by the IPT in partnership with Industry to identify the most appropriate solution in support of the Main Gate business case. These prototypes will feed into the more detailed work during the Demonstration Stage.

Inputs to this process are:

• The SRD Views, developed by the Requirements workstream

• SV-9 Systems Technology Forecast, to provide insight into how technology is evolving in relation to this system, developed by the Systems and Technology Workstream

• TV-2 Technical Standards Forecast, which, as discussed in the Systems and Technology workstream description, shows how the system needs to be ‘future-proofed’ for the new accepted standards, also developed by the Systems and Technology Workstream.

3.6.3 Negotiate contract

The architectural model developed alongside the URD and SRD will assist the IPT in their contract negotiations. Not only will this provide industry with a clearer system context and set of assumptions but it will also identify the required system interfaces

Attribute Measure Value As - Is Epoch 1 Epoch 2 Target Operational Tempo

Rate of Advance for an Armoured Brigade against light resistance

20 km/day 40 km/day 60 km/day 80 km/day

Synchronisation of Effects

Simultaneous rounds on impact delivered by an Arty Bty

30 rounds 40 rounds 60 rounds 100 rounds

Sortie Rate Period to re-fuel and re-arm an aircraft

4 hours 3 hours 2 hours 1 hours

The Assess Battle Damage process starts when the target has been engaged. An initial assessment is made using nearby FRES Scout. This information is passed up to FRES IFS. FRES IFS will order further BDA if necessary (for example if the first assessment was inconclusive). If necessary a further application of effect may be ordered through FRES PM, followed by a further BDA. Once the battle damage assessment has been completed the FRES roles continue with their original tasks.

- 41 -

and standards. Furthermore, the boundaries within which system elements can be traded-off will be apparent. During negotiations, the cost and time implications of the architectural components can also be finalised, and used as a basis for updating the TLMP with more detailed plans.

3.6.4 Deliver the solution

The supplier will have responsibility to deliver the solution in accordance with the contract and SRD. As part of the solution delivery, the supplier will find it helpful to use some of the MODAF Views as part of their detailed design work.

3.6.5 Carry out any agreed upgrades or improvements

Upgrades and improvements are identified by Customer 2, and fed back into the EP for management by Customer 1. These will usually spawn a new CADMID cycle within the responsible IPT and, as such, will utilise the same MODAF Views as described in this Deskbook.

The need for upgrades or improvements are also informed by the following: StV-2, Capability Functions; StV-3, Capability Phasing, (both of which are owned and updated by the Customer 1 function); and SV-8, the Systems Evolution Description, essential in the TLMP, that shows the planned upgrade path for the system.

- 42 -

3.7 Through-Life Management

This section describes the use of MODAF for Through-Life Management within the IPT. The key activities for Through-Life Management that may be helped by use of MODAF are:

• Through-Life Management Planning (TLMP)

• Integrated Logistics Support

Figure 3-23 shows the key architectural products for Through-Life Management, and how this fits within the overall process, as shown in Figure 3-2.

- 43 -

Figure 3-23: MODAF Relationship to Through-Life Management


Requirements


Industry



View Set





Key

Through-Life Management Plan

SV-9

SV-8

AcV-2

SV-8

TV-2

TV-1

Integrated Logistic Support

OV-1c

NB: An OV-1c for the entire system will be produced byCustomer 1 within the URD. The Through-Life Management

workstream creates an instance of OV-1c pertaining tosustainability, maintainability etc of the system

OV-5

- 44 -

3.7.1 TLMP

The Through-Life Management Plan (TLMP) is initiated during the Concept Stage, and is revised and refined throughout the CADMID cycle, as shown in Figure 3-24 below. Also, the TLMP for each CADMID stage should include detailed planning and assumptions necessary for the next stage.

Figure 3-24: TLMP MODAF Views through CADMID

SV-9, the Systems Technology Forecast, shows how technology is expected to evolve in the short-, mid- and long-term. This informs the TLMP, showing whether there are any step-changes in available technology expected within the life of the system that will contribute to the system evolution strategy (see SV-8). If this is the case, upgrade costs need to be evaluated to keep the system up-to-date with the latest technology. An example SV-9 is shown in Figure 3-18. As previously mentioned, in the longer-term it is likely that a centrally maintained set of SV-9s will be available from the appropriate MOD authorities, from which an IPT will be able to cherry-pick the appropriate forecasts. However, in the short-term an IPT will need to create and maintain its own SV-9.

SV-8 Systems Evolution Description feeds into the Whole Life Costing by describing the transition of the new system into service (eg will this be an incremental release, building on functionality between IOC and FOC, or is the entire required functionality included in the first system release). This will have an affect on the development and maintenance costs for inclusion in the TLMP.

Figure 3-25: SV-8 Systems Evolution Description

Ongoing investment required over 60 months to implement

IG MG

SV-9

AcV-2

SV-8


SV-9

SV-8

AcV-2

SV-9

SV-8

AcV-2

Essential View


- 45 -

The TLMP also contains the detailed plans for the current phase. The AcV-2 SoS Acquisition Programmes View shall therefore be refined as part of this planning activity. Figure 3-5 shows an example AcV-2.

The TLMP is revised throughout the CADM stages as the solution, and therefore cost for development, support and upgrades, is defined in increasing granularity. As the industry supplier becomes more involved during the Demonstration and Manufacture Stages, the TLMP should be updated in consultation with the Industry supplier.

The TLMP shall also need to make reference to appropriate elements of the TV-1 and TV-2 that specify or forecast the regulations that are likely to apply to an equipment’s ultimate decommissioning and disposal. This is becoming increasingly important as more environmental legislation is being introduced and the hazards associated with more materials and processes are being highlighted.

The TLMP is closely related to the Capability Integration Plan (CIP), produced by Customer 2. The IPT should liase with the relevant Customer 2 to ensure that this integration occurs between the TLMP and CIP. The Customer 2 Deskbook (MODAF-M10-005) contains further information regarding the Views contained within the Capability Integration Plan.

3.7.2 Integrated Logistic Support

The focus on ILS begins during the Demonstration Stage (though time and effort is expended on Whole Life Costing (WLC) prior to both initial and main gates, when options for support solutions must be considered) and ILS work continues throughout CADMID. OV-1c Operational Performance Attributes is essential for use to articulate the availability, sustainability, reliability and maintainability of the system.


OV-5 Operational Activity Model, from the URD, informs the ILS approach.

For further activity on how MODAF supports the TLMP and ILS once they are actioned during the In-Service Stage, please refer to the Sustainment Deskbook (MODAF-M10-014).

- 46 -

4. Worked Example

This section describes a worked example of the Acquisition process as described in Section 3. The example illustrated is based in the ISTAR community, and its level of complexity is simplified in order to avoid the need to understand specific ISTAR systems and technologies. The example does not represent the UK's ISTAR assets; it contains a number of fictional systems and entities.

A similar ISTAR example has been replicated in each of the COI Deskbooks to provide a common thread of understanding across business functions and processes. This approach has been selected to demonstrate MODAF's ability to integrate people, processes, organisations, systems and equipments across the MOD.

It is envisaged that this section will be expanded to include further examples from the Acquisition Community as MODAF becomes more widely used, and so an increasing number of examples become available upon which to draw.

An additional worked example from the FRES IPT can be found in the Restricted Annex to this Deskbook (MODAF-M10-014).

4.1 ISTAR Worked Example Introduction

The ISTAR Worked Example for Acquisition begins at the point of forming the IPT. Customer 1 has completed their Capability Audit and reviewed the Capability Options. The Option chosen to fill an identified gap within the ISTAR Capability is to procure two new ISTAR assets, SPECS 2 and KESTREL. Separate IPTs are being established, one to procure KESTREL and the other to procure SPECS 2. This worked example follows the architecture work undertaken by the SPECS 2 IPT.

4.2 Project Management

4.2.1 Form the IPT

The SPECS 2 IPT is formed through the Future Business Group (FBG), and is provided with an initial AcV-2 developed by Customer 1 as part of their Capability Options planning:

- 47 -

Figure 4-1: AcV-2 provided by Customer 119

From the System of Systems and URD requirements there are certain standards that constrain the SPECS 2 IPT from the outset. These are collated in an initial TV-1 to set the boundaries for the IPT’s activities:

Figure 4-2: Initial TV-1 setting the standards and constraints for the IPT

4.2.2 Systems Engineering Management Plan

It can be seen from the standards in the initial TV-1 that the Systems Engineering Management Plan (SEMP) is a key document for the IPT to produce. This is begun

19 This AcV-2 shows 6 lines of development – the MODAF meta-model allows any number of lines of development to be included within the data for this View to accommodate the new 8 LoDs, or any additional future LoDs

ISTAR SYSTEMS

SPECS

DISP START

LOOKER

DISP START DISP FIN

NEMESIS

DISP START

People

Organisation

Sustainment

Equipment Training

Doctrine

LoDs

Pre-IG

IG to MG

MG to IOC

IOC to FOC

In Service

Disposal

Key to View

Project Phase

No outstanding issues

Manageable issues

Critical issues

LoD 'Hexagon'

2005 2020 2040

DISP FIN

SPECS 2

KESTREL

ISTAR SYSTEMS

SPECS

DISP START

LOOKER

DISP START DISP FIN

NEMESIS

DISP START

People

Organisation

Sustainment

Equipment Training

Doctrine

LoDs

Pre-IG

IG to MG

MG to IOC

IOC to FOC

In Service

Disposal

Key to View

Project Phase


Manageable issues

Critical issues

LoD 'Hexagon'

2005 2020 2040

DISP FIN

SPECS 2

KESTREL

MOD Sustainment guidelinesSPECS 2 and DLoD support

Ability to sustain capability

Sustainment & Logistics

US Guidance NotesSPECS 2 external US communication network interfaces

Communications/Networking

US Interoperability

MOD Systems Engineering Management Plan (SEMP)

SPECS 2 & interfacesSystems Engineering

MOD Strategy

ISTAR Acceptance ProcedureAll fielded capabilityAcceptance

SOPsAll fielded capabilityOperationsISTAR Governance

Standard/ PolicyApplicable ElementsServiceService Area






US Interoperability



MOD Strategy




- 48 -

during Concept, and will be updated and maintained throughout the CADMID lifecycle for the SPECS 2 system. During the IPT formation, the SEMP lays down how the IPT will be organised, including (amongst other things20) which MODAF Views the IPT intends to use for the analysis and design of the SPECS 2 system.

4.2.3 Initial Gate

At Initial Gate, the SPECS 2 Programme Manager will collate the SPECS 2 Business Case, containing the AcV-2 shown in Figure 4-1 and the TV-1 shown in Figure 4-2, along with the TLMP (see Through-Life Management Section 4.6) and the URD validation Views (or actual URD Views if available, see Requirements Management Section 4.3).

4.2.4 Manage Dependency Risks

As mentioned in the introduction to this worked example, the introduction of SPECS 2 is one part of the Capability deployment that includes the introduction of another ISTAR asset, KESTREL. There are therefore dependencies between the introduction of SPECS 2 and KESTREL, as without one or other being delivered into service, the required Capability will not be available.

The AcV-2 allows the IPT Programme Manager to monitor delivery timescales in conjunction with the other related deliveries, to monitor whether all the dependencies are on-track to deliver in conjunction with the SPECS 2 delivery.

20 For more information regarding the contents of a SEMP, an example can be found in the Integration Authority Systems Engineering Management Plan Volume 1 – Systems Engineering Process. File name: SEMP vol 1 0.C_1.1_1.doc File ref: IA/06/02/2701

- 49 -

Figure 4-3: AcV-2 showing dependency with delivery of KESTREL21

The Programme Manager can also use OV-5 and StV-5 to ensure that the scope of the delivery is well defined, and help reduce risks due to scope creep.

21 This AcV-2 shows 6 lines of development – the MODAF meta-model allows any number of lines of development to be included within the data for this View to accommodate the new 8 LoDs, or any additional future LoDs

ISTAR SYSTEMS

SPECS

DISP START

LOOKER

DISP START DISP FIN

NEMESIS

DISP START

People

Organisation

Sustainment

Equipment Training

Doctrine

LoDs

Pre-IG

IG to MG

MG to IOC

IOC to FOC

In Service

Disposal

Key to View

Project Phase


Manageable issues

Critical issues

LoD 'Hexagon'

2005 2020 2040

DISP FIN

SPECS 2

KESTREL

SPECS 2 must be delivered along with KESTREL to fill the Capability Gap left by the disposal of SPECS and LOOKER

- 50 -

Figure 4-4: OV-5 from the URD

OV-5 is part of the User Requirements Document, delivered before Main Gate submission. It clearly lays out the operational activities that SPECS 2 must support. Any request to support additional activities can be referred back to this View, and shown to be changes to the original scope.

Similarly StV-5, where available, shows the Capability gap being addressed by SPECS 2, as well as its intended implementation time frame. Any request to address other Capability gaps through delivery of SPECS 2 will also be changes to the original scope.

Figure 4-5: StV-5 showing the Capability gap to be addressed

Request SPECS 2 beprepared for Recce

of target area

Request launch ofSPECS 2

PJHQ BDE HQ ISTAR BASE STATION SPECS 2

Execute SPECS 2launch procedure

Provide suspectedtarget location

Provide SPECS 2search area co-

ordinates

Configure SPECS 2to provide video

footage/ data reports

Provide preferredtarget information

requirements

Request SPECS 2provide live video


Enter SPECS 2search area flight

profile

Moves to searcharea flight profile

Take off

Captures/ fuses livevideo footage/ data

reports

Relay video footage/data reportsProvide target status

Decide whether totake action

Strategic - PJHQ

Operational -JFHQ

Tactical -Brigade

Tactical - SpecialForces

InformationAcquistion

InformationManagement Effects

BISA

NEMESISSPECS

MILAN

CR2

FGA

EPOCH 1

LOOKER

Strategic - PJHQ

Operational -JFHQ

Tactical -Brigade




BISA

NEMESIS

CR2

FGA

EPOCH 2

Strategic - PJHQ

Operational -JFHQ

Tactical -Brigade




BISA

CR2

FGA

EPOCH 3

Any requests to fulfil requirements outside of the Information Acquisition Capability are changes to scope

- 51 -

4.2.5 Main Gate

The SPECS 2 Programme Manager collates the information from each workstream for the Main Gate submission, as for Initial Gate. There will be similar MODAF products within the Main Gate business case, but these contain increased detail from Initial Gate. The SRD, ITEAP (both described in Section 4.3), and TLMP (described in Section 4.6) are key deliverables at Main Gate.

There will be interoperability and compliance assurance undertaken by the IA (through IOCA) at Main Gate. These will look to ensure that adequate consideration has been taken to interoperability issues through OV-2 and SV-1 (shown in the Requirements Management section 4.3), appropriate standards have been included within the TV-1, and that the project’s MODAF architecture fits with existing architectures held in the Repository.

4.2.6 Place contract(s) to meet the SRD

The SRD development process is described in section 4.3.

4.2.7 Wind down of IPT

It is important that the Repository is kept up-to-date with the actual systems landscape in-service. Therefore once SPECS 2 is disposed of it must be removed from the repository leaving only those elements that remain. If this is not undertaken, it is possible that a future system may look to elements of SPECS 2 for information, causing re-work once it becomes apparent that these services are no longer available.

4.3 Requirements Management

The process for Requirements Management described here follows that used by the FRES IPT in development of their SRD. Initially, as was the case for FRES, IPTs may have to create their own Operational Views, as they will have existing URDs created prior to MODAF. Once MODAF is mature, the URD section within the Worked Example will no longer apply, as IPTs will receive MODAF compliant URDs with which to work.

4.3.1 Develop and Maintain User Requirements Document (URD)

The Customer 1 community has provided the URD for SPECS 2. However, as it was partly written prior to the implementation of MODAF, it does not contain all the MODAF Views required by the SPECS 2 Requirements Engineers in order for them to create their System architecture. The first step, therefore, is to validate the URD by creating the Operational Views required for the architecture.

The high-level OV-1 Views are available from the Capability Audit undertaken by Customer 1. For SPECS 2 are two operational scenarios: identification of target and information fusion. These are identified as Vignettes in the StV-6 provided by Customer 1. The process to produce the URD MODAF Views for the identify target Vignette is described below; the same process would be undertaken for each Vignette for every scenario within the URD.

- 52 -

A. IDENTIFY TARGET URD VIGNETTE

Figure 4-6: StV-6 within the URD shows the Operational Vignette

Figure 4-7: OV-1a showing identification of target Operational Vignette

The Performance Requirements for this Vignette are also extracted from the URD into the architecture, and viewed within an OV-1c:

Information Acquisition

Information Management

Effects

Recce X

Collate Intelligence X

Conduct Estimate X

Coordinate Plan X X X

Attack X X X

Recuperate X

Information AcquisitionInformation AcquisitionInformation Acquisition

Information ManagementInformation

ManagementInformation

ManagementEffectsEffectsEffects

RecceRecceRecce XXX

Collate IntelligenceCollate IntelligenceCollate Intelligence XXX

Conduct EstimateConduct EstimateConduct Estimate XXX

Coordinate PlanCoordinate PlanCoordinate Plan XXX XXX XXX

AttackAttackAttack XXX XXX XXX

RecuperateRecuperateRecuperate XXX

- 53 -

Figure 4-8: OV-1c showing Performance Requirements

The SPECS 2 Requirements Manager then decided to break down the Vignettes further through the creation of textual use cases for each scenario. These create a hybrid OV-1b, using use case documents containing richer information than a standard OV-1b:

Overview To identify the target, PJHQ directly task SPECS 2 to identify the target. SPECS 2, having then identified the target returns the identification data to both PJHQ and the common base station.

Primary Actors PJHQ

Supporting Actors

SPECS 2

ISTAR Base Station

Trigger PJHQ requests SPECS 2 be prepared for Recce of target area.

Preconditions Precondition

1 PJHQ executes SPECS 2 launch procedure.

Scenario Step

1 SPECS 2 takes off.

2 PJHQ provides SPECS 2 with search area co-ordinates.

3 PJHQ enters SPECS 2 search area flight profile.

4 SPECS 2 moves to search area flight profile.

5 PJHQ requests SPECS 2 identifies target.

15510152530Maximum time delay (seconds) viewing tasked location

SPECS 2 Video Delay

55567810Number of days required for maintenance

SPECS 2 Downtime

6444422Number of individual video channels provided

SPECS 2 Video Support

300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026

1200300Maximum number of km from ISTAR base station

4824Maximum number of hours for a single flight

Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure

- 54 -

6 PJHQ configures SPECS 2 to identify target.

7 SPECS 2 captures target video and data.

8 SPECS 2 relays video footage and data reports to PJHQ and

ISTAR Base Station.

9 PJHQ analyses video and data

10 ISTAR Base Station stores the video and data.

Postconditions Post condition

1 PJHQ decides whether to take action.

Extensions

Variations SPECS 2 could not perform operation so other ISTAR or organic assets are tasked.

Candidate Requirements

Remarks

Figure 4-9: Use Case document used as a hybrid OV-1b

The use case is then broken down into an OV-5 Operational Activity Model, taking the scenario steps above, and laying them over the organisations that undertake each step in the process:

Figure 4-10: OV-5 derived from Use Case document


of target area

PJHQ ISTAR BASE STATION SPECS 2


Configure SPECS 2to identify target


profile


Take off

Captures targetvideo and data

Relay video footage/data reports

Analyse video anddata


ordinates

Request SPECS 2identify tagret


Store video and data

1

2 3 4

5 6 7

89

10

- 55 -

The next step in the process is to translate the activities between nodes shown in the OV-5 translates into information flows. The OV-2 Operational Node Connectivity Description adds information regarding how the operational nodes share information.

Figure 4-11: OV-2 showing information flows

The needlines identified on the OV-2s highlight where there is a need to exchange information requirements. These are then translated into Information Exchange Requirements by the SPECS 2 architects, and recorded in an OV-3:

PJHQ SPECS 2

ENEMY

ISTAR BASESTATION

ISTAR INFORMATION

ISTAR INFORMATION

ISTAR TASK ORDER

1

2

3

4

ISTAR INFORMATION

- 56 -

Figure 4-12: OV-3 provides Information Exchange Requirements

4.3.2 Linkage between User and System Requirements

The SPECS 2 Requirements Engineers, using DOORS to manage their requirements, then set up in their MODAF architecture the SV-5 View, that pulls the operational activities as shown in the StV-6 in the URD, together with the system functions. This provides an ‘at-a-glance’ view to ensure that all the user requirements, in the activities, are provided for by one or more system functions.

Figure 4-13: SV-5 provides the linkage between the URD and SRD Views

Provision Of Real-Time VideoImagery

Provision Of Real-Time IRImagery

Monitoring Of Airspace

Timelapse Recording OfDesignated Areas

Communications Relay

Command & Control

Rec

ce

Co

llate

Inte

llige

nce

Con

duct

Est

imat

e

Co-

ordi

nat

e P

lan

Att

ack

Re-

cup

erat

e

X X

X X

X X

X

X X X X

X

X

X

X X

X

X X

X X

Op

erat

iona

l Act

ivit

y

SPECS 2 Functions



Effects

Recce X


Conduct Estimate X


Attack X X X

Recuperate X





RecceRecceRecce XXX






URD StV-6 Activities

- 57 -

4.3.3 Develop and Maintain System Requirements Document (SRD)

The first View to be created within the SRD is the SV-4 Systems Functional Description. The high-level system functions should directly correlate to the system functions shown in the SV-5 (as per Figure 4-13).

Figure 4-14: SV-4 Systems Functional Description

The next stage is to identify the System Interfaces. These should correlate to the information flow requirements, as shown in the OV-2 Views within the URD.

SPECS 2

ISTAR Base Station

Provision OfReal-Time Visual

Imagery

Provision OfReal-Time IR

Imagery

CommunicationsRelay

Monitoring OfAirspace

Command &Control

ManageBandwidth

Rx Orders Tx Orders Process OrdersRecord MessageMeta Dats

ManageBandwidth

Tx Orders Rx Orders

- 58 -

Figure 4-15: SV-1 showing the system interfaces

Each interface needline relates to an information needline within the OV-2. These System to System connections are drawn together in the SV-3 Systems-Systems Matrix, which completes the System View set for Initial Gate submission:

SPECS 2

Video Recorder

Command &Control

Data Analysis

CommunicationsRelay

ISTAR Base Station

Command &Control

Aircraft Carrier

PJHQ

US JSTAR

CommunicationsRelay

Command &Control

CommunicationsRelay

- 59 -

Figure 4-16: SV-3 Systems-Systems Matrix

Post-Initial Gate, the interface requirements are specified in more detail.

The ports used for each System Interface are defined on an SV-2a System Port Specification View. In this case, there is a need for SPECS 2 to transfer information with the US JSTAR asset. The SPECS 2 team therefore first of all obtain the SV-2a from the US JSTAR team:

X

Systems SA

TC

OM

BO

WM

AN

BD

E H

Q C

OM

MS

PJH

Q C

OM

MS

Air

craf

t C

arri

er

ISTA

R B

ase

Sta

tion

NE

ME

SIS

SP

EC

S 2

KE

STR

EL

US

JSTA

R

SATCOM

BOWMAN

BDE HQ COMMS

PJHQ COMMS

Aircraft Carrier

ISTAR Base Station

NEMESIS

SPECS 2

KESTREL

USJSTAR

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X X X

- 60 -

Figure 4-17: SV-2a for US JSTAR asset

From this, they can then specify the port requirements for SPECS 2 in their own SV-2a for inclusion in the SRD:

Figure 4-18: SV-2a for SPECS 2 SRD

These two can then be consolidated in the URD in the SV-2b System to System Protocol Stack. The SV-2b will show that the interoperability considerations have

US JSTARInformation

Fusion System

ReceiverPort

ETHERNETLOS COMMS

HTTPTCP/IP

FTPFusion Appl

TransmitterPort

ETHERNETLOS COMMS

HTTPTCP/IP

FTPFusion Appl

SPECS 2Receiver

SPECS 2Transmitter

ReceiverPort

ETHERNETLOS COMMS

HTTPTCP/IP

TransmitterPort

ETHERNETLOS COMMS

HTTPTCP/IP

Link ApplLink Appl

- 61 -

been taken into account – particularly for the Main Gate submission and assurance by IOCA.


The final stage in the interface specification is to link the system interfaces to the organisational information exchange requirements defined in the URD (through the OVs), through the use of SV-2c System Connectivity Clusters. This shows the end-to-end connectivity to satisfy one or more needlines as identified in OV-2a. These diagrams can also be used to model the implementation of kill chains:

SPECS 2Receiver

SPECS 2Transmitter

ReceiverPort

ETHERNETLOS COMMS

HTTPTCP/IP

TransmitterPort

US JSTARInformation

Fusion System

ReceiverPort

TransmitterPort

ETHERNETLOS COMMS

HTTPTCP/IP

SPECS 2 Transmitt

SPECS 2 Receive

- 62 -


The Information Exchange Requirements are then given more detail in the SV-6 Systems Data Exchange Matrix. This provides richer information specific to the SPECS 2 system, specifying all of the data exchanges, in this case between SPECS 2 and the ISTAR Base Station Command and Control:


The final part of the SRD specification for Main Gate is to determine the performance requirements. These build on the Operational Performance Requirements given in the URD through OV-1c, but at a system level:

Line Of Sight (LOS) Comms

SPECS 2 USJSTAR

SPECS 2Receiver

SPECS 2Transmitter

ReceiverPort

TransmitterPort

US JSTARInformation

Fusion System

ReceiverPort

TransmitterPort

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

� ��

��!��

"��

��#��"

��

$

�� "

��

��!��"��

��#��"��

%

��&!��&��

��!��"��

��#��"��

'

��"

��

��!��"��

��#��"��

(

��"

��

��!��"��

��#��"��

#

�� #��)��#��"��!��

��"��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

� ��

��!��

"��

��#��"

��

$

�� "

��

��!��"��

��#��"��

%

��&!��&��

��!��"��

��#��"��

'

��"

��

��!��"��

��#��"��

(

��"

��

��!��"��

��#��"��

#

�� #��)��#��"��!��

��"��

�

��

��

- 63 -

Figure 4-22: SV-7 System Performance Parameters Matrix

4.3.4 Integrated Testing, Evaluation and Acceptance

The OV-1c from the URD, along with the SV-3 and the SV-7 developed for the SRD form the basis for the Integrated Testing, Evaluation and Acceptance Plan (ITEAP). The ITEAP for SPECS 2 also includes the StV-2 produced by Customer 1, as this was available for the IPT with performance attributes. The StV-2, with its performance attributes, for SPECS 2 is shown below:

��*+��

*!#,��-��.�� #/#

�!#��00.�1��-!��*+�* 1�233��

��#��-��..��

(/�

��4�-.�,#'4#,'5��3��*��.�-2 ��#��*��*��

'/�

�2�.6 �3��*��.�-2 ��

#,� ��3�� 7 '/#

��8 +��

0� ��.�,��020 �� -�� *�� 2��7

��*��-7.�.��/�

0� ��..��%��020 �� .3��*��2��7

.��*.

0� ��.

*!

�!

��

(,��020�-�� .3��.� �0�

%,,��020. � 2.�1��-�� 2��7

�� 2.�-��

��/#

$,��#��9�� #/�

#��.0�..�� #��.0� �� /�

��

��!��

��*+��

*!#,��-��.�� #/#

�!#��00.�1��-!��*+�* 1�233��

��#��-��..��

(/�

��4�-.�,#'4#,'5��3��*��.�-2 ��#��*��*��

'/�

�2�.6 �3��*��.�-2 ��

#,� ��3�� 7 '/#

��8 +��

0� ��.�,��020 �� -�� *�� 2��7

��*��-7.�.��/�

0� ��..��%��020 �� .3��*��2��7

.��*.

0� ��.

*!

�!

��

(,��020�-�� .3��.� �0�

%,,��020. � 2.�1��-�� 2��7

�� 2.�-��

��/#

$,��#��9�� #/�

#��.0�..�� #��.0� �� /�

��

��!��

- 64 -

Figure 4-23: StV-2 Capability Functions with Performance Attributes

Performance requirements such as the Range and Duration were included as part of the ITEAP, to confirm that the required Capability has been delivered.

4.4 Systems / Technology

4.4.1 Identify technology and procurement options

The StV-3 Capability Phasing View from Customer 1 for SPECS 2 shows that a new ISTAR Base Station is being introduced during the time that SPECS 2 is in service:

Information Acquisition Information Management Effects

1. StrategicRange: 120km - 1000kmDuration: 24hrs

1. Analysis 1. TargetingAccuracy: 10m

2. OperationalRange: 20km - 120kmDuration: 20hrs

2. Fusion 2. Plan Engagement

3. TacticalRange: 0km - 20kmDuration: 16hrs

3. Quality Assurance 3. Conduct Engagement

4. Dissemination 4. Battle Damage Assessment









Information AcquisitionInformation AcquisitionInformation Acquisition Information ManagementInformation ManagementInformation Management EffectsEffectsEffects



1. Analysis1. Analysis 1. TargetingAccuracy: 10m1. TargetingAccuracy: 10m



2. Fusion2. Fusion 2. Plan Engagement2. Plan Engagement



3. Quality Assurance3. Quality Assurance 3. Conduct Engagement3. Conduct Engagement

4. Dissemination4. Dissemination 4. Battle Damage Assessment4. Battle Damage Assessment

- 65 -

Figure 4-24: StV-3 Capability Phasing

Therefore when considering the technology options, interoperability with both NEMESIS ISTAR Base Station and the ISTAR Base Station must be considered.

This is considered along with the SV-9 Technology Forecast, which shows how technology will change during the life of the SPECS 2 system:

Figure 4-25: SV-9 Technology Forecast

Along with the SV-9, the TV-2 shows how standards are likely to evolve. The two taken together provide a long-term view of changes, to which the chosen solution for SPECS 2 will need to adapt.

Capability Functions Epoch 1 Epoch 2 Epoch 3


Strategic ISTAR NEMESIS NEMESIS

Operational ISTAR SPECS SPECS 2 SPECS 2

Tactical ISTAR LOOKER KESTREL KESTREL


Analysis NEMESIS NEMESISISTAR BASE STATION

ISTAR BASE STATION

Fusion NEMESIS NEMESISISTAR BASE STATION

ISTAR BASE STATION

Quality Assurance NEMESIS NEMESISISTAR BASE STATIN

ISTAR BASE STATION

Dissemination BOWMAN, SAT BOWMAN, SAT

Effects

Targeting LOOKER, SPECS KESTREL, SPECS 2

KESTREL, SPECS 2

Plan Engagement BISA BISA

Conduct Engagement CR2, MILAN, FGA CR2, FGA CR2, FGA

BDA FGA, SAT FGA, SAT FGA, SAT








ISTAR BASE STATION


ISTAR BASE STATION


ISTAR BASE STATION


Effects


KESTREL, SPECS 2




Capability FunctionsCapability FunctionsCapability Functions Epoch 1Epoch 1Epoch 1 Epoch 2Epoch 2Epoch 2 Epoch 3Epoch 3Epoch 3

Information AcquisitionInformation Acquisition

Strategic ISTARStrategic ISTAR NEMESISNEMESISNEMESIS NEMESISNEMESISNEMESIS

Operational ISTAROperational ISTAR SPECSSPECSSPECS SPECS 2SPECS 2SPECS 2 SPECS 2SPECS 2SPECS 2

Tactical ISTARTactical ISTAR LOOKERLOOKERLOOKER KESTRELKESTRELKESTREL KESTRELKESTRELKESTREL

Information ManagementInformation Management

AnalysisAnalysis NEMESISNEMESISNEMESIS NEMESISISTAR BASE STATION

NEMESISISTAR BASE STATION


ISTAR BASE STATIONISTAR BASE STATIONISTAR BASE STATION

FusionFusion NEMESISNEMESISNEMESIS NEMESISISTAR BASE STATION




Quality AssuranceQuality Assurance NEMESISNEMESISNEMESIS NEMESISISTAR BASE STATIN

NEMESISISTAR BASE STATIN



DisseminationDissemination BOWMAN, SATBOWMAN, SATBOWMAN, SAT BOWMAN, SATBOWMAN, SATBOWMAN, SAT

EffectsEffects

TargetingTargeting LOOKER, SPECSLOOKER, SPECSLOOKER, SPECS KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

Plan EngagementPlan Engagement BISABISABISA BISABISABISA

Conduct EngagementConduct Engagement CR2, MILAN, FGACR2, MILAN, FGACR2, MILAN, FGA CR2, FGACR2, FGACR2, FGA CR2, FGACR2, FGACR2, FGA

BDABDA FGA, SATFGA, SATFGA, SAT FGA, SATFGA, SATFGA, SAT FGA, SATFGA, SATFGA, SAT

SPECS 2 must interoperate with both the NEMESIS ISTAR Base Station in Epoch 2, and the ISTAR Base Station in Epoch 3

Service Orientated Networking

Virtual Networks (including VLAN)

Fixed Point To Point Networks

Networking philosophy

XP

Medium Term3-6 years

Not disclosedXPWindows Version

180GB60GBDefault storage capacity for Personal Computer

10Ghz Processor2Ghz ProcessorDefault digital signal processor speeds

Long Term6-9 years

Short Term1-3 years

Area





XP





Long Term6-9 years

Short Term1-3 years

Area

- 66 -

Figure 4-26: TV-2 Technical Standards Forecast

4.4.2 Demonstrate ability to deliver integrated capability

The Systems and Technology workstream will draw on the Views created within the URD and SRD to demonstrate integration.

The OV-2 (in Figure 4-11) and SV-6 (in Figure 4-21) show how the system meets interoperability requirements, communicating with the ISTAR Base Station and the Data Exchanges that specify this data link.

The OV-3 (in Figure 4-12) and SV-1 (in Figure 3-11) show the Information Exchange Requirements, and how connections will be inserted between systems to meet these.

The OV-1c (in Figure 4-8) and the SV-7 (in Figure 4-22) show the required operational and system performance factors that are being taken into account when specifying the system.

4.4.3 Technology Insertion

The forecast information within the SV-9Technology Forecast and TV-2 Technical Standards Forecast is maintained, so that it will highlight any likely issues in the future. These would then be raised with Customer 1, for them to initiate any required upgrades or improvements.

4.5 Industry / Suppliers

4.5.1 Involve Industry

The SPECS 2 IPT decide to involve industry from the outset, in order that they can best exploit the technologies available. They take the OV-1a (as per Figure 4-7) and OV-1c (as per Figure 4-8) for initial industry consultation, along with the OV-2 (in Figure 4-11).

During the consultation with industry, the IPT is informed that there is a significant cost increase to specify that the flight time needs to be 24hrs, prior to 2027. This would require a jump to unproven technology, however the industry partners believed that this would be proven by 2027. On referring back to Customer 1, it is agreed that a flight time of 20hrs will provide the required level of capability until such time as the

WAN: SDH TechnologyLAN: Gigabit Ethernet Backbone

XMIv2.1


WAN: PDH TechnologyMOD Communications/ Networking Policy

MOD System Of Systems Engineering Management Plan (SEMP)

Local Systems Engineering Management Plan (SEMP)

MOD Systems Engineering Standards

MODAF v2.0MODAF v1.0XMI v2.0

MODAF

Long Term6-9 years

Short Term1-3 years

Standard/ Policy


XMIv2.1







MODAF

Long Term6-9 years

Short Term1-3 years

Standard/ Policy

- 67 -

new technology is proven, and so the requirement is lowered to 20hrs to achieve the significant cost reduction this affords.

Similarly, with regards to the number of video channels required, industry inform that it is currently possible to obtain 4 video channels using the same technology as would be used to provide 2 channels, therefore this requirement is increased to take advantage of the technology available.

Figure 4-27: Modified OV-1c after industry consultation

4.5.2 System Synthesis

The SRD Views described in Section 4.3.3 form the basis for prototyping with industry, along with considerations from the SV-9 and TV-2 forecasts, shown in Figure 4-25 and Figure 4-26 respectively.

4.5.3 Negotiate Contract

The SPECS 2 contract negotiations are held, using the architectural model developed through the URD validation and the SRD development. The technical findings from the initial industry consultation also give the negotiators a good grounding in the technical possibilities to drive out the risk from the contract.

4.5.4 Deliver the solution

The chosen supplier agrees in the contract negotiations to provide high-level MODAF Views as part of their solution delivery. These Views are fed back to the IPT, who consolidate them for inclusion into MODAR.

4.5.5 Carry out any agreed upgrades or improvements

Upgrades and improvements are undertaken as Customer 2 identifies them, and as agreed in the contract, shown in the TLMP (see next section). The increases in available technology are also included in the upgrade plan: for example the increase in flight duration to 24hrs in 2027, highlighted during initial industry involvement.


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

20

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

20

2026



Target2025Measure

- 68 -

4.6 Through-Life Management

4.6.1 TLMP

The SPECS 2 IPT initiates the Through-Life Management Plan (TLMP) in the Concept Stage. The first TLMP View to be developed is the SV-9 Technology Forecast, which is developed in conjunction with the Systems and Technology workstream. The SV-9 is shown in Figure 4-25.

For the Initial Gate review, the SV-8 Systems Evolution Description is developed within the SPECS 2 architecture. This shows the planned upgrade and improvement path for SPECS 2, and its in-service life span:


This provides the development and maintenance costs for inclusion within the Whole-Life Costing for the TLMP.

The TLMP also contains the detailed planning for each Stage. This is taken from the AcV-2, managed within the Project Management workstream (in conjunction with the Through-Life Management team), and an example is shown in Figure 4-3.

4.6.2 Integrated Logistic Support

The ILS team use the architecture to help articulate their requirements. They pull together ILS requirements within an OV-1c, to show the availability, maintainability and reliability requirements for the system:

Figure 4-29: OV-1c articulating ILS requirements

4.7 UML Example

The example in this section is a notional ISTAR example, and is not related to any actual ISTAR work. It is included to provide an alternative to the example Views provided elsewhere in this document, showing the use of UML for View representation.

Release 1

SPECS 2

Release 2 Release 3 Release 4 DisposalPlanning

Q1 2025 Q2 2026 Q4 2028 Q4 2030 Q4 2040

InitialRelease Release +

UrgentAdditionalRequirementsIdentified AtAcceptance

Release + DesirableAdditional RequirementsIdentified At Acceptance Release + Required

Situational Updates Planning for disposal/exension of designed life

7

45

20

2027

6

40

18

2028

5

35

15

2029

5

34

14

2030

SPECS 2 Reliability

SPECS 2 Maintainability

SPECS 2 Availability

Attribute

8

50

30

2026

510Number of days unplanned downtime

3050Support personnel required to maintain SPECS 2

1045Number of days down time

Target2025Measure

7

45

20

2027

6

40

18

2028

5

35

15

2029

5

34

14

2030

SPECS 2 Reliability



Attribute

8

50

30

2026




Target2025Measure

- 69 -

In this example, the OV-4 Organisational Relationships Chart is first drawn out, containing actors to show the various relationships between ISTAR roles.

Figure 4-30: UML Version of OV-4 Organisational Relationships Chart

High-level activities are then related to the roles in the OV-4 through a use case diagram, as the beginnings of developing the OV-5:

cd OV-4

Collection Manager ISTAR Coordinator

Intelligence Manager

Commander

Intelligence Consumer

Planner

«organisation»collection

source

+superior officer

+manager

+organic col lection source

+customer

+inorganic col lection source

+customer

+overseer+overseer

The generalisation from the intelligence manager shows that the

inorganic collection source organisation will also fulfil another

instance of the Intelligence Manager role.

- 70 -

Figure 4-31: UML Use Cases derived from the OV-4

The information contained in these Use Cases is then broken down to define the operational activities, recorded in the OV-5 Operational Activity Diagram. Note the use of the actors, which can also be organisations in the swimlanes, and the absence of any notion of automated functionality. Sequencing bars represent concurrent activities and decision points providing mutually exclusive decisions. Objects are used to capture the information products which will equate to rows in the OV-3 Information Exchange Requirements. Each activity can be reworded in terms of “The User Shall” to imply candidate functional requirements.

ud Use Case Diagram

Collection Manager

Maintain Collection Plan

Generate RFI

Task Organic Collection Sources

Monitor Organic Collection Sources

ISTAR Coordinator


Monitor ISTAR Process

Identify Information Collection

Requirements

Deceminate Intelligence

Commander

Specify Directiv es


Receiv e Intelligence

Collect Organic Intelligence

Collect Inorganic Intelligence


source

«extend»

«extend»

«extend»

Besides human actors, it is quite acceptable and quite common to use organisations as actors

- 71 -

ad Activ ity Diagram

ISTA

R C

oord

inat

orC

olle

ctio

n M

anag

er


Requirements

:Intelligence Collection Plan

Determine how information can

be collected

Identify required

collection capability

Allocate capability

to task

:Battlespace Management

Information Source

Identify w hat information should

be collected

Identify w hen information needs to be

collected

Raise RFI

:Intelligence Estimate

:IPB

Monitor Task

Update plan

RFI

Update Plan

Monitor Response

Notify Intelligence

Manager


Notify Intelligence Manager and Collection

Manager

[inorganic]

[organic]

[else]

[does not meetrequirement]

[else]


Figure 4-32: UML representation of an OV-5 Operational Activity Model

An SV-4 Systems Functional Description would then be developed as the system moved into the SRD development phase. A hybrid SV-4 is shown below, depicting how part of the OV-5 could be implemented in a notional ISTAR system that allow collaborative working between the Collection Manager and the ISSTAR Coordinator. This is a hybrid View, as it contains information pertaining to interfacing systems, which is not required in a standard SV-4.

Most of the activity takes place in the system of interest with assumptions placed against interfacing systems. Any transitions that cross a swim lane indicate a potential interface or HCI. Care should be taken with these diagrams to only show the logical activities required and not to drive down into design. Use notes to show where there may be alternative solutions.

- 72 -

ad SV4

Situ

atio

n A

war

enes

s S

yste

mIS

TAR

Sys

tem

ISTA

R C

oord

inat

orC

olle

ctio

n M

ana

ger

Display Collection

Requirements

Input collection

Tasks

Update Task List

Display Task List

Prov ide Geographical

information

Display Geographical

Locations

battlespace topography

Select Geographical

Location corrisponding

to task

Display av ailable

assetsRequest Geographical

Information

Prov ide av ailable

asstes

Request assets for

geographical location

asset list[fi l tered]

Display task list M ap

Assets to Tasks

Allocate Assets to

Tasks

Update collection

plan

Update asset status

Design Consideration:T hese two exchanges could be achi ved wi thin a single exchange.

Figure 4-33: UML representation of a hybrid SV-4 Systems Functionality Description

- 73 -

5. Document Maintenance

It is intended that the MODAF product suite will evolve through time in order to reflect learning from experience, changes to the MOD’s processes and the evolution of architectural best practice. A change control process will be established for all MODAF products and suggestions upon the refinement / improvement of this and related products is welcome. The formal MODAF change control process shall be published in due course. In the interim, suggestions should be forwarded to the MODAF point of contact, EC CCII Cap Strat, located in Main Building.

Acknowledgements

This document has been developed by MODAF partners as part of the MODAF 1.0 Baseline that is being prepared by DEC CCII supported by the IA. Other organisations that have contributed to the content and / or review of this document are:

• DII IPT

• FRES IPT

• CSIS IPT

• DCBA IPT

• Satcom IPT

• Sea Technology Group (DPA)

• DCSA

• PDG Standardisation

The role of Industry is also acknowledged in providing support to the MODAF development and in reviewing the MODAF products prior to its release. The authors acknowledge Hi-Q Systems for providing the UML Views used in the Worked Example section of this document.

MODAF partners

The MODAF 1.0 Baseline has been developed for the MOD by MODAF partners. The MODAF partners team leaders for this work have been:

Fariba Hozhabrafkan

Cornwell Management Consultants Home Barn Court The Street Effingham Surrey

KT24 5LG

Tel: 01372 456086

Dave Mawby

PA Consulting Group 123 Buckingham Palace Road London SW1W 9SR

Tel: 020 7730 9000

- 74 -

Appendix A: Large-Scale Diagrams

This section provides large-scale versions of the diagrams included in this document, for ease of reading.

A.1 Process Diagrams

The following pages contain the process diagrams as shown at the start of each sub-section within section 3, to a larger scale than was possible within the text.

- 75 -

Figure 3-3: Key MODAF Relationship to Project Management Activities


Form the IPT

URD

View Set

Essential View producedoutside this workstreamTV-1

InitialGate




TLMPAcV-2URD

SV-1OV-2

Managedependency

risks

OV-5StV-5

SRDURD

MainGate

SRD ITEAPTLMP

Placecontract(s) tomeet the SRD

SRD

URD

Wind down ofIPT

Key

TV-1

SV-1 TV-1OV-2

AcV-2

- 76 -

Figure 3-6: MODAF relationship to Requirements Management


View Set





Key

User Requirements Document (URD)

StV-6

OV-1

OV-2

OV-2

OV-3

OV-5

TV-1

OV-3

OV-5

TV-1

Linkage between user andsystem requirements SV-5

SV-4

OV-5

System Requirements Document (SRD)URD

SV-1

SV-2

SV-3

SV-4

SV-6

SV-7

TV-1

NB: The TV-1 contained inthe SRD will be at a lowerlevel than that in the URD.This more detailed TV-1 iscreated by the IPT, basedon the high-level TV-1 in

the URD.

SV-2

SV-6

SV-7

TV-1

Integrated Testing, Evaluation and AcceptancePlan

StV-2

OV-1c

SV-7

SV-3

SRD

OV-7 OV-7

- 77 -

Figure 3-17: MODAF Relationship to System / Technology workstream


View Set





Key

Identify technology and procurement options

StV-3

TV-1

SV-9

TV-2

SV-9

TV-2

updated

updated

Demonstrate ability to deliverintegrated capability

OV-2

OV-3

SV-1

SV-7

SV-6

OV-1c

SV-7

Technology insertion

SV-9

TV-2

- 78 -

Figure 3-19: MODAF Relationship to Industry workstream


View Set





Key

Involve Industry

OV-1

OV-2

System SynthesisSV-9

TV-2

SRD

Negotiate Contract

URD

SRD

Deliver Solution

Carry out any agreedupgrades or improvements

StV-2

StV-3

SV-8

- 79 -

Figure 3-23: MODAF Relationship to Through-Life Management


View Set





Key

Through-Life Management Plan

SV-9

SV-8

AcV-2

SV-8

TV-2

TV-1

Integrated Logistic Support

OV-1c

NB: An OV-1c for the entire system will be produced byCustomer 1 within the URD. The Through-Life Management

workstream creates an instance of OV-1c pertaining tosustainability, maintainability etc of the system

OV-5

- 80 -

A.2 View Examples

The following pages contain all of the Views used to illustrate the text, in a larger size so that they can be easily read. However, it is important to note that these Views are examples only, containing dummy data. They are intended to show the type of information available in each View.

- 81 -

Figure 3-4: TV-1 Technical Standards Profile


Standard / Policy




Operating Systems


Data Interchange



Standard / Policy




Operating Systems


Data Interchange


Service AreaService AreaService Area ServiceServiceService System ElementsSystem

ElementsSystem

ElementsStandard / PolicyStandard / PolicyStandard / Policy

Data TransferData TransferData Transfer TCP/IPTCP/IPTCP/IP BOWMANBOWMANBOWMAN IP v6IP v6IP v6

MessagingMessagingMessaging EmailEmailEmail BISA / CommsBISA / CommsBISA / Comms




Operating SystemsOperating SystemsOperating Systems

WorkstationsWorkstationsWorkstations BISA / Control Stations



Data InterchangeData InterchangeData Interchange

InteroperabilityInteroperabilityInteroperability OMG XMI 2.1OMG XMI 2.1OMG XMI 2.1

- 82 -

Figure 3-5: AcV-2 SoS Acquisition Programmes

- 83 -

Figure 3-8: SV-5 links the URD and SRD

- 84 -

Figure 3-10: SV-4 Systems Functionality Description

- 85 -

Figure 3-11: SV-1 Systems Interface Description

- 86 -

Figure 3-12: SV-2a System Port Specification

- 87 -


- 88 -


- 89 -

Figure 3-15: SV-3 System-to-System Matrix

- 90 -


- 91 -

Figure 3-18: SV-9 Systems Technology Forecast

- 92 -

Figure 3-20: OV-1a High Level Operational Graphic

- 93 -

Figure 3-21: OV-1b High Level Operational Description

The Assess Battle Damage process starts when the target has been engaged. An initial assessment is made using nearby FRES Scout. This information is passed up to FRES IFS. FRES IFS will order further BDA if necessary (for example if the first assessment was inconclusive). If necessary a further application of effect may be ordered through FRES PM, followed by a further BDA. Once the battle damage assessment has been completed the FRES roles continue with their original tasks.

- 94 -


Attribute Measure Value As - Is Epoch 1 Epoch 2 Target Operational Tempo

Rate of Advance for an Armoured Brigade against light resistance

20 km/day 40 km/day 60 km/day 80 km/day

Synchronisation of Effects

Simultaneous rounds on impact delivered by an Arty Bty

30 rounds 40 rounds 60 rounds 100 rounds

Sortie Rate Period to re-fuel and re-arm an aircraft

4 hours 3 hours 2 hours 1 hours

- 95 -


- 96 -


- 97 -

A.3 Worked Example Diagrams

The diagrams on the next few pages are those included in the Worked Example in Section 4.

- 98 -

Figure 4-1: AcV-2 provided by Customer 1

ISTAR SYSTEMS

SPECS

DISP START

LOOKER

DISP START DISP FIN

NEMESIS

DISP START

People

Organisation

Sustainment

Equipment Training

Doctrine

LoDs

Pre-IG

IG to MG

MG to IOC

IOC to FOC

In Service

Disposal

Key to View

Project Phase


Manageable issues

Critical issues

LoD 'Hexagon'

2005 2020 2040

DISP FIN

SPECS 2

KESTREL

ISTAR SYSTEMS

SPECS

DISP START

LOOKER

DISP START DISP FIN

NEMESIS

DISP START

People

Organisation

Sustainment

Equipment Training

Doctrine

LoDs

Pre-IG

IG to MG

MG to IOC

IOC to FOC

In Service

Disposal

Key to View

Project Phase


Manageable issues

Critical issues

LoD 'Hexagon'

2005 2020 2040

DISP FIN

SPECS 2

KESTREL

- 99 -

Figure 4-2: Initial TV-1 setting the standards and constraints for the IPT






US Interoperability



MOD Strategy









US Interoperability



MOD Strategy




- 100 -

Figure 4-3: AcV-2 showing dependency with delivery of KESTREL

ISTAR SYSTEMS

SPECS

DISP START

LOOKER

DISP START DISP FIN

NEMESIS

DISP START

People

Organisation

Sustainment

Equipment Training

Doctrine

LoDs

Pre-IG

IG to MG

MG to IOC

IOC to FOC

In Service

Disposal

Key to View

Project Phase


Manageable issues

Critical issues

LoD 'Hexagon'

2005 2020 2040

DISP FIN

SPECS 2

KESTREL

SPECS 2 must be delivered along with KESTREL to fill the Capability Gap left by the disposal of SPECS and LOOKER

- 101 -

Figure 4-4: OV-5 from the URD


of target area

Request launch ofSPECS 2

PJHQ BDE HQ ISTAR BASE STATION SPECS 2


Provide suspectedtarget location


ordinates

Configure SPECS 2to provide video


Provide preferredtarget information

requirements

Request SPECS 2provide live video



profile


Take off

Captures/ fuses livevideo footage/ data

reports

Relay video footage/data reportsProvide target status


- 102 -

Figure 4-5: StV-5 showing the Capability gap to be addressed

Strategic - PJHQ

Operational -JFHQ

Tactical -Brigade




BISA

NEMESISSPECS

MILAN

CR2

FGA

EPOCH 1

LOOKER

Strategic - PJHQ

Operational -JFHQ

Tactical -Brigade




BISA

NEMESIS

CR2

FGA

EPOCH 2

Strategic - PJHQ

Operational -JFHQ

Tactical -Brigade




BISA

CR2

FGA

EPOCH 3

Any requests to fulfil requirements outside of the Information Acquisition Capability are changes to scope

- 103 -

Figure 4-6: StV-6 within the URD shows the Operational Vignette



Effects

Recce X


Conduct Estimate X


Attack X X X

Recuperate X





RecceRecceRecce XXX






- 104 -

Figure 4-7: OV-1a showing identification of target Operational Vignette

- 105 -

Figure 4-8: OV-1c showing Performance Requirements


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure

- 106 -

Figure 4-10: OV-5 derived from Use Case document


of target area

PJHQ ISTAR BASE STATION SPECS 2


Configure SPECS 2to identify target


profile


Take off

Captures targetvideo and data

Relay video footage/data reports

Analyse video anddata


ordinates

Request SPECS 2identify tagret


Store video and data

1

2 3 4

5 6 7

89

10

- 107 -

Figure 4-11: OV-2 showing information flows

PJHQ SPECS 2

ENEMY

ISTAR BASESTATION

ISTAR INFORMATION

ISTAR INFORMATION

ISTAR TASK ORDER

1

2

3

4

ISTAR INFORMATION

- 108 -

Figure 4-12: OV-3 provides Information Exchange Requirements

- 109 -

Figure 4-13: SV-5 provides the linkage between the URD and SRD Views

Provision Of Real-Time VideoImagery

Provision Of Real-Time IRImagery

Monitoring Of Airspace

Timelapse Recording OfDesignated Areas

Communications Relay

Command & Control

Rec

ce

Co

llate

Inte

llige

nce

Con

duct

Est

imat

e

Co-

ordi

nat

e P

lan

Att

ack

Re-

cup

erat

e

X X

X X

X X

X

X X X X

X

X

X

X X

X

X X

X X

Op

erat

iona

l Act

ivit

y

SPECS 2 Functions



Effects

Recce X


Conduct Estimate X


Attack X X X

Recuperate X





RecceRecceRecce XXX






URD StV-6 Activities

- 110 -

Figure 4-14: SV-4 Systems Functional Description

SPECS 2

ISTAR Base Station

Provision OfReal-Time Visual

Imagery

Provision OfReal-Time IR

Imagery

CommunicationsRelay

Monitoring OfAirspace

Command &Control

ManageBandwidth

Rx Orders Tx Orders Process OrdersRecord MessageMeta Dats

ManageBandwidth

Tx Orders Rx Orders

- 111 -

Figure 4-15: SV-1 showing the system interfaces

SPECS 2

Video Recorder

Command &Control

Data Analysis

CommunicationsRelay

ISTAR Base Station

Command &Control

Aircraft Carrier

PJHQ

US JSTAR

CommunicationsRelay

Command &Control

CommunicationsRelay

- 112 -

Figure 4-16: SV-3 Systems-Systems Matrix

X

Systems SA

TC

OM

BO

WM

AN

BD

E H

Q C

OM

MS

PJH

Q C

OM

MS

Air

craf

t C

arri

er

ISTA

R B

ase

Sta

tion

NE

ME

SIS

SP

EC

S 2

KE

ST

RE

L

US

JST

AR

SATCOM

BOWMAN

BDE HQ COMMS

PJHQ COMMS

Aircraft Carrier

ISTAR Base Station

NEMESIS

SPECS 2

KESTREL

USJSTAR

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X X X

- 113 -

Figure 4-17: SV-2a for US JSTAR asset

US JSTARInformation

Fusion System

ReceiverPort

ETHERNETLOS COMMS

HTTPTCP/IP

FTPFusion Appl

TransmitterPort

ETHERNETLOS COMMS

HTTPTCP/IP

FTPFusion Appl

- 114 -

Figure 4-18: SV-2a for SPECS 2 SRD

SPECS 2Receiver

SPECS 2Transmitter

ReceiverPort

ETHERNETLOS COMMS

HTTPTCP/IP

TransmitterPort

ETHERNETLOS COMMS

HTTPTCP/IP

Link ApplLink Appl

- 115 -


SPECS 2Receiver

SPECS 2Transmitter

ReceiverPort

ETHERNETLOS COMMS

HTTPTCP/IP

TransmitterPort

US JSTARInformation

Fusion System

ReceiverPort

TransmitterPort

ETHERNETLOS COMMS

HTTPTCP/IP

SPECS 2 Transmitt

SPECS 2 Receive

- 116 -


Line Of Sight (LOS) Comms

SPECS 2 USJSTAR

SPECS 2Receiver

SPECS 2Transmitter

ReceiverPort

TransmitterPort

US JSTARInformation

Fusion System

ReceiverPort

TransmitterPort

- 117 -


��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��!��"��

��#��"��

$

�� "��

��!��"��

��#��"��

%

��&!��&��

��!��"��

��#��"��

'

��

��"��

��!��

"��

��#��"

��

(

��"

��

��!��"��

��#��"��

#

�� #��)��#��"��!��"��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��!��"��

��#��"��

$

�� "��

��!��"��

��#��"��

%

��&!��&��

��!��"��

��#��"��

'

��

��"��

��!��

"��

��#��"

��

(

��"

��

��!��"��

��#��"��

#

�� #��)��#��"��!��"��

�

��

��

- 118 -

Figure 4-22: SV-7 System Performance Parameters Matrix

��*+��

*!#,��-��.�� #/#

�!#��00.�1��-!��*+�* 1�233��

��#��-��..��

(/�

��4�-.�,#'4#,'5��3��*��.�-2 ��#��*��*��

'/�

�2�.6 �3��*��.�-2 ��

#,� ��3�� 7 '/#

��8 +��

0� ��.�,��020 �� -�� *�� 2��7

��*��-7.�.��/�

0� ��..��%��020 �� .3��*��2��7

.��*.

0� ��.

*!

�!

��

(,��020�-�� .3��.� �0�

%,,��020. � 2.�1��-�� 2��7

�� 2.�-��

��/#

$,��#��9�� #/�

#��.0�..�� #��.0� �� /�

��

��!��

��*+��

*!#,��-��.�� #/#

�!#��00.�1��-!��*+�* 1�233��

��#��-��..��

(/�

��4�-.�,#'4#,'5��3��*��.�-2 ��#��*��*��

'/�

�2�.6 �3��*��.�-2 ��

#,� ��3�� 7 '/#

��8 +��

0� ��.�,��020 �� -�� *�� 2��7

��*��-7.�.��/�

0� ��..��%��020 �� .3��*��2��7

.��*.

0� ��.

*!

�!

��

(,��020�-�� .3��.� �0�

%,,��020. � 2.�1��-�� 2��7

�� 2.�-��

��/#

$,��#��9�� #/�

#��.0�..�� #��.0� �� /�

��

��!��

- 119 -

Figure 4-23: StV-2 Capability Functions with Performance Attributes

















Information AcquisitionInformation AcquisitionInformation Acquisition Information ManagementInformation ManagementInformation Management EffectsEffectsEffects



1. Analysis1. Analysis 1. TargetingAccuracy: 10m1. TargetingAccuracy: 10m



2. Fusion2. Fusion 2. Plan Engagement2. Plan Engagement



3. Quality Assurance3. Quality Assurance 3. Conduct Engagement3. Conduct Engagement

4. Dissemination4. Dissemination 4. Battle Damage Assessment4. Battle Damage Assessment

- 120 -

Figure 4-24: StV-3 Capability Phasing








ISTAR BASE STATION


ISTAR BASE STATION


ISTAR BASE STATION


Effects


KESTREL, SPECS 2











ISTAR BASE STATION


ISTAR BASE STATION


ISTAR BASE STATION


Effects


KESTREL, SPECS 2




Capability FunctionsCapability FunctionsCapability Functions Epoch 1Epoch 1Epoch 1 Epoch 2Epoch 2Epoch 2 Epoch 3Epoch 3Epoch 3

Information AcquisitionInformation Acquisition

Strategic ISTARStrategic ISTAR NEMESISNEMESISNEMESIS NEMESISNEMESISNEMESIS

Operational ISTAROperational ISTAR SPECSSPECSSPECS SPECS 2SPECS 2SPECS 2 SPECS 2SPECS 2SPECS 2

Tactical ISTARTactical ISTAR LOOKERLOOKERLOOKER KESTRELKESTRELKESTREL KESTRELKESTRELKESTREL

Information ManagementInformation Management

AnalysisAnalysis NEMESISNEMESISNEMESIS NEMESISISTAR BASE STATION




FusionFusion NEMESISNEMESISNEMESIS NEMESISISTAR BASE STATION




Quality AssuranceQuality Assurance NEMESISNEMESISNEMESIS NEMESISISTAR BASE STATIN




DisseminationDissemination BOWMAN, SATBOWMAN, SATBOWMAN, SAT BOWMAN, SATBOWMAN, SATBOWMAN, SAT

EffectsEffects

TargetingTargeting LOOKER, SPECSLOOKER, SPECSLOOKER, SPECS KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

KESTREL, SPECS 2

Plan EngagementPlan Engagement BISABISABISA BISABISABISA

Conduct EngagementConduct Engagement CR2, MILAN, FGACR2, MILAN, FGACR2, MILAN, FGA CR2, FGACR2, FGACR2, FGA CR2, FGACR2, FGACR2, FGA

BDABDA FGA, SATFGA, SATFGA, SAT FGA, SATFGA, SATFGA, SAT FGA, SATFGA, SATFGA, SAT

SPECS 2 must interoperate with both the NEMESIS ISTAR Base Station in Epoch 2, and the ISTAR Base Station in Epoch 3

- 121 -






XP





Long Term6-9 years

Short Term1-3 years

Area





XP





Long Term6-9 years

Short Term1-3 years

Area

- 122 -

Figure 4-26: TV-2 Technical Standards Forecast


XMIv2.1







MODAF

Long Term6-9 years

Short Term1-3 years

Standard/ Policy


XMIv2.1







MODAF

Long Term6-9 years

Short Term1-3 years

Standard/ Policy

- 123 -

Figure 4-27: Modified OV-1c after industry consultation


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

24

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

20

2026



Target2025Measure


SPECS 2 Video Delay


SPECS 2 Downtime



300

24

2027

300

36

2028

500

36

2029

600

36

2030

SPECS 2 Range

SPECS 2 Flight Time

Attribute

300

20

2026



Target2025Measure

- 124 -


Release 1

SPECS 2

Release 2 Release 3 Release 4 DisposalPlanning

Q1 2025 Q2 2026 Q4 2028 Q4 2030 Q4 2040

InitialRelease Release +

UrgentAdditionalRequirementsIdentified AtAcceptance

Release + DesirableAdditional RequirementsIdentified At Acceptance Release + Required

Situational Updates Planning for disposal/exension of designed life

- 125 -

Figure 4-29: OV-1c articulating ILS requirements

7

45

20

2027

6

40

18

2028

5

35

15

2029

5

34

14

2030

SPECS 2 Reliability



Attribute

8

50

30

2026




Target2025Measure

7

45

20

2027

6

40

18

2028

5

35

15

2029

5

34

14

2030

SPECS 2 Reliability



Attribute

8

50

30

2026




Target2025Measure

- 126 -

Figure 4-30: UML Version of OV-4 Organisational Relationships Chart

cd OV-4

Collection Manager ISTAR Coordinator


Commander


Planner


source

+superior officer

+manager

+organic col lection source

+customer

+inorganic col lection source

+customer

+overseer+overseer

- 127 -

Figure 4-31: UML Use Cases derived from the OV-4

ud Use Case Diagram

Collection Manager

Maintain Collection Plan

Generate RFI

Task Organic Collection Sources

Monitor Organic Collection Sources

ISTAR Coordinator


Monitor ISTAR Process


Requirements

Deceminate Intelligence

Commander

Specify Directiv es


Receiv e Intelligence

Collect Organic Intelligence

Collect Inorganic Intelligence


source

«extend»

«extend»

«extend»

- 128 -

Figure 4-32: UML representation of an OV-5 Operational Activity Model

ad Activ ity Diagram

ISTA

R C

oord

inat

orC

olle

ctio

n M

anag

erIdentify

Information Collection

Requirements


Determine how information can

be collected

Identify required

collection capability

Allocate capability

to task

:Battlespace Management

Information Source

Identify w hat information should

be collected

Identify w hen information needs to be

collected

Raise RFI

:Intelligence Estimate

:IPB

Monitor Task

Update plan

RFI

Update Plan

Monitor Response

Notify Intelligence

Manager


Notify Intelligence Manager and Collection

M anager

[inorganic]

[organic]

[else]


[else]


- 129 -

Figure 4-33: UML representation of a hybrid SV-4 Systems Functionality Description

ad SV4S

ituat

ion

Aw

aren

ess

Sys

tem

ISTA

R S

yste

mIS

TAR

Coo

rdin

ator

Col

lect

ion

Man

ager

Display Collection

Requirements

Input collection

Tasks

Update Task List

Display Task List

Prov ide Geographical

information

Display Geographical

Locations

battlespace topography

Select Geographical

Location corrisponding

to task

Display av ailable

assetsRequest Geographical

Information

Prov ide av ailable

asstes

Request assets for

geographical location

asset list[fi l tered]

Display task list M ap

Assets to Tasks

Allocate Assets to

Tasks

Update collection

plan

Update asset status

Design Consideration:These two exchanges could be achived wi thin a single exchange.

- 130 -

A.4 Other Deskbook Figures

The following pages contain all the other Figures used to illustrate the text, enlarged for readability if they are not easily readable within the text.

- 131 -

Figure 2-1: MODAF Viewpoints

SystemsViewpoint

Articulates system composition and interconnectivity to support system

analysis, and through-life management

Acquisition Viewpoint

Articulates acquisition programme construct, timelines and DLOD status to

inform planning

All Views

Provides pertinent summary information that specifies the architecture product

Strategic Viewpoint

Articulates the long-term strategic picture to support capability management and

equipment planning

TechnicalViewpoint

Articulates policy, standards, guidance & constraints to specify and assure quality

expectations

Operational Viewpoint

Articulates the operational picture to support operational analysis, user requirements

definition, and solution acceptance

- 132 -

Figure 2-2: MODAF 1.0 Baseline Products

TaxonomyTaxonomy

Meta ModelMeta Model

MODAF Acronyms ListMODAF Acronyms List


okok


okok

AcquisitionAcquisitionDeskbookDeskbook


okok


okok

MODAFMODAFCOICOI

DeskbookDeskbook

MODAFMODAF

Technical Technical HandbookHandbook

MODAFMODAF

OverviewOverview

MODAF Executive SummaryMODAF Executive Summary



MODAF Glossary of TermsMODAF Glossary of Terms

- 133 -

Figure 2-3: Community of Interest Deskbook Scope

C A D M C A D M I T

D I

Concepts & Doctrine

Capability

Management

Operations

Funded Options

Capability Gaps Future Op

Needs

Doctrine

Customer 1 Acquisition

Sustainment

Customer 2

Concepts & Doctrine

- 134 -

Figure 3-1: General Process for Building MODAF-Compliant Architectures

User training- MODAF principles

Prerequisites 1. Establish Intended

Use

2. Define Architecture

Scope

3. Develop Data

Requirements

4. Capture Architecture

5. Conduct Analyses

6. Document Results

MODAF Governance

MODAF Users

MODAF Resources

MODAF Baseline

Architectural Use Doc.

Workshop -Determine Architecture Usage

Workshop -Bound Architecture Scope

Workshop -Establish Data Needs

Architectural Scope Doc.

Tool Selection

Data Gathering Plan

BaselineArch. Review

Baseline Architecture

Inform Central Reg.

Query of Avail. Data Sources

Publish Baseline to MODAR

Tool-specific Training

Initial Analysis

Final Analysis

Analysis Review

Finalised Architecture

Finalised Arch. Review

Publish Final Arch. to MODAR

Provide Extant Arch.Data

MODAF Training Material

MODAF Tiger Teams

MODAF Tiger Teams

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Help Desk

MODAF Tiger Teams

Certified Tool List

Tool Advice

Hybrid View Development

MODAF Tiger Teams

MODAF Tiger Teams

MODAF Tiger Teams

MODAF Taxonomy

ERM / M3

Workshop -Determine Use Cases

Plan of Time & Resources

- 135 -

Figure 3-2: Key Elements and Interfaces of Acquisition COI Processes

Acquisition

I T

DI

Concepts & Doctrine

Capability

Management

Operations

C A D M

C A D M

Acquisition

Project Management

Requirements


Industry


URD SRD

CapabilityTLMP

CONOP,CONEMP,CONUSE CIP

- 136 -

Figure 3-7: URD MODAF Viewpoints through CADMID

IG MG

TV-1

OV-2

OV-1

OV-3

OV-5


StV-6

OV-1


OV-2

OV-1


OV-5

TV-1

OV-3

OV-2


��

��

�

StV-6 StV-6

Essential View


- 137 -

Figure 3-9: SRD MODAF Viewpoints through CADMID

IG MG

TV-1

SV-3

SV-1


SV-6

TV-1

SV-2


SV-4

SV-7

SV-3

SV-1


SV-4

SV-2

SV-6

SV-7

Essential View


OV-7 OV-7

- 138 -

Figure 3-24: TLMP MODAF Views through CADMID

IG MG

SV-9

AcV-2

SV-8


SV-9

SV-8

AcV-2

SV-9

SV-8

AcV-2

Essential View
