MINISTRY OF DEFENCE. MOD Architectural Framework Integrated Project Team (IPT) Community of Interest Deskbook

Transcription

1 MODAF-M MINISTRY OF DEFENCE MOD Architectural Framework Integrated Project Team (IPT) Community of Interest Deskbook Version August 2005 Prepared by:- Approved by:- MODAF Project Review Board CROWN COPYRIGHT 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

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 Version August 2005 First MODAF Baseline release Disclaimer Following review it has been decided that, to better reflect its intended audience and to avoid confusion with the Acquisition Process, the Acquisition Community of Interest (COI) Deskbook (this Deskbook) is renamed the Integrated Project Team (IPT) COI Deskbook. This change is immediate; all references in the MODAF documentation to the Acquisition COI Deskbook should be interpreted as the Integrated Project Team COI Deskbook. This change will be reflected in the MODAF documentation at the next update. MODAF-M Version 1.0 2

3 MODAF Integrated Project Team (IPT) Deskbook Table of Contents Foreword Introduction Enterprise Architectures and Frameworks This Deskbook Background What is MODAF? Guide to Deskbook Purpose Approach Context Deskbook Structure MODAF Relationship to Acquisition Business Processes and Activities Architecture Development Process Six-Stage Architecture Development Process Architectural Data Sources Application to Acquisition Process Overview of MODAF View use Ensuring Views are MODAF compliant Key to the Process / View Mapping Diagrams Acquisition Process Project Management Form the IPT Systems Engineering Management Plan Initial Gate Manage dependency risks Main Gate Place contract(s) to meet the SRD Wind down of IPT Requirements Management User Requirements Document (URD) Linkage between User and System Requirements System Requirements Document (SRD) Integrated Testing, Evaluation and Acceptance Systems / Technology Identify technology and procurement options Demonstrate ability to deliver integrated capability Technology insertion Industry / Suppliers Involve Industry System Synthesis Negotiate contract Deliver the solution Carry out any agreed upgrades or improvements Through-Life Management TLMP MODAF-M Version 1.0 3

4 3.7.2 Integrated Logistic Support Worked Example ISTAR Worked Example Introduction Project Management Form the IPT Systems Engineering Management Plan Initial Gate Manage Dependency Risks Main Gate Place contract(s) to meet the SRD Wind down of IPT Requirements Management Develop and Maintain User Requirements Document (URD) Linkage between User and System Requirements Develop and Maintain System Requirements Document (SRD) Integrated Testing, Evaluation and Acceptance Systems / Technology Identify technology and procurement options Demonstrate ability to deliver integrated capability Technology Insertion Industry / Suppliers Involve Industry System Synthesis Negotiate Contract Deliver the solution Carry out any agreed upgrades or improvements Through-Life Management TLMP Integrated Logistic Support UML Example Document Maintenance Bibliography...78 MODAF-M Version 1.0 4

5 Table of Figures Figure 1-1: Enterprise Architecture Views...10 Figure 2-1: MODAF Viewpoints...12 Figure 2-2: MODAF 1.0 Baseline Products...14 Figure 2-3: Community of Interest Deskbook Scope...15 Figure 3-1: General Process for Building MODAF-Compliant Architectures...17 Figure 3-2: Key Elements and Interfaces of Acquisition COI Processes...21 Figure 3-3: Key MODAF Relationship to Project Management Activities...23 Figure 3-4: TV-1 Technical Standards Profile...24 Figure 3-5: AcV-2 SoS Acquisition Programme...26 Figure 3-6: URD MODAF Viewpoints through CADMID...29 Figure 3-7: MODAF relationship to Requirements Management...30 Figure 3-8: SV-5 links the URD and SRD...31 Figure 3-9: SRD MODAF Viewpoints through CADMID...32 Figure 3-10: SV-4 Systems Functionality Description...33 Figure 3-11: SV-1 Systems Interface Description...33 Figure 3-12: SV-2a System Port Specification...34 Figure 3-13: SV-2b System-to-System Port Connectivity...34 Figure 3-14: SV-2c System Connectivity Clusters...35 Figure 3-15: SV-3 Systems-Systems Matrix...35 Figure 3-16: SV-6 Systems Data Exchange Matrix...36 Figure 3-17: MODAF Relationship to System / Technology workstream...39 Figure 3-18: SV-9 Systems Technology Forecast...40 Figure 3-19: MODAF Relationship to Industry workstream...43 Figure 3-20: OV-1a High Level Operational Concept Graphic...44 Figure 3-21: OV-1b Operational Concept Description...44 Figure 3-22: OV-1c Operational Performance Attributes...45 Figure 3-23: MODAF Relationship to Through-Life Management...47 MODAF-M Version 1.0 5

6 Figure 3-24: TLMP MODAF Views through CADMID...48 Figure 3-25: SV-8 Systems Evolution Description...48 Figure 3-26: OV-1c Operational Performance Attributes...49 Figure 4-1: AcV-2 provided by Customer Figure 4-2: Initial TV-1 setting the standards and constraints for the IPT...51 Figure 4-3: AcV-2 showing dependency with delivery of KESTREL...53 Figure 4-4: OV-5 from the URD...54 Figure 4-5: StV-5 showing the Capability gap to be addressed...54 Figure 4-6: StV-6 within the URD shows the Operational Vignette...56 Figure 4-7: OV-1a showing identification of target Operational Vignette...56 Figure 4-8: OV-1c showing Performance Requirements...57 Figure 4-9: Use Case document used as an extension to OV Figure 4-10: OV-5 derived from Use Case document...58 Figure 4-11: OV-2 showing information flows...59 Figure 4-12: OV-3 provides Information Exchange Requirements...59 Figure 4-13: SV-5 provides the linkage between the URD and SRD Views...60 Figure 4-14: SV-4 Systems Functionality Description...61 Figure 4-15: SV-1 showing the system interfaces...62 Figure 4-16: SV-3 Systems-Systems Matrix...63 Figure 4-17: SV-2a for US JSTAR asset...64 Figure 4-18: SV-2a for SPECS 2 SRD...64 Figure 4-19: SV-2b System-to-System Port Connectivity...65 Figure 4-20: SV-2c System Connectivity Clusters...66 Figure 4-21: SV-6 Systems Data Exchange Matrix...66 Figure 4-22: SV-7 System Performance Parameters Matrix...67 Figure 4-23: StV-2 Capability Taxonomy with Performance Attributes...68 Figure 4-24: StV-3 Capability Phasing...69 Figure 4-25: SV-9 Systems Technology Forecast...69 Figure 4-26: TV-2 Technical Standards Forecast...70 MODAF-M Version 1.0 6

7 Figure 4-27: Modified OV-1c after industry consultation...71 Figure 4-28: SV-8 Systems Evolution Description...72 Figure 4-29: OV-1c articulating ILS requirements...72 Figure 4-30: UML Version of OV-4 Organisational Relationships Chart...73 Figure 4-31: UML Use Cases derived from the OV Figure 4-32: UML representation of an OV-5 Operational Activity Model...75 Figure 4-33: UML representation of a hybrid SV-4 Systems Functionality Description...76 MODAF-M Version 1.0 7

8 Foreword 1. An effects based approach to military operations demands that we combine military capabilities in time and space, to an ever increasing tempo, in order to achieve the desired outcome. To achieve this, we must master the complex interaction of weapons, platforms, sensors and people, in order to maximise their combined strengths and to minimise any potential weaknesses. We seek to do this through our adoption of Network Enabled Capability, integrating existing capabilities into an increasingly coherent system of systems. 2. At the same time, perpetual pressure on Defence spending means that we must seek maximum return on our investments and drive inefficiency out of our operations. 3. Our greatest enemy in this regard is complexity and we must find effective ways to overcome it. One key to achieving the simplicity we seek is to focus on the decision-making process and the information flows that must support effective decision-making and subsequent action. 4. The MOD Architectural Framework (MODAF) offers invaluable assistance in our struggle for simplicity, as it provides a common language and common formats for the capture and shared use of trusted data. It is therefore my intent that we adopt an architectural approach, grounded in MODAF, to our day-to-day business. This Deskbook explains how you can begin to use MODAF to articulate your business in a manner that will aid collective understanding, increase efficiency and enhance effectiveness; I commend it to you. MODAF-M Version 1.0 8

9 1. Introduction 1.1 Enterprise Architectures and Frameworks 5. MOD s adoption of Network Enabled Capability (NEC) 1 as a means of integrating existing capabilities into a coherent system of systems is an ambitious exercise in managing both complexity and change throughout the enterprise. Modern warfare is fast changing and the systems that technology is now making available are in themselves faster, more complex and more adaptable than ever before. The combination and orchestration of these systems in concert with operational planning introduces a level of complexity never before experienced in the Ministry of Defence. 6. To assist decision-makers, MOD has decided to adopt the MOD Architecture Framework (MODAF) as a means of abstracting essential information from the underlying complexity and presenting it in a way that maintains coherence and consistency. One of the principle objectives is to present this information in a way that is understandable to the many stakeholder communities involved in developing, delivering and sustaining capability through life. 7. MODAF is an Architectural Framework which has been designed to meet the specific business and operational needs of the MOD. It defines a way of representing an Enterprise Architecture which enables stakeholders to focus in on specific areas of interests in the enterprise, whilst retaining sight of the big picture. In essence it enables decision-makers to manage complexity by splitting the problem space into manageable pieces defined in the framework as Views. The views are categorised under Viewpoints by their perspective (e.g. operational, technical, etc.). Each View has a particular purpose, and usually presents: a. Broad summary information about the whole enterprise (e.g. high level operational concepts); b. Narrowly focussed information for a specialist purpose (e.g. system interface definitions); c. Or, information about how aspects of the enterprise are connected (e.g. how business processes or operational activities are supported by a system, or how programme management brings together the different aspects of network enabled capability). 8. The fundamental tenet of an Enterprise Architecture approach is that there is one source of truth. This reflects the fact that while there can only be one enterprise, there can be many valid stakeholder views providing they are based on a common data set. The diagram in Figure 1-1 attempts to illustrate this concept of a single enterprise that can be presented in different ways that has meaning for particular stakeholders or communities of interest. 1 Network Enabled Capability JSP 777 Edition 1 dated April MODAF-M Version 1.0 9

10 Operational Node - Marketing Dept. Operational Node - Sales Dept. Operational Node - Distribution Centre Operational Node - Product Design Centre Operational Node - Call Centre Operational Node - Manufacturing Plant Location - London, UK 1 Location - Cambridge, UK 4 Location - Shanghai, China Acme inc. 2 3 Location - Leeds, UK Sales & Marketing Engineering HR IS/IT 5 6 Sales Marketing R&D Design Test Location - Northampton, UK Needlines: 1 market requirements 2 sales summary information 3 target market information 4 manufacturing specifications 5 distribution orders 6 product requests Customer Services MRP etc. Sales Dept. CRM Marketing Dept. Reqs Mgmt Functional Modeller Product Design Centre Product Data Mgmt CAD Recon Report <<OperationalActivity>> Analyse Target Data <<OperationalActivityAction>> Enhance Images Order Mgmt CRM Reqs Mgmt ERP Finite Element Processe d Images Order Mgmt CRM ERP Strike Recommendati <<OperationalActivityAction>> <<OperationalActivityAction>> on Make Strike Analyse Images Decision Stock Mgmt CCMS QC Robot Planning CNC Strike Decision Distribution Centre Call Centre Manufacturing Plant Figure 1-1: Enterprise Architecture Views 9. As with any potentially large-scale endeavour such as MODAF, it is crucial to have an agreed and common language or terminology. To this end MODAF provides a Dictionary of Terms and a Glossary of Abbreviations. To understand what MODAF is (and equally important what it is not) it is particularly important for the reader to understand the following terms from the outset: a. Enterprise Architecture: The formal description of the structure and function of the components of an enterprise, their interrelationships, and the principles and guidelines governing their design and evolution over time. (Note: Components of the Enterprise can be any element that goes to make up the enterprise and can include people, processes and physical structures as well as engineering and information systems). b. Enterprise: The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organisational boundaries are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes. i. Enterprise (1) : An organisation (or cross organisational entity) supporting a defined business scope and mission that includes interdependent resources (people, organisations and technologies) that must coordinate their functions and share information in support of a common mission (or set of related missions). (US Federal CIO Council) ii. Enterprise (2) : A systematic, purposeful set of activities whose primary purpose is focussed on achieving a set of clearly defined objectives that may transcend organisational boundaries and consequently require integrated team working under the direction of a governing body of resource providers. c. Enterprise Architecture Framework: A logical structure for classifying, organising and presenting complex information relating to Enterprise Architectures in a uniform manner. 1.2 This Deskbook 10. This Deskbook is part of a suite of MOD Architectural Framework (MODAF) documentation that is being released at Version 1.0. The Deskbook is not intended MODAF-M Version

11 to be an authoritative technical document with respect to MODAF and only provides limited information regarding the background to MODAF, the benefits that will result from its implementation and the technical detail needed to produce MODAFcompliant architectures. Should more information be required, then it is suggested that the reader consult the MODAF Overview document (MODAF-M09-002) in the first instance, and then the MODAF Technical Handbook Volume 2 (MODAF-M07-022) for detailed technical information. 11. The Deskbook intends to provide pertinent MODAF-specific information and guidance to this community s specific business processes and activities, placing particular emphasis on understanding how current processes/activities relate to the future needs of the community. The insight to this was provided through communityrelated documentation and engagement with the specific community of interest through a series of workshops and participation in the document review board. 12. Naturally, as these processes and activities evolve, it may be necessary to release updated versions of this Deskbook for the benefit of the community. Should any changes, errors or omissions be noticed while reading this document then these should be brought to the attention of the MODAF Project Management team, whose contact details are published in Section 5 of this Deskbook. MODAF-M Version

12 2. Background 2.1 What is MODAF? 13. MODAF is a framework for conducting Enterprise Architecture and provides a means to model, understand, analyse and specify Capabilities, Systems, Systems of Systems (SoS) and Business Processes. MODAF consists of the six Viewpoints that are shown in Figure 2-1. Strategic Viewpoint Documents the strategic picture of how military capability is evolving in order to support capability management and equipment planning Operational Viewpoint Documents the operational processes, relationships and context to support operational analyses and requirements development Systems Viewpoint Documents system functionality and interconnectivity to support system analysis and through-life management Acquisition Viewpoint Documents acquisition programme dependencies, timelines and DLOD status to inform programme management Technical Viewpoint Documents policy, standards, guidance and constraints to specify and assure quality expectations All Views Provides summary information for the architecture that enables it to be indexed, searched and queried Figure 2-1: MODAF Viewpoints 14. MODAF consists of 38 Views, each of which can be used to represent a particular aspect of the enterprise. These Views are categorised into the six Viewpoints, as shown in Figure 2-1. The purpose of each of the 38 Views is different some provide high-level summary information about the enterprise (e.g. organisational structure, programme management, etc.), others describe some specific aspect (e.g. system interfaces), whilst others serve to describe the relationships between different aspects of the enterprise (e.g. process mapping). 15. Not every View is appropriate or necessary for a given architecture. It is intended that users select appropriate MODAF Views to most effectively represent their needs. This Deskbook provides advice for the specific Community of Interest (COI). 16. 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 is an enabler to the successful delivery of Network Enabled Capability (NEC). Amongst the benefits of MODAF within the Acquisition processes are: d. Improved clarity of the context within which a new capability will operate. e. Clearer and more comprehensive requirements documents MODAF-M Version

13 f. Improved ability to resolve interoperability issues between systems g. 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 Purpose 17. The purpose of this document is to illustrate to the general Acquisition community how the MODAF Views within these architectures can support the various elements of their processes and activities Approach 18. The main part of this Deskbook is the mapping of MODAF views onto the Acquisition community s processes (see Section 3). For each process, the required, and useful MODAF Views are specified illustrating whether the process requires input from Products 2 conforming to a given view, or whether the process itself creates those Products. A worked example (see Section 4) provides context to the process mappings by showing how the architectural development process can be applied to a given scenario Context 19. The Acquisition Deskbook forms part of the overall suite of MODAF 1.0 baseline documentation as shown in Figure An Architectural Product is a connected and coherent set of architectural elements (e.g. processes, systems, platforms, organisations, etc.) that conforms to a view. MODAF-M Version

14 MODAF Executive Summary MODAF Overview MODAF Technical Handbook Acquisition Deskbook COI Deskboo MODAF COI k Deskboo COI Deskbook k Viewpoint Overview Meta Model Taxonomy MODAF Acronyms List MODAF Glossary of Terms Figure 2-2: MODAF 1.0 Baseline Products 20. The main elements of the MODAF baseline documentation are: a. Executive Summary provides a brief summary of the entire MODAF baseline b. MODAF Overview describes what MODAF is, why it should be used and details the process for developing architectures c. MODAF Technical Handbook provides details of the construction of MODAF Views and their relationship to the MODAF Meta Model (M 3 ). This is supported by: i. View Overview a short summary of each View intended for quick reference by MOD users ii. Meta Model 3 used to define the architectural objects that are permitted in MODAF Views and their relationships with each other. The M3 is derived from a conceptual model of the elements within the MOD architecture - the Enterprise Reference Model 4 (ERM). iii. Taxonomy 5 provides the approved names and definitions for architectural objects to be used within the MOD s architectures 3 MODAF Meta Model, IA/02/16-ERMcm04 Version 1.0. Please refer to the IA for more information. 4 Enterprise Reference Model, IA/02/16-ERMcm06 Model Version 2.1, 15 August 2005 and Document version 1.1, 15 August MODAF Taxonomy Requirements, IA/02/16-ERMcm05 Version 1.0. Please refer to the IA MODAF-M Version

15 d. MODAF Deskbooks describe how users within particular communities in the MOD are expected to utilise MODAF architectures to support their processes. e. MODAF Acronym List and Glossary of Terms these documents define the commonly used terminology in the MODAF Document Suite. 21. The Deskbooks are aimed at specific Communities of Interest (COIs). The boundaries between these communities are not always distinct, but it has been necessary to draw boundaries for the purposes of the Deskbooks. Each COI is defined in terms of its relationship to the main MOD processes (see Figure 2-3). Whilst these do not describe the whole of the MOD s processes as described in the Business Management System (BMS), they do cover the core processes around acquisition and military operations. 22. It should be noted that the COI names referred to in Figure 2-3 are merely convenient labels to apply to communities / groups that are engaged in similar activities, representing the primacy of each role as the CADMID/CADMIT cycle unfolds. For instance, the scope of the Acquisition COI aligns broadly with that of the DPA IPTs (i.e. largely equipment focussed from Concept stage through to delivery into service). Obviously this scope is somewhat more limited than the full Smart Acquisition definition of Acquisition which encompasses all DLODs and the entire lifecycle. However, collectively the MODAF COIs do encompass all of the DLODs and cover the entire MOD acquisition lifecycle. Concepts & Doctrine Concepts & Doctrine Future Op Needs Doctrine Capability Gaps Customer 2 Operations Customer 1 Acquisition Capability Management C A D M I D Funded C A D M I T Options Sustainment Constraints Figure 2-3: Community of Interest Deskbook Scope 23. The high level scope of these COIs is: a. Concepts and Doctrine - the development of analytical concepts (e.g. Joint High Level Operational Concept), applied concepts (e.g. Joint Fires) and In- Service doctrine (eg SOPs and TTPs) for more information. MODAF-M Version

16 b. Customer 1 the monitoring of capability gaps against future needs, building the Equipment Programme (EP) and ownership of User Requirements Documents (URDs) for new capabilities c. Acquisition the development and fielding of new military capabilities, the primary focus is up to the acceptance into service of a fully operational capability d. Sustainment the processes to maintain military capability in line with the relevant Through Life Management Plan while recognising the in-theatre Sustainment roles of the relevant Second Customer s Pivotal Managers 6 e. Customer 2 the Core Leadership and Pivotal Management roles as defined in Smart Acquisition 7 and described further in the Joint and Single Service 2 nd Customer Handbooks Deskbook Structure 24. The remainder of this Deskbook comprises two key sections: a. 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. b. Section 4 - Worked Example of MODAF in Acquisition this section demonstrates how MODAF can be used practically within CADMID. 25. In addition, the following guides are available, summarising key elements of this Deskbook: a. Project Management Guide (MODAF-M10-006) b. Requirements Guide (MODAF-M10-007), and: i. User Requirements Document (URD) Guide (MODAF-M10-003) ii. System Requirements Document (SRD) Guide (MODAF-M10-008) c. Systems / Technology Guide (MODAF-M10-009) d. Industry / Supplier Liaison Guide (MODAF-M10-010) e. Through-Life Management Guide (MODAF-M10-011) 6 Covered in the Customer 2 Deskbook as the Maintain Military Capability process 7 For further detail, see Smart Acquisition Handbook, available at 8 Customer 2 (Core Leadership) is undertaken by single-service Chiefs to provide overall strategic management of individual Services and their professional direction. Core Leadership provides advice to Customer 1 on the full range of factors contributing to military capability across the DLODs. Customer 2 (Pivotal Management) is undertaken by those who use the equipment in-service (primarily the front line and training commands) in order to provide the user perspective and manage allocated resources to achieve the required output. MODAF-M Version

17 3. MODAF Relationship to Acquisition Business Processes and Activities 3.1 Architecture Development Process 26. The Deskbooks provide guidance about the appropriate MODAF views that can be used to support the COI s processes. It is also worthwhile considering the process of developing the architecture itself. The following sections outline a generic approach based on architectural best practice. The approach can be used (with some tailoring where necessary) by any COI wishing to develop an architecture Six-Stage Architecture Development Process 27. The stage-by-stage approach to developing a MODAF-compliant architecture is shown in Figure 3-1. The initial stages establish purpose and scope for the architecture and define the data needed to populate the architecture. Then there is the key stage of developing the architecture itself, and the use of the architecture to conduct analysis and document the results of that analysis. A more detailed description of the six-stage architecture development process is provided in the MOD Architectural Framework Overview (MODAF-M09-002, Version 1.0), which should be consulted by all MODAF users before embarking on their first architecture development. 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 User training -MODAF principles Workshop - Determine Architecture Usage Inform Central Reg. Workshop - Bound Architecture Scope Query of Avail. Data Sources Workshop - Establish Data Needs Provide Extant Arch. Data Tool-sp ecific Training Publish Baseline to MODAR Analysis Review Publish Final Arch. to MODA R Finalised Arch. Re view Workshop - Determine Use Cases Plan of Time & Resources Data Gatheri ng Plan Baseline Arch. Re vie w Initial Analysis Architectural Use Doc. Architectural Scope Doc. To ol Selection Baseline Architecture Final Analysis Finalised Architecture MODAF Resources MODAF Baseline MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Tiger Teams MODAF Training Material MODAF Help Desk MODAF Help Desk Hybrid View Development MODAF Help Desk Certified Tool List MODAF Help Desk MODAF Taxonomy MODAF Help Desk MODAF Help Desk To ol A dvi ce ERM / M3 Figure 3-1: General Process for Building MODAF-Compliant Architectures 28. 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. MODAF-M Version

18 29. One of the crucial MODAF governance mechanisms is the MOD Architectural Repository (MODAR) that is run by the Integration Authority (IA). 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 is also important that all new architectures are lodged with MODAR to inform others and allow the re-use of new architectural data. Furthermore, for the Acquisition community the IA provides additional integration services that assist in modelling end-to-end performance and interoperability assurance. 30. Another important 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 tools 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) are completed thoroughly for all architectures before they are published. Further information on the All Views can be found in the MODAF Viewpoint Overview (MODAF-M07-016, Version 1.0). 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 Architectural Data Sources 32. Over time, as increasing numbers of projects develop their MODAF architectures, a cohesive library of architectural elements will emerge, and any MODAF user would expect to commence analysis or planning by re-using relevant elements from the library. These may include MODAF architectures supporting the capability definition (Strategic Products), URD and CONEMP (Operational Products), interfacing systems (System Products), applicable standards (Technical Products) and programmatic information (Acquisition Products). For early adopters of MODAF, it is likely that some or all of these will be missing when architectural activities are started and the user will have to either backfill the key elements themselves, validating them with the stakeholders who should have provided them, or request that they be produced. 33. Architectures should be living representations of the enterprise and must be kept up to date. It is important to apply the six-stage architectural process for each new piece of work as the required outcomes, assumptions, scope, data sources etc may have changed in the meantime. 34. 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: a. 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 b. 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 9 Interim NEC, CBM and BMS MODAF Modelling Policy, DEC (CCII) File ses , 1/3/05. MODAF-M Version

19 35. 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 10 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. 36. Any team conducting architectural activities within the MOD should contact the IA as custodians of the MODAR in order to establish what architectural data may exist or to understand who else may be developing related information all of which will minimise nugatory work. See Section 5 for contact details Application to Acquisition Process 37. The intent is that the architecture development approach should be applied by all acquisition IPTs as they progress through the CADMID / CADMIT lifecycle 11 in order to deliver the required new or enhanced military capability. 38. 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 Overview of MODAF View use 39. MODAF Views provide support to MOD business processes in four key ways: in support of analysis; to articulate issues or requirements; to specify or design a capability, or to validate or assure a capability. Particular attention needs to be paid to analysis support, which is generally a reference to some form of Operational Analysis (OA). 40. OA is initiated by any MOD community that has a requirement to answer questions about current, or proposed, military capability, operational processes, organisations, systems etc. As such, MODAF Views used for the analysis may be different, depending on the purpose of that analysis. Specific instances of OA applicable to the normal COI processes have been included within this Deskbook in the relevant sections. OA undertaken on subjects not covered within this Deskbook should follow the 6-stage architecture process described in Section This can be used to determine the relevance and scope of architectural support for specific OA; smaller pieces of analysis work are anticipated to continue using any relevant tools (for example, spreadsheets may be the most appropriate tool for financial analysis) where the analysis piece is not large enough to warrant use of a MODAF architecture. 10 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 11 Further information on the CADMID / CADMIT lifecycle can be found on the Acquisition Management System (AMS) 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. MODAF-M Version

20 41. In addition to the way MODAF Views support business processes, they are applicable 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, as the SoS Acquisition Programme View, is designed to support the acquisition and fielding processes to achieve integrated military capabilities. However, it could also inform the Concepts & Doctrine community of the current and proposed status of projects/programmes during the development of concepts. MODAF Views may also provide a means of communication between different stakeholders in a process. 42. 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: a. Essential Views that are essential for use during a particular Concepts & Doctrine activity b. 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. 43. The Essential Views are the starting point for any new MODAF user. Highly Desirable Views are more appropriate to users who have more experience of MODAF and are looking for further ways of using architectural information to inform an activity. An example of the classification of MODAF Views is at Appendix 1, illustrating the mapping of essential and highly desirable Views. 44. Any other MODAF 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. If a non-modaf View is used, the user must justify use of a non-standard View and be aware that such Views may not be shared Ensuring Views are MODAF compliant 45. In order to maximise the ability to exploit architectures produced in MODAF format it is important that they fully comply with the MODAF standards, which includes not only the use of MODAF views but also the MODAF Meta-Model and Taxonomy. The use of MODAF-certified tools by architecture development teams will ensure that most of these requirements are satisfied and hence provide assurance of interoperability between tools and with the MODAR repository. 46. It is possible for users to create Views that look similar to those specified in MODAF, but which do not conform to the full standard. In such cases it is likely that the resulting architecture will not be capable of full information exchange between tools / with the MODAR repository and therefore might not be accessible to others running architectural queries. The resulting architecture would become, to a greater or lesser degree, isolated from the main MODAR body of architectural knowledge. 47. However, there may be good reasons for wishing to modify MODAF views such as adding further overlays to enhance understanding. Where this is the case, the user wishing to develop modified Views should first contact the MODAF team and/or IA (see Section 5 for points of contact) for advice on how to implement the required enhancements in a manner that maximises tool interoperability and hence the future exploitation of the resulting architecture Key to the Process / View Mapping Diagrams 48. The key to the Process / View mapping diagrams used in this section are as follows: MODAF-M Version

21 a. Activities are shown as unshaded rectangles with the name of the activity inside the rectangle b. MODAF Views are shown as follows: i. Essential MODAF Views are shown as rectangular objects, colourcoded by Viewpoint (see Figure 2-1) ii. Highly Desirable MODAF Views are shown as ellipse objects, similarly colour-coded. c. Inputs and outputs are shown as arrows from the process to / from the appropriate MODAF Views. If the arrowhead points to the View, it indicates that the process produces architectural products that conform to that View. If the arrowhead points to the process, it indicates that the process uses products that conform to that View. 3.2 Acquisition Process 49. 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 a particular process stage. This type of information can be found on the Acquisition Management System (AMS) 12. CONOP, CONEMP, CONUSE Acquisition Project Management CIP URD Requirements SRD Concepts & Doctrine Systems / Technology Industry Through Life Management Operations Acquisition TLMP Capability Capability C A D M I D Management C A D M I T Figure 3-2: Key Elements and Interfaces of Acquisition COI Processes 12 MOD Smart Acquisition Management System MODAF-M Version

22 50. The Acquisition COI processes interface with all of the other COIs, some of the key inputs and outputs being: a. Concepts and Doctrine inputs: provides the Acquisition processes with applied concepts that document the operational context and usage of the new capability b. Capability Management inputs: is responsible for the CRD, URD, associated KURs and their management throughout the lifecycle c. 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 d. 2nd Customer inputs: the Capability Integration Plan (CIP) that defines responsibilities and integration mechanisms across all of the LODs is developed in conjunction with the 2nd Customer 51. 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 Project Management 52. 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: a. Forming the IPT b. Systems Engineering Management Plan c. Initial Gate Review d. Management of Dependency Risks e. Main Gate Review f. Placing of contract(s) to meet the SRD g. Winding down the IPT 53. Figure 3-3 shows the key architectural product for Project Management, Acquisition View AcV-2 System of Systems Acquisition Programme, and how this fits within the overall process, as shown in Figure 3-2. MODAF-M Version

23 Acquisition Project Management Requirements CONCEPT ASSESSMENT DEMONSTRATION MANUFACTURE IN-SERVICE DISPOSAL URD Systems / Technology Key TV-1 URD OV-2 Form the IPT AcV-2 TLMP SV-1 TV-1 Initial Gate Industry Through Life Management View Set Essential View produced outside this workstream Essential View produced by this workstream Highly Desirable View produced outside this workstream Highly Desirable View produced by this workstream StV-5 URD OV-5 SRD AcV-2 Manage dependency risks SRD TLMP ITEAP Main Gate OV-2 SV-1 TV-1 SRD Place contract(s) to meet the SRD URD Wind down of IPT Figure 3-3: Key MODAF Relationship to Project Management Activities MODAF-M Version

24 3.3.1 Form the IPT 54. 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. 55. 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. 56. Part of this process includes co-ordination and management of the standards portfolio from System of Systems and URD requirements 13. The use of the Technical Viewpoint, and TV-1 in particular, aids this role in tracking the Treaties, Legislation and Standards invoked. 57. TV-1 (Figure 3-4) 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. Service Area Service System Elements Standard / Policy Data Transfer TCP/IP BOWMAN IP v6 Messaging BISA / Comms MS Outlook Compliant JSP 324 Operating Systems Workstations BISA / Control Stations Data Interchange Interoperability OMG XMI 2.1 Figure 3-4: TV-1 Technical Standards Profile 13 Further information regarding Standardisation and its application to Acquisition can be found on the Acquisition Management System at or by contacting PDG Standardisation. MODAF-M Version

25 3.3.2 Systems Engineering Management Plan 58. 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). 59. 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 Initial Gate 60. The business case to be presented at Initial Gate includes the programme plan and costing for the procurement. 61. AcV-2, SoS Acquisition Programme, 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 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 MODAF-M Version

26 ISTAR SYSTEMS Kestrel needs to come in to service as planned, to avoid a capability gap arising when SPECS is fully disposed KESTREL DISP START DISP FIN SPECS DISP START NEMESIS DISP START DISP FIN LOOKER SPECS Training Equipment LoD 'Segment' Project Phase Key to View Personnel Information Lo gistics I nf rastructure No outstanding issues Manageable issues Critical issues Pre-IG IG to MG MG to IOC IOC to FOC Doctrine/ Concepts Organisation DLOD Absent In Service Disposal Critical issues Figure 3-5: AcV-2 SoS Acquisition Programme 62. 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). 63. The Operational Analysis Supporting Papers for the Initial Gate submission may also utilise MODAF Views for the analysis undertaken, and also to articulate that analysis. Specific instances of these analyses have been included within this Deskbook in the relevant sections: (for example, technology forecasts, operational activities, options analysis etc). Please refer to Section for further information regarding MODAF support to OA. 64. 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 Manage dependency risks 65. 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. MODAF-M Version

27 66. AcV-2 SoS Acquisition Programme 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 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. 67. 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. 68. 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 Main Gate 69. 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. 70. Similarly to the Initial Gate submission, an Operational Analysis Supporting Paper (OASP) may be submitted as part of Main Gate. This may contain any relevant MODAF Views, depending on the nature and scale of the analysis. Please refer to the description of MODAF use within OA given in the Initial Gate Section 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 (e.g. through OV-2 and SV-1) and compliance with standards including JSP 600 series (using TV-1) 15. This assurance process will normally involve an assessment of the project s MODAF architecture against those for interfacing systems held within MODAR. 72. 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. 15 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. MODAF-M Version

28 3.3.6 Place contract(s) to meet the SRD 73. 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 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 Wind down of IPT 74. 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. 3.4 Requirements Management 75. 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: a. Develop and Maintain User Requirements Document (URD) b. Maintaining the linkage between User and System Requirements c. Develop and Maintain System Requirements Document (SRD) d. Integrated Testing, Evaluation and Acceptance Plan (ITEAP) e. Acceptance 76. Figure 3-7 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. SMART acquisition principles ensure that the statement of a requirement (whether it be in the CRD, URD or SRD), is distinct from that of a constraint. Requirements are pure capability statements, focussed on what needs to be achieved, and not stating any association with a type solution or extant/ proposed operational environment. Constraints are used to place the requirement in context of the extant/ proposed environment, by specifying the constraining factors associated with a particular type of solution. 77. For example, a requirement might be for an underwater personnel transport capability, range 10km, capacity 20 personnel. An associated constraint might be that if the solution is a submarine, it must be able to dock at existing submarine docking stations, and satisfy the relevant standards, policies and procedures. It supplier could propose an alternative solution, along with modified or new docking stations. 78. Note that constraints can easily be confused with requirements and one could argue that there is a requirement for a solution to interface to an existing system. This is actually a constraint, as it might be that the supplier could propose a solution that avoids the need for that interface, but delivers the requirements - or capability sought after. MODAF Views can be used to specify both the requirements, and the constraints. Views can be either constraint or requirement based depending on their content. As such, their use in the requirements documents needs to be clarified as the content is developed. It can be generally said that Strategic & Operational Viewpoints are more appropriate to the Requirements space, whereas System and Technical Viewpoints, the constraints space. However, the views must be considered carefully, as there are exceptions. In the following text, views are identified as supporting requirements or constraints as appropriate to the data they contain. MODAF-M Version

29 3.4.1 User Requirements Document (URD) 79. 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 Deskbook 16 and the URD Reference Guide 17. Other guides are also available 18. The Views included in the URD, and provided by Customer 1 to the Acquisition Community, are shown in Figure 3-6 below. Concept IG Assessment MG Demonstration StV-6 StV-6 StV-6 Operational Viewpoint Suite OV-1 OV-2 Operational Viewpoint Suite OV-1 OV-2 Operational Viewpoint Suite OV-1 OV-2 Essential View Scenario/ Vignette 1 Scenario/ Vignette N OV-3 OV-5 OV-3 OV-5 Highly Desirable View TV-1 TV-1 Figure 3-6: URD MODAF Viewpoints through CADMID 80. Please refer to the Customer 1 Deskbook 16 and the URD Reference Guide 17 for further information regarding the URD creation process using MODAF. 16 MODAF-M MODAF-M For example, DCBM(Army) Guide to URD Development D CBM(A)/07/10/06 14 March 2005 MODAF-M Version

30 Acquisition Project Management Requirements CONCEPT ASSESSMENT DEMONSTRATION MANUFACTURE IN-SERVICE DISPOSAL Systems / Technology User Requirements Document (URD) StV-2 Industry Key View Set StV-6 OV-1 OV-2 OV-2 OV-3 OV-5 TV-1 OV-3 OV-5 TV-1 Through Life Management OV-1c SV-3 SV-7 SRD Integrated Testing, Evaluation and Acceptance Plan Essential View produced outside this workstream Essential View produced by this workstream Highly Desirable View produced outside this workstream Highly Desirable View produced by this workstream OV-5 Linkage between user and system requirements SV-5 SV-4 URD System Requirements Document (SRD) OV-7 OV-7 SV-1 SV-2 SV-2 SV-6 SV-3 SV-7 SV-4 TV-1 NB: The TV-1 contained in the SRD will be at a lower level than that in the URD. This more detailed TV-1 is created by the IPT, based on the high-level TV-1 in the URD. SV-6 SV-7 TV-1 Figure 3-7: MODAF relationship to Requirements Management MODAF-M Version

31 3.4.2 Linkage between User and System Requirements 81. 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. 82. The SV-5 shall be kept updated during SRD development to ensure the linkage with the URD Views is maintained 19. SV-5 Operational Activity to Systems Function Traceability Matrix acts as the glue between the URD and SRD Views. It is essential 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. 83. 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. 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. System Functions defined in SRD Operational Activities defined in URD Map to SV-4 System Functions Figure 3-8: SV-5 links the URD and SRD System Requirements Document (SRD) 84. 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 19 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. MODAF-M Version

32 Main Gate. Figure 3-9 shows how the MODAF Views that support the SRD mature during the acquisition lifecycle. Concept IG Assessment MG Demonstration OV-7 OV-7 System Viewpoint Suite SV-1 SV-2 SV-3 SV-4 SV-6 SV-7 System Viewpoint Suite SV-1 SV-2 SV-3 SV-4 SV-6 SV-7 Essential View Highly Desirable View TV-1 TV-1 Figure 3-9: SRD MODAF Viewpoints through CADMID 85. 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-6. StV-5 (if available) may also be useful in developing the SRD as an aid to identifying system options and interfaces. 86. The SRD, as with the URD, is comprised of requirements, stating what the new capability must provide; and constraints, relating to existing systems that the new system may need to communicate with in order to provide the required capability. It is important that the Requirements Managers do not lay down the solution within the requirements documents. Therefore, the constraints should be minimised, and any alternative solutions given consideration. 87. 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. 88. It is important that when creating the SV-4s, and, in fact, all of the SRD Views, the Requirements Manager focuses on the essential requirements for the system, not solutioneering the system itself. The SV-4 is used to show what functions the system must be able to perform, not how it is to perform them, as that will be up to the system designers to determine. MODAF-M Version

33 Figure 3-10: SV-4 Systems Functionality Description 89. Interface constraints can now be documented. Prior to Main Gate, only the key external interfaces, which provide interoperability constraints, will be modelled. The interfaces described here relate to constraints laid down by existing systems, with which the new system is likely to need to communicate. As with the SV-4, the Requirements Manager must ensure that only the essential interface constraints are included in these Views (and therefore in the SRD), to avoid undertaking system design. The interface constraints are documented using the following essential Views: a. SV-1 Systems Interface Description shows the interfaces that the new system is likely to need 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 Needlines show interdependencies with other systems, with which the new system will need to share information Figure 3-11: SV-1 Systems Interface Description b. 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: 90. 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 if it is MODAF-M Version

34 to communicate with the systems identified in the SV-1. These port specifications are therefore constraints applied by the external systems, rather than solution requirements for the new system design. Figure 3-12: SV-2a System Port Specification 91. SV-2b System to System Port Stack is used to assess the compatibility of the protocol stacks between multiple interfacing systems in order to provide interoperability assurance. Again, these are constraints laid down by the external systems, rather than solution requirements, and therefore design considerations rather than the design itself. Figure 3-13: SV-2b System-to-System Port Connectivity 92. SV-2c System Connectivity Clusters shows how the individual interfaces required might 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, and again shows external system constraints. MODAF-M Version

35 Figure 3-14: SV-2c System Connectivity Clusters 93. SV-3 Systems-Systems 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. These are constraints based on existing systems, and alternatives should be considered when deciding on the solution: this View should not in itself provide the solution design. Figure 3-15: SV-3 Systems-Systems Matrix 94. 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 once the design phase begins. 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, these should be developed by the customer at a high-level within the SRD, providing only constraints, not the solution, and increased in granularity by the supplier during system design. MODAF-M Version

36 Figure 3-16: SV-6 Systems Data Exchange Matrix 95. 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 constraints. 96. The performance requirements for each part of the system are then defined in an essential SV-7 Systems Performance Parameters Matrix. These relate to the capability requirements laid down in the URD, and should avoid determining the solution. 97. 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 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. 98. Finally, refining the TV-1 is essential during SRD development to define the system constraints with regards to standards, 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. 99. 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. MODAF-M Version

37 3.4.4 Integrated Testing, Evaluation and Acceptance 100. 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 liaise 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 added20) 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 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. 3.5 Systems / Technology 106. 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: a. Identification of technology and procurement options b. Demonstration of the ability to deliver integrated capability c. Technology insertion (during the In-Service Stage) 20 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. MODAF-M Version

38 107. 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. MODAF-M Version

39 Acquisition Project Management Requirements Systems / Technology Industry CONCEPT ASSESSMENT DEMONSTRATION MANUFACTURE IN-SERVICE DISPOSAL StV-3 Through Life Management Key SV-7 SV-9 View Set SV-9 TV-1 Identify technology and procurement options updated updated TV-2 Essential View produced outside this workstream Essential View produced by this workstream TV-2 OV-1c OV-2 Highly Desirable View produced outside this workstream Highly Desirable View produced by this workstream OV-3 SV-1 Demonstrate ability to deliver integrated capability SV-6 SV-9 SV-7 Technology insertion TV-2 Figure 3-17: MODAF Relationship to System / Technology workstream MODAF-M Version

40 3.5.1 Identify technology and procurement options 108. 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, System 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 Desktops may need upgrade in the long term to take advantage of new processors Figure 3-18: SV-9 Systems Technology Forecast 21 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. MODAF-M Version

41 111. The TV-2 Technical Standards Forecast 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 SV-7 Systems Performance Parameters Matrix 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 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 Demonstrate ability to deliver integrated capability 116. 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 Technology insertion 120. 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. MODAF-M Version

42 3.6 Industry / Suppliers 121. 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: a. Industry involvement b. System synthesis c. Contract negotiation d. Solution delivery e. Carrying out any agreed upgrades or improvements once the system is in the In-Service Stage 122. 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. MODAF-M Version

43 Acquisition Project Management Requirements Systems / Technology Industry CONCEPT ASSESSMENT DEMONSTRATION Through Life Management MANUFACTURE IN-SERVICE DISPOSAL OV-1 Key OV-2 Involve Industry View Set SRD SV-9 TV-2 System Synthesis URD Essential View produced outside this workstream Essential View produced by this workstream Highly Desirable View produced outside this workstream Highly Desirable View produced by this workstream Negotiate Contract SRD Deliver Solution StV-2 Figure 3-19: MODAF Relationship to Industry workstream StV-3 Carry out any agreed upgrades or improvements MODAF-M Version SV-8

44 3.6.1 Involve Industry 123. 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 Concept Graphic 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. Figure 3-21: OV-1b Operational Concept Description MODAF-M Version

45 128. 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. Attribute Measure Value As-Is Period of Time 1 Period of Time 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 Artillery Battery 30 rounds 40 rounds 60 rounds 100 rounds Sortie Rate Period to refuel and rearm and aircraft 4 hours 3 hours 2 hours 1 hour Figure 3-22: OV-1c Operational Performance Attributes 129. 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 System Synthesis 130. 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: a. The SRD Views, developed by the Requirements workstream b. 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 c. TV-2 Technical Standards Forecast, which, as discussed in the Systems and Technology workstream description, shows how the system needs to be futureproofed for the new accepted standards, also developed by the Systems and Technology Workstream Negotiate contract 132. 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 and standards. Furthermore, the boundaries within which system elements MODAF-M Version

46 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 Deliver the solution 133. 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 Carry out any agreed upgrades or improvements 134. Upgrades and improvements are identified by the 2nd Customer, 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 Taxonomy; 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. 3.7 Through-Life Management 136. 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: a. Through-Life Management Planning (TLMP) b. Integrated Logistics Support 137. 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. MODAF-M Version

47 Acquisition Project Management Requirements Systems / Technology Industry CONCEPT ASSESSMENT DEMONSTRATION MANUFACTURE IN-SERVICE DISPOSAL SV-9 TV-1 Through Life Management AcV-2 TV-2 Through-Life Management Plan SV-8 SV-8 OV-5 Integrated Logistic Support OV-1c Key NB: An OV-1c for the entire system will be produced by Customer 1 within the URD. The Through-Life Management workstream creates an instance of OV-1c pertaining to sustainability, maintainability etc of the system View Set Essential View produced outside this workstream Essential View produced by this workstream Highly Desirable View produced outside this workstream Figure 3-23: MODAF Relationship to Through-Life Management Highly Desirable View produced by this workstream MODAF-M Version

48 3.7.1 TLMP 138. 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. Concept IG Assessment MG Demonstration SV-9 SV-9 SV-9 Essential View SV-8 AcV-2 SV-8 AcV-2 SV-8 AcV-2 Highly Desirable View Figure 3-24: TLMP MODAF Views through CADMID 139. 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 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 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. Ongoing investment required over 60 months to implement Figure 3-25: SV-8 Systems Evolution Description 141. The TLMP also contains the detailed plans for the current phase. The AcV-2 SoS Acquisition Programme View shall therefore be refined as part of this planning activity. Figure 3-5 shows an example AcV-2. MODAF-M Version

49 142. 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 the 2nd Customer. The IPT should liaise with the relevant 2nd Customer to ensure that this integration occurs between the TLMP and CIP. The 2nd Customer Deskbook (MODAF-M10-005) contains further information regarding the Views contained within the Capability Integration Plan Integrated Logistic Support 145. 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. The OV-5 Operational Activity Model, from the URD, informs the ILS approach. Attribute Measure As-Is Value Period of Period of Time 1 Time 2 Target Availability Number of hours planned downtime 30 hrs/year 20 hrs/year 10 hrs/year 5 hrs/year Maintainability Support personnel required to sustain the system Reliability Number of hours unplanned downtime 10 hrs/year 5 hrs/year 3 hrs/year 1 hr/year Figure 3-26: OV-1c Operational Performance Attributes 146. 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). MODAF-M Version

50 4. Worked Example 147. 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) which is available via the MODAF Team (See Section 5) or can be directly accessed on the RLI via the IA website at the following URL: Architectural-Framework/index.htm 4.1 ISTAR Worked Example Introduction 151. 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 Form the IPT 152. 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. MODAF-M Version

51 ISTAR SYSTEMS KESTREL DISP START DISP FIN SPECS DISP START NEMESIS DISP START DISP FIN LOOKER SPECS Training Equipment LoD 'Segment' Project Phase Key to View Personnel Logistics I nf ormation Infrastructure Doctrine/ Organisation Concepts No outstanding issues Manageable issues Critical issues DLOD Absent Critical issues Pre-IG IG to MG MG to IOC IOC to FOC In Service Disposal Figure 4-1: AcV-2 provided by Customer 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. Service Area Service Applicable Elements Standard/ Policy ISTAR Governance Operations All fielded capability SOPs Acceptance All fielded capability ISTAR Acceptance Procedure MOD Strategy Systems Engineering SPECS 2 & interfaces MOD Systems Engineering Management Plan (SEMP) US Interoperability Communications/ Networking SPECS 2 external US communication network interfaces US Guidance Notes Sustainment & Logistics Ability to sustain capability SPECS 2 and DLoD support MOD Sustainment guidelines Figure 4-2: Initial TV-1 setting the standards and constraints for the IPT MODAF-M Version

52 4.2.2 Systems Engineering Management Plan 154. 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 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 things 22 ) which MODAF Views the IPT intends to use for the analysis and design of the SPECS 2 system Initial Gate 155. 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) Manage Dependency Risks 156. 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. 22 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 MODAF-M Version

53 ISTAR SYSTEMS SPECS 2 must be delivered along with KESTREL to fill the Capability Gap left by the disposal of SPECS and LOOKER KESTREL DISP START DISP FIN SPECS DISP START NEMESIS DISP START DISP FIN LOOKER SPECS Training Equipment LoD 'Segment' Project Phase Personnel Logistics No outstanding issues Pre-IG Key to View I nf ormati on Infrastructure Manageable issues IG to MG MG to IOC Critical issues IOC to FOC Doctrine/ Concepts Organisation DLOD Absent In Service Disposal Critical issues Figure 4-3: AcV-2 showing dependency with delivery of KESTREL 158. 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. MODAF-M Version

54 PJHQ BDE HQ ISTAR BASE STATION SPECS 2 Request SPECS 2 be prepared for Recce of target area Request launch of SPECS 2 Execute SPECS 2 launch procedure Take off Provide suspected target location Provide SPECS 2 search area coordinates Enter SPECS 2 search area flight profile Moves to search area flight profile Provide preferred target information requirements Request SPECS 2 provide live video footage/ data reports Configure SPECS 2 to provide video footage/ data reports Captures/ fuses live video footage/ data reports Decide whether to take action Provide target status Relay video footage/ data reports Figure 4-4: OV-5 from the URD 159. 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. Information Acquistion EPOCH 1 Information Management Effects Information Acquistion EPOCH 2 Information Management Effects Any requests to fulfil requirements outside of the Information Acquisition Capability are changes to scope EPOCH 3 Information Acquistion Information Management Effects Strategic - PJHQ Strategic - PJHQ Operational - JFHQ SPECS NEMESIS BISA FGA Operational - JFHQ NEMESIS BISA FGA Strategic - PJHQ Operational - JFHQ FGA Tactical - Brigade Tactical - Special Forces LOOKER CR2 MILAN Tactical - Brigade Tactical - Special Forces CR2 Tactical - Brigade Tactical - Special Forces BISA CR2 Figure 4-5: StV-5 showing the Capability gap to be addressed MODAF-M Version

55 4.2.5 Main Gate 161. 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 Place contract(s) to meet the SRD 163. The SRD development process is described in section Wind down of IPT 164. 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 165. 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 Develop and Maintain User Requirements Document (URD) 166. 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. MODAF-M Version

56 A. IDENTIFY TARGET URD VIGNETTE Information Acquisition Information Management Effects Recce X Collate Intelligence X Conduct Estimate X Coordinate Plan X X X Attack X X X Recuperate X Figure 4-6: StV-6 within the URD shows the Operational Vignette Figure 4-7: OV-1a showing identification of target Operational Vignette 168. The Performance Requirements for this Vignette are also extracted from the URD into the architecture, and viewed within an OV-1c. MODAF-M Version

57 Attribute Measure Target SPECS 2 Flight Time Maximum number of hours for a single flight SPECS 2 Range Maximum number of km from ISTAR base station SPECS 2 Downtime Number of days required for maintenance SPECS 2 Video Support Number of individual video channels provided SPECS 2 Video Delay Maximum time delay (seconds) viewing tasked location Figure 4-8: OV-1c showing Performance Requirements 169. 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 an extension to the OV-5, using use case documents containing richer information than is found in the standard OV-5 Operational Activity Model: Overview Primary Actors Supporting Actors 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. PJHQ SPECS 2 ISTAR Base Station Trigger Preconditions PJHQ requests SPECS 2 be prepared for Recce of target area. 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. 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. MODAF-M Version

58 9 PJHQ analyses video and data 10 ISTAR Base Station stores the video and data. Postconditions Post condition Extensions 1 PJHQ decides whether to take action. Variations Candidate Requirements SPECS 2 could not perform operation so other ISTAR or organic assets are tasked. Remarks Figure 4-9: Use Case document used as an extension to OV The use case is then broken down into a standard OV-5 Operational Activity Model, taking the scenario steps above, and laying them over the organisations that undertake each step in the process: PJHQ ISTAR BASE STATION SPECS 2 Request SPECS 2 be prepared for Recce of target area Execute SPECS 2 launch procedure Provide SPECS 2 search area coordinates Enter SPECS 2 search area flight profile 1 Take off Moves to search area flight profile Request SPECS 2 identify tagret Configure SPECS 2 to identify target Captures target video and data 9 Analyse video and data 8 Relay video footage/ data reports Decide whether to take action 10 Store video and data Figure 4-10: OV-5 derived from Use Case document 171. 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. MODAF-M Version

59 ISTAR BASE STATION 1 ISTAR TASK ORDER ISTAR INFORMATION 3 2 PJHQ SPECS 2 ISTAR INFORMATION ISTAR INFORMATION 4 ENEMY Figure 4-11: OV-2 showing information flows 172. 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. Figure 4-12: OV-3 provides Information Exchange Requirements MODAF-M Version