The Human View Handbook for MODAF: Part V â Appendices

The Human View Handbook 

for MODAF: 

Part V – Appendices 

The work described in this document has been undertaken by the Human Factors Integration 

Defence Technology Centre, part funded by the Human Capability Domain of the U.K. Ministry 

of Defence Scientific Research Programme. 

© BAE Systems 2011. The authors of this report have asserted their moral rights under the 

Copyright, Designs and Patents act, 1988, to be identified as the authors of this work. 

Reference ................................................... HFIDTCPIII_T02_02e 

Version ........................................................................................ 2 

Date ...................................................................... 11 August 2011 

© BAE Systems 2011. All Rights Reserved. Issued by BAE Systems on behalf of the HFI DTC consortium. The HFI DTC consortium consists of 

BAE Systems, Cranfield University, Lockheed Martin, MBDA, SEA, Southampton University and the University of Birmingham.

HFIDTCPIII_T02_02e 

Version 2/ 11 August 2011 

Author 

Anne Bruseberg 

Systems Engineering & Assessment Ltd. 

ii


Part 5: Appendices 

The Human View 

Handbook for MODAF: 

— Second Issue — 

July 2010 

page 1



DOCUMENT INFORMATION 

Purpose of the Human View Handbook 

The Human View Handbook for MODAF describes a set of Human Views (HVs) to be used 

as complementary elements to MODAF – the Ministry of Defence Architectural 

Framework. It aims to clarify the role of Human Factors (HF) when creating Enterprise 

Architectures in support of acquisition – in order to facilitate both Human Factors 

Integration (HFI) and Systems Engineering (SE). HVs aim to enable better integration 

across all the Defence Lines of Development (DLOD) and to aid Through-Life Capability 

Management (TLCM). 

Enterprise Architectures such as MODAF produce conceptual models of current and 

future systems. By modelling an enterprise as a whole, MODAF provides an overview 

perspective that aids acquisition management and collaboration between diverse 

disciplines. Therefore, it is an important tool for helping to fulfil the prime objectives 

of HFI – those of integrating the different HFI domains, integrating with other 

engineering disciplines, managing the need for HFI activities, and informing trade-off 

analyses. 

HVs clarify the scope of enterprises as socio-technical systems. HVs capture specific 

human-related components of enterprise models to enable effective HFI. By explicitly 

modelling the human elements that are being shaped in the process of capability 

design, they can be considered early and related closely to the design and 

implementation of technology. This supports a change of focus from technologycentred 

functional requirements only to broader capability-based requirements. 

The HVs aim to support any practitioner who needs to consider the human elements of 

Enterprise Architectures. The role of applying HVs may fall to experts with either 

Human Factors or Engineering backgrounds who plan and design future technologies 

and/or infrastructure, human networks, organisations, operations, or personnel 

processes, including the relationships between these aspects. 

Contents 

The HV Handbook is broken up into five separate documents: 

Part 1 provides a high-level introduction to concepts, benefits and use; 

Part 2 provides an in-depth technical description and justification of HVs; 

Part 3 provides guidance on the underlying processes and methods needed to 

support planning and generating HVs; 

Part 4 provides example applications to illustrate HV use, based on experiences 

from realistic projects, including a collection of HV example instantiations; 

Part 5 provides additional useful resources through several appendices. 

Table 1 provides an overview of the document structure. Note that the four main 

sections partition the document. However, the main headings run through these 

sections with continuous numbering (to avoid too many levels). 

Complementary to the HV Handbook, the ‘Human View Quick Start Guide’ provides a 

condensed technical overview of the HVs that can function as a quick reference guide. 

page 2



Table 1: The contents of the HV Handbook, with a brief outline of each section. 

Part I: 

Introduction 

Section 

Description 

Part I: Overview & Short Introduction 

1 Introduction 

to Human 

Views 

Provides a high-level introduction to the Human Views covering the most 

essential aspects on purpose, benefits, use and technical content. It provides a 

condensed summary to help judge whether the implementation of HVs is 

appropriate, and what for. 

Part II: 

Technical Description 

Part III: 

Process Guidance 

Part II: Technical Background and Detailed Human View Descriptions 

2 HVs to 

support 

MODAF as an 

Enterprise 

Architecture 

3 The Role of 

HFI 

4 Joining HFI 

and MODAF 

perspectives 

5 Overview of 

Human Views 

6 Detailed 

descriptions 

To introduce the role of MODAF as an Enterprise Architecture, its purpose, 

structure, principles and use are explained, and to justify the need for modelling 

people-related elements explicitly. The HVs were tailored to the main 

characteristics of an architectural model. 

To introduce the role of HFI in relation to enterprise design as part of acquisition 

processes, the HFI process, HFI benefits, and HFI functions are expanded on. 

Some example cases are given to illustrate the problems that may occur when 

not involving HFI sufficiently. 

Approaches and terminology differ between HFI and SE. The HVs need to bring 

together perspectives from both HFI methodologies and architectural modelling 

approaches. The differences are discussed to be able to bridge them better. 

Potential relationships of the HVs with MODAF are discussed. 

The HVs are introduced, including their purpose and benefit, and definitions of 

what HVs are (and are not). The relationship with MODAF layers and technical 

themes is clarified. The HV meta-model is introduced, which specifies the HV 

data elements and their dependencies. The function of HVs in filling gaps in the 

MODAF meta-model and view descriptions is introduced. 

Each HV (HV-A through to HV-G) is described in depth, including its 

• Function (providing a summary of its focus and purpose) 

• Benefits and use (including justifications for using the View) 

• Data elements (defining the meta-model elements, and listing relationships 

with relevant MODAF Views and MODAF meta-model definitions) 

• Visualisation options (describing or illustrating ways in which the HV can be 

presented), including examples to show how the HV may be applied for its 

different instantiations). 

Part III: Applying Human Views: Process and Methods 

7 Aims of the 

process 

guidance 

The purpose and content of sections 8 to 10 are outlined, in providing guidance 

on how to plan, use and implement HVs, and how to progress creating the Views. 

Section III is organised in line with the generic MODAF Architecting Process. It 

describes decision variables for scoping and detailing project-specific use by a 

wide range of potential stakeholders, rather than narrowly tailored answers. 

8 The Purpose The section puts HVs in the context of the processes that it needs to support, and 

responds to the questions: 

• Why consider HVs (i.e. deciding whether to use MODAF and HVs in principle) 

• What to use HVs for (i.e. deciding on purpose and focus of HV use, when 

establishing architecting project boundaries in line with the envisaged 

benefits). This includes generic principles for architecture generation and use, 

which are important for understanding the role of HVs and their application. 

page 3



9 The Process Process guidance is provided addressing the question of which HVs to produce, as 

well as when, at what depth, and by whom. The section expands on the 

technical process to planning the progression of HV creation (e.g. starting point, 

order, level of validation). It outlines a three-dimensional approach including: 

• The process of iterations from initial concepts to agreed baseline models. 

• The process of moving through different levels of abstraction. 

• The process of choosing which technical areas are relevant, and how to iterate 

between them. 

It aligns HV generation with the generic technical architecting process and 

illustrates a sample progression. It discusses specific stakeholder roles and 

outlines HV use for the five MODAF Communities of Interest (COI). 

Part IV: 

Examples 

Part V: Appendices 

10 The Methods Specific technical approaches and methods for informing, generating, assessing, 

and managing HVs are provided. A table outlining HFI methods, data and 

activities for each HV, and its data elements, is included. HFI guidance is 

provided for how to inform existing MODAF Views, by relating them to HFI design 

areas, HFI activities, and HFI methods. 

Part IV: Examples Illustrating HV Use 

11 Example: 

Maintenance 

System 

12 Example 

Applications 


APPENDIX A 

APPENDIX B 

APPENDIX C 

APPENDIX D 

APPENDIX E 

APPENDIX F 

APPENDIX G 

APPENDIX H 

The section provides a practical illustration of HVs for a specific project that 

dealt with the design of a ‘paperless’ maintenance system for aircraft. The 

examples were produced in a realistic environment, which included accessing 

project data and discussion with a Subject Matter Expert (SME). The section 

includes HV examples, as well as an overview of the process used, with the 

specific benefits and the approach to generating views. 

The section provides several example application overview to illustrate the 

different types of applications that have been observed from projects in realistic 

settings. 

The MODAF Views explained: Provides a brief description of all MODAF Views 

(except the service-oriented Views). It is recommended to also refer directly to 

the MODAF documentation (MoD 2008a) for a more comprehensive description. 

The MODAF Process for Creating Architectures: Summarises the official MODAF 

architecting process. 

NATO HFM-155 HVs: Provides an overview of the HVs developed by a NATO 

Research Panel, and how they compare to the UK HVs. 

The HFI Process: Provides an overview of the HFI Process in relation to the 

People-in-Systems Requirements and Assurance Process. 

HFI Risk Assessment Checklist: Outlines a high-level list of criteria to assess 

technical and project risks related to HFI, including a rating mechanism. 

HFI Cost-Benefit Analysis: Introduces a process for assessing HFI project risk in 

cost terms and planning HFI activities in financial terms to reduce overall risk. 

HV Overlays on COI Processes: Uses the flowcharts from the MODAF Deskbooks 

(MODAF 2005b, c, d, e, f) to illustrate where HV support can be beneficial. 

Processes used for individual project applications: describes a series of example 

processes from various applications that have been applied and populated HVs. 

page 4



Who should read which section 

Table 2 provides a guide to the envisaged readers for each section. According to 

stakeholders’ roles in either planning or conducting people-related modelling activities 

as part of architectural modelling, the level of required detail varies. The interest is 

likely to vary for stakeholders who: 

Make decisions about the need for investments in architectural modelling, including 

the extent to which HVs are beneficial (type ‘A’); 

Plan the modelling requirements for people-related elements when envisaging the 

use of Architectures for the design of socio-technical systems (type ‘B’); 

Need to directly produce people-related elements of an Architecture (type ‘C’). 

Table 2: Envisaged readership for the HV Handbook sections. 

Section For whom A B C 

Part I: Introduction 

1 Introduction to Human 


Aimed at MoD stakeholders judging the need for MODAF and HV 

developments, to help understand their purpose, content and 

fundamental implementation options 

Part II: Technical Description 

2 HVs to Support MODAF 

as an Enterprise 

Architecture 

Provides fundamental information on MODAF for all stakeholders 

without a prior understanding of architectural frameworks 

3 The Role of HFI For all engineering and project management experts without an 

understanding of HFI – to clarify the benefits and the process 

4 Joining HFI and MODAF 

perspectives 

5 Overview of Human 


For all stakeholders aiming to understand the challenge and 

implications of bringing together ‘soft’ people-related and 

engineering disciplines under the same framework 

For all MoD, Industry or Academia stakeholders aiming to gain a 

high-level overview of the entire HV set 

6 Detailed descriptions The reader should have some understanding of HFI, Systems 

Engineering and Architectural Frameworks – particularly MODAF 

Part III: Process Guidance 

7 Aims of the process 

guidance 

For stakeholders interested in finding out about the structure 

and content of the entire process guidance 

X X X 

X 

X 

X 

X 

X X X 

8 The Purpose For those judging on the need of applying HVs overall X X X 

9 The Process Aimed at those who plan the use of architectures and HVs X X 

10 The Methods For practitioners applying HVs X 

Part IV: Examples 

11 Example: Maintenance 

System 

For stakeholders seeking additional illustration materials through 

a concrete example application 

12 Example Applications For those who would like to learn about evidence and experience X X X 

from HV applications 


APPENDIX A & B For stakeholders seeking a more expanded overview of MODAF X 

APPENDIX C For stakeholders interested in the NATO HV concept X 

APPENDIX D, E F For stakeholders seeking more detail on HFI X 

APPENDIX G 

For stakeholders preferring HV process guidance to be organised 

X 

around flowcharts capturing key MoD activities 

APPENDIX H 

For stakeholders seeking further illustration on the HV process 

followed for selected HV example applications 

X 

X 

X 

X 

X 

X 

X 

page 5



Version history 

The current document constitutes Issue 2 of the HV Handbook. It introduces a 5-part 

structure and has been extended with an introductory overview section. It includes a 

clarified perspective on whether or not HVs should be seen as extensions of existing 

Views or as additions. Related to this, the HV meta-model has been updated and 

brought explicitly in line with the MODAF meta-model to ensure compatibility of 

concepts, dependencies and terminology. This includes a version of the HV metamodel 

in Unified Modelling Language (UML) format. An overview of concrete example 

applications too date was added to provide additional practical guidance. 

Previous Drafts and Issues include: 

A first draft version of the HV Handbook was completed as the basis for expert 

assessment and discussion in March 2007. It was based on MODAF v 1.0. It included 

a first description of the technical HV concepts only. 

Issue 1 of the HV Handbook (HFI DTC 2008) has been issued for publication on the 

HFI DTC website in July 2008. It was aligned with MODAF v 1.1, and followed a 

substantial revision of initial concepts, ready to be the basis for feedback from first 

applications. It included in-depth technical descriptions of the revised HVs. An 

introductory section was added to provide background on MODAF and HFI, and the 

options for better alignment. 

A Draft Issue 2 of the HV Handbook has been brought in line with MODAF v 1.2 

definitions. It implemented a series of updates to technical HV descriptions and 

context information. Substantial new material has been added providing guidance 

on processes and methods for how to plan HV use and creation, and how to populate 

HVs. A practical example has been added as well as a series of Appendices to 

supplement the process guidance. 

Further Information 

Further background detail on the HV development, related materials, and reasoning 

underlying the HVs (prior to Issue 1) can be found in an associated HFI DTC report 

(Bruseberg 2008c). 

Additional information can also be found in the following papers: 

“Human Views for MODAF as a Bridge between Human Factors Integration and 

Systems Engineering” (Bruseberg 2008d). It provides an overview and outlines links 

to Cognitive Systems Engineering approaches. 

“Applying the Human Views for MODAF to the conception of energy-saving work 

solutions” (Bruseberg 2008b). It discusses an example application. 

“Human Factors Integration for MODAF: Needs and Solution Approaches” (Bruseberg 

& Lintern 2007). It discusses the need for HVs, and provides an early concept 

overview. 

page 6



Table of Contents 

APPENDIX A The MODAF Views Explained ........................ 8 

APPENDIX B 

The MODAF Process for Creating Architectures13 

APPENDIX C NATO HFM-155 HVs ................................. 15 

APPENDIX D The HFI Process ..................................... 15 

APPENDIX E HFI Risk Assessment Checklist .................... 19 

APPENDIX F HFI Cost-Benefit Analysis .......................... 21 

APPENDIX G 

HV Overlays on MODAF Community of Interest (COI) Processes 22 

APPENDIX H 

Processes used for Individual Project Applications ............... 34 

H.1 Introduction ...................................................................................................... 34 

H.2 NITEworks ........................................................................................................ 35 

H.3 Commander’s Update Brief .............................................................................. 38 

H.4 Tele-working example ...................................................................................... 40 

H.5 UAV Scenario ................................................................................................... 43 

H.6 Maintenance Project ........................................................................................ 45 

Acknowledgements ................................................................................................. 46 

References .......................................................................................................... 46 

Acronyms .......................................................................................................... 50 

page 7



APPENDIX A 

The MODAF Views Explained 

Table 3 summarises main aspects of the Views from the MODAF 1.1 and DODAF 1.0 

documentation (DoD 2004b, MoD 2007) and supplementary sources of information 

(Dickerson et al 2004, DoD 2004a), with an HFI perspective. It is indicated whether the 

Views are specific to MODAF or DoDAF. 

Note, the service oriented views added in MODAF version 1.2 are not included here. 

View 

AV- 

1 

AV- 

2 

TV- 

1 

TV- 

2 

AcV 

-1 

AcV 

-2 

StV- 

1 

StV- 

2 

StV- 

3 

StV- 

4 

DoDAF Title 

Overview and 

Summary 

Integrated 

Dictionary 

Technical 

Standards 

Profile 

Technical 

Standards 

Forecast 

MODAF Title 

Overview & 

Summary 

Information 

Integrated 

Dictionary 

Table 3: MODAF and DoDAF View summaries and comments. 

Comments on perceived function 

• Provides information about the architecture such as project details, scope, purpose, context, formats, findings. 

Expressed in textual bulleted format. 

• It classifies model elements – usually in a hierarchical manner. 

• The generic MODAF ontology should be drawn on. 

• Defines terminology and acronyms. 

Standards Profile • A Standards Profile is created that is specific to the architecture, where general standards may be tailored. 

• Tabular representation; Can include HCI standards. 

Standards 

Forecast 

Acquisition 

Clusters 

Programme 

Timelines 

• Relates emerging standards to technological developments and project development timescales. 

• May combine this product with others that have timescales (e.g. technology forecast). 

• Defines acquisition programmes. 

• Deals with dependencies between projects to integrate capabilities across DLOD. 

• Identifies similarities and links between projects to define programmes. 

• A programme consists of several projects, based on identifying “hierarchies of acquisition clusters”. 

• Always for multiple projects. 

• More AcV-1s are to be developed later to track progress over time as new systems are introduced into the acquisition 

programme. 

• Is intended to draw in all DLOD: “The inclusion of the DLOD information allows areas of concern that are outside of the 

immediate scope of an Integrated Project Team (IPT) to be considered. Areas of concern identified across the DLOD, 

e.g. a shortfall in training resource, can be co-ordinated across a programme or group of projects, each of which require 

additional activity to be initiated to successfully deliver to the project/programme schedule.” 

Enterprise Vision • Guidance on future capabilities based on research for needs (unless the purpose of the Architecture is to describe an 

existing system). 

• Includes information on development priorities (e.g. UK Joint Vision; lean, agile robust networks) and key operational 

doctrine concepts (e.g. Prepare, Project, Protect, Sustain) for NEC. 

Capability 

Taxonomy 

Capability 

Phasing 

Capability 

Dependencies 

• Development of StV-1 into a specific set of defined capabilities that are organised hierarchically and broken down into 

sub-functions/tasks. 

• Metrics are supplied separately. 

• Can be represented in UML (a diagram of boxes within boxes). 

• Provides an overview of what capability may be available during which time scale through which major technology 

developments. 

• Capability gaps are visualised through absence of capability (bar) in Epoch. 

• Groups capabilities into clusters based on integration needs – the source of which are not further specified and left to 

the analysts. 

• Relationships are expressed as (one-way) dependencies where one capability depends on another. 

• The nature of the dependency is not specified in the examples given. 

• The Capabilities are abstract functional concepts that are not to be expressed through physical instantiations. The 

abstraction level may depend on the scope of the architecture. 

page 8




StV- 

5 

StV- 

6 

OV- 

1a 

OV- 

1b 

OV- 

1c 

OV- 

2 

OV- 

3 

DoDAF Title 

High-Level 

Operational 

Concept Graphic 

Operational 

Node 

Connectivity 

Description 

Operational 


Exchange Matrix 


Capability to 

Organisation 

Deployment 

Mapping 

Operational 

Activity to 

Capability 

Mapping 

High-Level 

Operational 

Concept Graphic 

Operational 

Concept 

Description 

Operational 

Performance 

Attributes 

Operational 

Node 

Relationships 

Description 

Operational 




• This is used as a more expanded version of StV-3 – to identify and manage capability gaps. 

• Provides a high-level summary of how capabilities relate to organisational units and technology developments, for 

different time periods of planning. 

• Draws in many other resources and has a pivotal overview role by drawing in a number of different issues – mainly for 

planning development management purposes. 

• This View aids strategic planning. Its role is to understand dependencies in the context of development periods, but 

also provides a point for assessing dependencies. 

• Involves assessment of technology legacy and new development issues. 

• Includes assessment of resources in relation to constraint of time-based availability. 

• Requires StV-2 and OV-5 elements being defined as a basis for mapping between them. 

• This view is seen as part of the requirements specification process for URD, preceding the OVs. 

• It is used later for URD management and updates and Operations Planning. 

• Vignettes may be identified that create a subset of concerns. 

• It maps the high-level capability definitions to the OV functional descriptions (i.e. activities). 

• Provides mapping between two abstraction levels (used again in SV-5). 

• Pictorial representation of an envisaged conceptual solution using a representative scenario that shows network nodes 

including envisaged technologies, and effects on enemies, through graphic or symbolic representations. 

• It includes notions of: location; distance; terrain constraints; types of connectivity and effects directions; organisational 

units; environment (e.g. sea, space, air, land). 

• The picture may be updated when changes to the solution are required later. More detail as to chosen technologies is 

added later. 

• This is an informal representation to be used as a communication tool. 

• There may be several OV-1’s, based on several vignettes from StV-6. 

• Summarises exemplary physical constraints and example solutions. 

• Textual explanation of OV-1a. 

• May include other media such as further pictures, or videos. 

• (OV1b is not an explicit view in DoDAF, but understood as needed). 

• Expanding on quantifiable attributes and values of OV-1a (e.g. Operational tempo, Accuracy of targeting, Fratricide 

rate). 

• Intended to provide performance targets for different conceptual time scales (e.g. short, medium, long-term 

development). 

• Specification of target values and priorities. 

• Basis for later assessments of detailed solutions. 

• A node is an abstraction that can have varying boundaries and definitions. Likewise, the information exchanges 

depicted are abstractions: “OV-2 is not a communications link or communications network diagram.” 

• Location information and Flows of material and people may be annotated but are seen as context. 

• There is a close relationship with OV-5 where node activities are defined. 

• Information exchanges are further specified in OV-3. 

• Nodes may be perceived as organisational groupings of some sort that may later be instantiated with people and/or 

technology elements. 

• MODAF understands nodes as more abstract than DoDAF, and discourages depictions where resources are directly 

overlaid onto the nodes. 

• Sometimes higher-level groupings are overlaid to node breakdowns and connectivity. 

• This is an essential View that aims to optimise (and minimise) information flows between conceptual units of operation 

(that are defined here). 

• Information types and purposes are defined. 

• Potential for adding HFI related criteria that further elaborates on information exchange purposes and may inform OV-4. 

• Includes a column that specifies interaction types, such as “collaboration”. 

page 9




OV- 

4 

OV- 

5 

OV- 

6a 

OV- 

6b 

OV- 

6c 

OV- 

7 

DoDAF Title 

Organisational 

Relationships 

Chart 

Operational 

Activity Model 

Operational 

Rules Model 

Operational 

State Transition 

Description 

Operational 

Event Trace 

Description 

Logical Data 

Model 


Organisational 

Relationships 

Chart 

Operational 


Operational 

Rules Model 

Operational 

State Transition 

Description 

Operational 

EventTrace 

Description 


Model 


• Mainly specifies formal human organisational structure, based on existing ones to a large extent. 

• Primarily defines organisational units and their command relationships in a hierarchical way 

• May extend to role level definitions (at later stages of framework). 

• Besides command relationships, it may include different types of relationships: 

• Organizations with a primary role and those with a supporting role (DoDAF); 

• Coordination or other specified relationship (MODAF). 

• Includes both hierarchical breakdown presentations and flow presentations. 

• For requirements engineering, MODAF suggests that operational views are intended to be independent of (technical) 

solutions. The focus should be on requirements rather than constraints. Solutions are, in the operational perspective, 

to be seen as constraints. 

• Is encouraged to draw on high-level mission-specific paradigms such as Detect/Control/Engage. 

• May be detailed using standard operational activities (e.g. from (US) Universal Joint Task List (UJTL) or Servicesderived 

task lists). 

• Captures activity constraints from an operational perspective, through the identification of rules that deal with 

constraints. 

• Is not intended to be at the level of detailed human activity. 

• There is a notion of dynamic behaviour in the identification of IF/THEN rules. 

• Further specifies information from OV-1, and closely relates to and extends OV-5. 

• There is no UML representation; Textual rules may be attached to OV-5 diagrams; Operational rules can be expressed 

in a number of different formats: e.g. structured English; decision tree. 

• Models behaviours through describing transitions. 

• Represents a dynamic analysis, simulation tools are recommended in DoDAF (e.g. Colored PetriNets). 

• Captures action sequences in relation to conditional and state changes that underlie rule definitions. 

• Captures alternative event/action flows for different conditions. 

• Captures elements of larger flow, defined through beginning and end point. 

• State is understood as an action lasting until a certain output/trigger has been reached that triggers the next action. 

• Cognitive tasks (e.g. planning strike) may be included with an outcome (planned strike), without going to detail of 

modelling underlying cognition. 

• They may be related to nodes, but appear to be understood as human activities (person or organisation). 

• DoDAF suggests use for workload assessments. 

• Time information is added for more detailed descriptions of operations. 

• Does not describe tasks as a whole but specific scenarios. 

• Deals mainly with timely availability of information for (human) nodes and tasks. 

• Describes ‘operational threads’ that further define capabilities. 

• Describes events (i.e. information communication events) and times at which ‘nodes become aware of the events’. 

• Includes sequencing/precedence, actual time descriptions, logical conditions, and timing constraints. 

• Depicts directions for the flow of control from one node to another. 

• May include ‘junctions’ that describe decision logic that may lead to several subsequent path options. 

• Specifies system information needs, as a basis for system specification. 

• Defines operational rules that govern system data (types, characteristics, relationships). 

• Classification of the information types being used as part of the system – i.e. business information requirements 

specification. 

• Supports interoperability through common standardised definitions of data types to be produced, exchanged, and used. 

• Defines new data: “may be necessary for interoperability when shared system data syntax and semantics form the basis 

for greater degrees of information systems interoperability, or when a shared database is the basis for integration and 

interoperability among business processes and, at a lower level, among systems.” 

page 10




SV- 

1 

SV- 

2 

SV- 

3 

SV- 

4 

SV- 

5 

DoDAF Title 

Systems 

Interface 

Description 

System Port 

Specification 

Systems- 

Systems Matrix 

Systems 

Functionality 

Description 

Operational 

Activity to 

Systems 

Function 

Traceability 

Matrix 


Resource 

Interaction 

Specification 

2a System Port 

Specification 

2b System Port 

Connectivity 

Description 

2c System 

Connectivity 

Clusters 

Resource 

Interaction Matrix 

Functionality 

Description 

Function to 

Operational 

Activity 

Traceability 

Matrix 


• Defines the system elements to be used to fulfil the information needlines between operational nodes defined in OV2 

(i.e. technical instantiation of nodes and needlines). 

• Specifies system nodes that correspond to operational nodes (and may be identical); MODAF defines the concept of 

‘Physical Asset’ that are instantiations of Nodes; DoDAF defines ‘System Node’: “The term System Node describes a 

logical or physical deployment for Operational Nodes – e.g. locations, Platforms, units, facilities, etc”. 

• Identifies system boundaries, and breaks down systems into system elements. 

• Identifies hardware and software needs, and their relationships based on communication links between resource 

elements (i.e. system interfaces). 

• Systems are understood as interconnected technology: ”The term system … is used to denote a family of systems 

(FoS), system of systems (SoS), nomenclatured system, or a subsystem. An item denotes a hardware or software 

item”. 

• DoDAF does not distinguish a,b,c; is most like the MODAF SV-2c. 

• SV-2 defines specific communication links or communication networks between systems, thus adding more detail to SV- 

1 (“comprehensive specification of how systems are connected,”); seen as key for NEC strategy: “quickly plan and 

visualise how communications between systems are to be implemented”; details abstract specifications. 

• SV-2a defines the hardware/software that communicates between technical system components. 

• SV-2b specifies how the protocols connect the ports, and shows which systems they connect; May be all in one diagram 

or a set of diagrams: “The architect may choose to create a diagram for each connection in the Architecture 

(recommended) or to show all the connections on one diagram (may be harder for readers to follow)”. 

• SV-2c provides a grouping of system-to-system connectivity into node-links (i.e. clusters) – thus abstracting back to a 

functional perspective; e.g. node-link may be ‘situational awareness’ ‘operational feedback, ‘e-mail’; No detail is given 

as to how the groupings should be derived; Helps to assess specified communication networks regarding redundancy 

and performance by considering constraints: 

“… 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”. 

• Provides an overview of the interfaces identified in SV-1, and draws attention to important ones (‘key’). 

• Specifies different types of relationships depending on purpose of representation: “examples: a. Status, (e.g., existing, 

planned, potential, deactivated), b. Purpose, c. Classification level, d. Means, e. Standard, f. Key Interface”. 

• Alternatives are encouraged: “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”. 

• Combines a functional breakdown into subcomponent functions with functional flow describing system behaviour. 

• Describes functional level only – not embodiment: “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.” 

• “Actors in systems use case diagrams may represent a mix of both the humans supported by the system functions 

…and other systems external to the system being described but not necessarily external to the architecture.” 

• “System functions are not limited to internal system functions and can include Human Computer Interface (HCI) and 

Graphical User Interface (GUI) functions.” 

• “Class diagrams are used to show static relationships between system functions. These diagrams collectively describe 

the systems support to the operational activities and operational use cases modeled in OV-5”. 

• Provides a matrix that traces the reasoning behind the definition of system functions to the operational needs (i.e. the 

activities/operational functions that are needed by the joint system). 

• Operational activities should not be understood here as human tasks (whilst they need to be supported by human 

functions). 

• May be used as mapping between URD and SRD items. 

• Provides a link between OV-5, 6b, 6c and SV-4: “Although there is a correlation between ... (OV-5) or business-process 

hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for... 

(SV-5), which provides that mapping”. 

page 11




SV- 

6 

SV- 

7 

SV- 

8 

SV- 

9 

SV- 

10a 

SV- 

10b 

SV- 

10c 

SV- 

11 

DoDAF Title 

Systems Data 


Systems 


Parameters 

Matrix 

Systems 

Evolution 

Description 

Systems 

Technology 

Forecast 

System Rules 

Model 

Systems State 

Transition 

Description 

Systems Event- 

Trace 

Description 

Physical 

Schema 


Systems Data 


Resource 


Parameters 

Matrix 

Capability 

Configuration 

Management 

Technology & 

Skills Forecast 

Resource 

Constraints 

Specification 

Resource State 

Transition 

Description 

Resource Event- 

Trace 

Description 


• Physical detailing and specification of data exchanges: “For example, the Levels of Information Systems Interoperability 

(LISI) level required for the operational information exchange is replaced by the LISI level achieved through the system 

data exchange(s)”. 

• Specific step after a series of system specification steps based on SV-1, SV-2 and OV-3: 

• “On SV-6, each operational Needline is decomposed into the interfaces that are the systems equivalents of the 

Needline”. 

• “The system data exchanges documented in SV-6 … constitute the automated portion(s) of the OV-3 information 

elements”. 

• Specifies achievement criteria of system elements, system functions, and interfaces. 

• Focus is on identifying parameters that are measurable. 

• Relates current performance parameters to future ones for different timescales. 

• Basis for acquisition decisions and product assessments. 

• May include performance range – thresholds, objectives, measures (e.g. time/speed). 

• May include parameters for ISO software quality criteria (maintainability, effectiveness). 

• Defines project milestones for system development over large timescales of operation. 

• Distinguishes evolution and migration: 

• Planning aid for system’s time scopes in operation from a technical constraint perspective; 

• Expressed as timeline annotated with milestone descriptions and system version numbers; 

• Recognises that system design is not final after initial implementation and further adaptations are required. 

• Tracks new technologies that will become available: “Emerging technologies and software/hardware products that are 

expected to be available in a given set of time frames and that will affect future development of the architecture”. 

• Within the bounds of architecture purposes being described. 

• MODAF now includes notions for availability of skills through actual human resources. 

• Applies to system rules only: “The Systems Rules Model (SV-10a) has the same format as the Operational Rules Model 

(OV-6a); however, the scope and applicability of the rules here are for individual systems, where OV-6a applies the 

architecture as a whole”. 

• Few examples are given and the expression is fairly open: “UML constraints are a direct analogue and have been 

stereotyped to “SystemConstraint””. 

• Rule types are given: “Systems rules can be expressed in natural language, as with OV-6a: 

a. Imperative – a statement of what shall be under all conditions – e.g. “B shall be less than 6.0” 

b. Conditional Imperative – a statement of what shall be, in the event of another condition being met – “If B is equal to 4 

then A shall be true”. 

• DoDAF users specified are Designer/ Builder/ Contractor only. 

• Dynamic description of actions by specifying sequences related to conditional events triggering actions and state 

changes; Focus is on graphical representation. 

• Closely related to other SV-10 products: “Both SV-10b and SV-10c describe systems responses to sequences of 

events. Events may also be referred to as inputs, transactions, or triggers.” 

• Can be presented at different levels of abstraction. 

• Closely relates to scenarios and focuses on critical sequences of events only: “allows the tracing of actions in a scenario 

or critical sequence of events”. 

• Adds an explicit time dimension. 

• Includes interactions with human roles, thus specifying activities at human-computer interfaces. 

• Deals with assessments of information availability and communication activities. 

• At a low level of detail. 

Physical Schema • Solution design, not requirements anymore: “closest to actual system design in the Framework”. 

• Format may vary. 

• Specifies options. 

• Besides specifying solutions to OV-7, it relates to other SV products: “Object classes defined here should trace to (a) 

system data flows in SV-4, (b) system data elements specified in SV-6, (c) transition triggers in SV-10b, and/or (d) 

events in SV-10c”. 

page 12



APPENDIX B 

The MODAF Process for Creating 

Architectures 

Table 4: Summary of the MODAF Architectural Process (for MODAF version 1.2), 

related to high-level HFI process questions (last column). 

Prerequisites 

Step 1 – Establish Intended Use 

Step 2 – Define Architecture Scope 

Activities & 

Deliverables 

Activities: 

User Training - 

MODAF 

Principles 

Activities: 

Workshop: 

determine 

architecture 

usage 

Deliverables: 

Architectural 

Use Document 

Activities: 

Workshop: 

bound 

architecture 

scope 

Workshop: 

determine use 

cases 

Deliverables: 

Architectural 

Scope 

Document 

Plan of Time 

and Resources 

Tasks Task breakdown HFI outputs and 

key questions 

Introductory course 

regarding the use of 

MODAF within their 

Communities of Interest 

(COIs) 

Determining and 

documenting the 

intended usage of the 

architecture 

COI specific usage of 

MODAF architectures 

Content and boundaries 

of the architecture 

A list of the key MODAF 

Views that are expected 

to be produced 

How the architectural 

information is likely to be 

presented 

Any modified MODAF 

Views needed 

• MODAF architecture development approach 

• Available views 

• Expected nature of architectural activities 

associated with their COI. 

• Workshop that includes all of the potential 

stakeholders who are expected to provide 

data to and / or utilise the resulting 

architecture 

• Identification of capability gaps / overlaps – 

Capability Sponsor 

• Develop and trade-off capability options in 

order to optimise the overall Equipment 

Programme – Capability Sponsor 

• Develop a clear understanding of the 

operational context and use cases in support 

of URD production – Capability Sponsor, 

Acquisition, The User 

• Establish system boundaries and interfaces, 

including interoperability analysis – 

Acquisition 

• Documentation of applied concepts (CONUSE, 

CONEMP, CONOP) – Concepts and Doctrine 

• Process scope 

• Organisational scope 

• Systems / platforms scope – including those 

that have to be interfaced with 

• Geographic scope 

• Coverage of the Defence Lines of 

Development 

• Timescales that are to be considered (e.g. 

‘as-is’, ‘to-be’, circa 2015, etc) 

• Degree of granularity that is to be modelled 

(e.g. system, subsystem or component) 

• Guidance for which can be found in the 

relevant MODAF COI deskbook(s) 

• Inform the MODAF governance processes 

Decision as to 

whether to 

commit resources 

to MODAF HV 

development 

Why consider 

HVs 

Purposes of 

models across 

COIs 

What to use HVs 

for 

Content and 

resource 

requirements 

plan for 

architecture 

development 

Process: 

Which HVs when, 

at what depth, 

by whom 

page 13



Step 3 – Develop Data Requirements 

Step 4 – Capture Architecture 

Step 5 – Conduct Analyses 

Activities: 

Workshop: 

establish data 

needs 

Deliverables: 

Data gathering 

plan 

Tool selection 

Activities: 

Tool-specific 

training 

Baseline 

architecture 

review 

Deliverables: 

Baseline 

architecture 

Activities: 

Analysis 

review 

Deliverables: 

Initial analysis 

Final analysis 

Establish a datagathering 

plan 

Inform the MODAF 

governance processes of 

the architecture’s 

intended scope; 

Consider tool selection; 

Start AVs 

Provide tool-specific 

training; 

Importing and editing 

extant architectural 

model; 

Capturing additional data 

and entering it into the 

architecture 

Accuracy and validity is 

confirmed 

Baseline (i.e. preanalysis) 

architecture 

should be published to 

the appropriate 

repository 

Analyses are likely to be 

COI-specific, and may 

include a variety of 

analytical techniques 

Conduct a review of the 

initial analyses if 

necessary to revise the 

analyses before issuing 

the final product(s) 

• Definition of what data is required 

• The level of granularity of data that is 

required 

• Identification of multiple / redundant data 

sources to provide data validation and / or 

back-up sources 

• Data formats, pre-processing and data 

migration issues 

• Assessment of the security aspects of the 

populated architecture 

• In accordance with the MODAF Meta Model 

and MODAF Taxonomy - to ensure 

compatibility and re-use 

• Review of the entire architecture by the 

subject matter experts who have provided key 

inputs 

• Consult the MODAF governance processes to 

ensure that any dependent architectures have 

not changed 

• To provide visibility to others across the MOD 

• Ensure the All Views are completed thoroughly 

for all architectures before they are 

published. 

• Static analyses – such as a gap / overlap 

analysis against the Strategic Views in order to 

identify capability issues 

• Dynamic analyses – such as network traffic / 

bandwidth analysis based upon network 

configurations from SV-1 and traffic data from 

OV-2/OV-3 

• Experimentation – using information 

developed from the architectural analysis to 

establish the use cases / context for 

experimentation campaigns such as those run 

through NITEworks 

• Trials – using architectures to provide use case 

/ context information for exercises and trials 

at a variety of scales from battlelabs to full 

brigade or division level exercises 

Plan for 

populating the 

architecture; 

Tool selection 

How to support 

HV creation 

• Data 

• Methods 

• Tool selection 

• Management 

page 14



APPENDIX C 

NATO HFM-155 HVs 

The NATO research panel HFM-155 produced a ‘NATO HV’ (NATO RTO 2009, 2010) that 

has evolved in close collaboration with the MODAF HV developments. While there are 

minor differences between these concepts, it needs to be recognised that the overall 

content and usefulness is very similar. Minor differences exist as to where the 

boundaries are drawn, and how far some elements are extended. 

For example, the NATO HFM-155 Human View includes an additional dedicated 

“Training” HV (which the MODAF HV concept covers through a combination of the MODAF 

HV-F and HV-A) and a “Human Concept” HV, which can be developed as a special 

pictorial version of a MODAF HV-C. On the other hand, there is no exact equivalent in 

the NATO HV concept to the MODAF HV-D, having considered that the NATO 

Architectural Framework (NAF) OV-4 can take that role. However, the MODAF HV-D 

suggests some additional elements not put forward, thus extending OV-4. Likewise, 

naming conventions have been chosen to be different – where the NATO HV-G is more or 

less identical to the MODAF HV-B. Figure 1 provides an overview of key dependencies 

between NATO HV products, and Figure 2 outlines the differences and similarities 

between the NATO HVs and the MODAF HVs. 

Figure 1: Overview of the Human Views developed under NATO HFM-155. 

In the same way in which DoDAF, MODAF and NAF differ, small misalignments between 

national HV concepts can be expected and are the result of individual perspectives of 

the developers involved, as well as the extent to which a consensus on details was 

found when they were recorded. The NATO HV definitions have drawn on an initial set 

of draft MODAF HVs, as well as other national HV concepts, and the boundaries were 

defined as a consensus between the panel participants during a workshop. All of the 

national concepts have evolved since, including the MODAF HVs. 

page 15



It is essential to note that all of the Views are graphical representations of what is 

captured in an underlying data model. Therefore, individual instantiations of any 

Views may differ. There are trends towards defining ‘Customised’ Views for 

architectural frameworks that combine data in new and different ways, entirely 

depending on the purpose. Therefore, creating View representation requires a certain 

amount of creativity anyway, making small differences in View definitions negligible. 

Thus, a full alignment cannot be expected, especially as details of each concept may 

evolve and continuous full alignment becomes unmanageable. Currently, no further 

alignment activities are planned. A key focus of any alignment task should be on the 

meta-model (in line with current MODAF/DoDAF/NAF policies), rather than on 

individual view descriptions. The MODAF HV meta-model may be considered as one of 

the most developed HV meta-models, including a thorough alignment with existing 

MODAF meta-model definitions. It may be noted that, rather than trying to align 

similar HV concepts, it may be more beneficial to achieve a close link with the relevant 

framework (e.g. MODAF, NAF), as part of which the HVs are to be applied. Only then 

can HVs achieve their full potential. 

Figure 2: Alignment of NATO and MODAF HV concept definitions. 

Other differences lie in the way in which HVs were refined and applied, and what type 

of practical guidance has been provided with them. The NATO HV has provided 

important demonstrations of practical applications through concrete links with dynamic 

modelling, where the focus of the modelling was to a large extent on providing a 

structural representation of an enterprise (often ‘as-is’) that can be assessed to inform 

the need for design changes. The MODAF HVs have put more emphasis on how HVs can 

page 16



support creative design thinking where new tasks, automation levels, roles, 

competencies, jobs, and organisations require defining. 

page 17



APPENDIX D 

The HFI Process 

The standard HFI Process is well described through several documents 1 – including 

overviews and detailed descriptions, and what to do when, supported by which 

methods and tools. Figure 3 maps the key elements of the HFI Process (including both 

technical and management activities) to key activities as part of the HFI requirements 

specification and assurance process. It includes an overlay of the currently defined HFI 

System Readiness Levels (SRLs) and selected MoD Acquisition activities as part of the 

CADMID lifecycle stages. HFI activities are defined under the HFI Process requirements 

in the Human Factors Integration Plan (HFIP). Their implementation is depicted under 

‘Observe Implementation’. 

Figure 3: The HFI Process in relation to requirements specification and assurance. 

1 (1) Def-Stan 00-250: Human Factors for Designers of Systems: Human Factors Integration. 

(2) MoD (2006) MAP-01-010 HFI Management Guide (formerly STGP 10). 

(3) HFI DTC (2009) The People in Systems TLCM Handbook. 

(4) ISO 13407: 1999. Human-centred design processes for interactive systems. 

(5) MoD (2009): HFI Overview on the AOF (Acquisition Operating Framework). 

page 18



APPENDIX E 

HFI Risk Assessment Checklist 

The HFI Cost-Benefit Analysis guidance (Bruseberg 2008a) proposes a high-level project 

risk analysis to determine the scope of HFI activities, and associated budget 

requirements. It assesses the risk potential on a severity scale, based on the likelihood 

and impact of problem occurrence 2 . The checklist in Table 5 captures ratings (the 

columns under ‘severity rating’) to estimate the potential impact of each factor 

(where ‘1’ is very low risk and ‘5’ is very high risk). Impact ratings need to be based 

on experience values and expert judgements. The assessments for each risk factor 

provide a qualitative overview as to where problem areas may lie. They may also provide 

an overall risk level. 

There are 15 factors, so each contributes 6.67% to the overall risk. Since their 

contribution may vary, the risk influence factors in Table 5 have been given a 

predetermined weight (e.g. presence of health hazards: 5%). These may need to be 

adjusted depending on the type of project. They need to add up to 100%. 

Risk influence 

factor 

1 Estimated 

cognitive 

complexity of 

operation 

2 Expected 

physical 

difficulty of 

operation 

3 Mission-critical 

operation 

4 Presence of 

health hazards 

5 Expected 

operation under 

safety critical 

conditions 

6 Direct 

interaction scope 

Table 5: Risk Potential Checklist as the basis for HFI activity cost predictions. 

Explanation 

The level of complexity for the interaction between people and 

technology, and the complexity of the operational environment, 

potentially leading to cognitive workload (e.g. decision-making 

tasks in dynamic environments; operation of complex equipment 

with many variables; time pressure; anxieties). 

The severity and number of adverse operating constraints that 

may reduce operator performance and task achievement due to 

physical stressors and workload factors (e.g. extreme thermal 

discomfort, moving heavy loads, limited visibility). 

The extent to which the operation of the system affects the 

success of the mission, and the criticality of mission or task 

failures. 

Presence of potentially harmful conditions due to the operating 

environment, technology interaction, or task demands (e.g. 

toxic substances, moving parts, prolonged operation under 

physically or psychologically strained conditions). 

Risk of large-scale accidents due to human error (e.g. possibility 

of excessive cognitive workload, lack of situational awareness). 

Extent to which people are directly affected by the equipment 

(e.g. number of users affected; occasional vs. continuous use) – 

not limited to operators, but including, for example, 

maintenance personnel, users directly benefiting from function 

15% 

of product/system, and people transporting and installing 

equipment. 

7 Expected change Likelihood of changes to personnel issues including manpower 5% 

Weight 

5% 

5% 

10% 

5% 

5% 

Severity Rating 

0 - None 

1- Very Low 

2 - Low 

3 – Medium 

4 - High 

5 – Very High 

2 Note that risks are usually estimated based on a combination of both probability and severity of 

effects. The ‘impact’ rating used here is a simplification combining the two dimensions implicitly. 

page 19



Risk influence 

factor 

of manpower and 

skill levels 

8 Extent of HF 

problems in 

predecessor 

systems 

Explanation 

availability and requirements, and skill needs – potentially 

requiring manpower planning, recruitment, and/or training 

activities. 

Extent of HF problems in existing systems, giving an indication 

of the amount of design change required to overcome them and 

assess improvements. 5% 

9 Scope of effects The extent to which the new product/system affects related 

system design areas through the consequences of changes 

required. For example, new technology such as NEC information 

networks may require new organisational and information flow 

structures, re-training, re-recruiting, new maintenance 

schedules, new documentation. The lifetime of the 

product/system may come into the equation here. 

10 HFI design scope 

in relation to 

project focus 

If the purpose of the project is the design of a new user 

interface only (e.g. for an existing helicopter), then the HFI 

effort is proportionally much higher than, for example, the 

design of an entire new helicopter (where, for example, 

ensuring technical airworthiness will take on a much larger 

proportion than HFI activities). 

11 Level of novelty The extent to which the newly designed working system is novel 

(e.g. first-of-a kind) and produces sources of uncertainty (e.g. 

novel technology, new task and operating conditions, new 

organisational constraints). This affects design, implementation, 

and operation. 

12 Number of design 

constraints 

13 Project 

uncertainty 

14 Product purpose 

directly fulfils a 

Human Factors 

need 

15 Absence of 

conducive design 

organisation 

conditions 

The extent to which the design process needs to conform with 

external limitations that require optimisation of operational 

variables (e.g. need to comply with safety regulations, need to 

follow specific design standards). 

Amount of (not yet) available understanding of operational 

needs and system requirements (e.g. agreements on operational 

concepts, understanding of user constraints, definition of tasks 

and expected task performance, clarity of high-level humanequipment 

interface requirements, envisaged use of 

technologies). 

Technology Readiness Levels may be referred to here. 

The purpose of the design is in itself fulfilling a user need, i.e. 

support to humans is the objective of the project (e.g. 

transporting them, housing them, providing them with 

information). 

The ease with which an effective HFI process can be integrated 

depends not only on the acceptance level of HFI, but also on the 

presence of conducive processes such as an iterative design 

process, efficient project management, effective 

communication, documentation, and information sharing 

processes. 

Weight 

5% 

10% 

5% 

5% 

10% 

5% 

5% 

Severity Rating 

0 - None 

1- Very Low 

2 - Low 

3 – Medium 

4 - High 

5 – Very High 

page 20



APPENDIX F 

HFI Cost-Benefit Analysis 

HFI plan options are often closely linked to budget decisions. In order to determine 

the HFI activities at any stage, different options for implementing change need to be 

traded off in relation to the cost of undesired effects and the cost of additional 

activities. The HFI cost-benefit analysis (for justifying budget plans) can be conducted 

as shown in Figure 4. The steps are answering the following questions: 

What are the aims, constraints, and priorities of the analysis, what will be the 

outputs, and for whom 

What can go wrong without HFI, and what are the potential cost effects of the risks 

Which HFI activities are needed to reduce the risks as far as possible, and how 

should HFI get involved 

What are the costs for the required HFI activities 

What if a full and optimal implementation of HFI activities needs to be traded off 

against other cost priorities 

Which is the most suitable HFI implementation option based on a trade-off analysis, 

and how best to present it to decision makers 

Figure 4: HFI Cost-Benefit Analysis process steps (derived from Bruseberg 2008a). 

page 21



APPENDIX G 

HV Overlays on MODAF COI 

Processes 

All flowcharts shown here have been taken from the MODAF Deskbooks (MoD 2005b, c, 

d, e, f) and have been overlaid with applicable HVs in addition to the existing MODAF 

Views on the original pictures. 

Concepts & Doctrine 

Figure 5: Suggested HV use by Concepts & Doctrine in addition to MODAF View use. 

page 22



Sponsor (previously Customer 1) 

Figure 6: Suggested HV use by the Sponsor in addition to MODAF View use. 

page 23



Acquisition 

Figure 7: Suggested HV use for Acquisition (project management). 

page 24



Figure 8: Suggested HV use for Acquisition (requirements). 

page 25



Figure 9: Suggested HV use for Acquisition (systems/technology). 

page 26



HV-C 

HV-D 

HV-A 

HV-G 

HV-B 

HV-E 

HV-C 

HV-F 

HV-D 

HV-G 

HV-B 

HV-A 

Figure 10: Suggested HV use for Acquisition (industry). 

page 27



Figure 11: Suggested HV use for Acquisition (through-life management). 

page 28



The User (previously Customer 2) 

Figure 12: Suggested HV use by the User (advance military planning, part 1). 

Figure 13: Suggested HV use by the User (advance military planning, part 2). 

page 29



HV-D 

HV-B 

HV-E 

HV-D 

HV-G 

HV-G 

HV-C 

HV-G 

Figure 14: Suggested HV use by the User (command military activities). 

Figure 15: Suggested HV use by the User (provide feedback post-operations/exercises). 

page 30



HV-B 

HV-C 

HV-A 

HV-G 

HV-C 

HV-C 

HV-D 

HV-E 

HV-F 

HV-B 

Figure 16: Suggested HV use by the User (maintain military capability). 

Figure 17: Suggested HV use by the User 

(contribute to capability development and integration). 

page 31



Sustainment 

Figure 18: Suggested HV use by Sustainment (manage defence logistics). 

Figure 19: Suggested HV use by Sustainment 

(develop the equipment and support solutions). 

page 32



Figure 20: Suggested HV use by Sustainment 

(material and associated service provisions to end use). 

page 33



APPENDIX H 

Processes used for Individual 

Project Applications 

H.1 Introduction 

The process regarding the scope and order in which HVs are populated can differ 

significantly depending on specific applications in terms of their objectives and focus. 

This section describes a series of example processes from various applications that 

have applied and populated HVs. They include: 

Niteworks: supporting early capability-focused decision-making for acquisition, 

where MODAF supports experimentation activities using synthetic environments. 

Examples were produced in relation to a realistic project (Hitchins 2008). 

Commander’s Update Brief (NATO RTO HFM 155 example): analyse the impact of an 

already implemented technology insertion on human enterprise components, to 

evaluate performance changes retrospectively. Moreover, the HVs can be used to 

provide the foundation for reviewing the organisational processes and structures in 

order to assess human-related redesign needs and design options. Examples 

equivalent to the UK HV-A, B, C, D, E, F, G were produced (NATO RTO 2009, 2010). 

Tele-working example: exploring implementation options for new organisational 

working mechanisms, without specific project context (i.e. theoretical design). The 

use of all HVs was discussed and specific examples were produced for HV-B, C, E, F 

(Bruseberg 2008b). 

Dynamic modelling: HV use as the basis for dynamic modelling activities to assess 

human and enterprise performance parameters (NATO RTO 2010). The primary 

focus was on assessing human network structures, for example in response to UAV 

technology insertion or organisational change, without a specific project context 

(i.e. theoretical design). 

Maintenance Project: HV use within Industry at a stage where equipment design 

decisions had already progressed quite far, and HVs were used to model important 

constraints to assess equipment design options and pinpoint needs for potential 

design changes, as well as to facilitate implementation requirements. Examples of 

HV-B, C, D, E, F, G were produced. 

page 34



H.2 NITEworks 

The Project 

NITEworks is the MoD’s centre for manned warfare experimentation and acquisition 

decision support, in order to support early capability-based planning. The warfighting 

experiments can be planned and documented using MODAF. Likewise, the synthetic 

environments used for experimentation can be specified and built grounded in MODAF. 

The NITEworks approach is to think and design ‘Top down’, from Capability, to System 

of Systems, to Systems, to Components, but to check and validate ‘bottom up’ 

(Hitchins 2008). 

HV examples were produced in relation to a realistic project, supplementing the other 

MODAF elements. First, a baseline architecture was created, followed by a model of 

the experimental architecture. This was the basis for capturing warfighter behaviour 

in response to selected scenarios. 

The Process 

Figure 21 traces the approximate path of progressing the HV development in relation to 

MODAF Views. The blue lines between numbered star symbols show the order of 

progression. Table 6 provides a key to the numbers. 

Table 6: The order of progression between HVs and MODAF Views. 

Description 

1 StV-1 Describe the capability vision to be instantiated, including key targets and timescales 

(Specify Theme Question) 

2 StV-2 Develop Capability Taxonomy: Break down the capability requirements hierarchically 

3 AcV-2 List technology implementation options for intended timescales and map onto specific 

deployment 

(Platform specific view of scenario using equipment from that epoch) 

4 OV-1 

a, b 

Describe the overall scenario including intended types of assets, communication links, roles 

and constraints (Defining System of Systems) 

5 OV-5 Describe the high-level enterprise activities to be achieved, including a breakdown into subactivities 

(Describe overall Process) 

6 HV-F Identify individual (human) roles that will be played by warfighters, having identified the 

organisation relevant to the theme (roles are used, rather than posts, as a more abstract 

functional representation underlying posts and part of existing organisations intended to use 

the envisaged equipment) 

7 OV-4 Capture relationships between roles as the basis for potential organisational structures, and 

by mapping key interaction links between roles 

8 OV-2 Identify Operational Nodes including intended assets (e.g. intercept helicopter), Distinguish 

Manned and Simulated Platforms for experiment 

9 HV-C Use an HV-C (Human Interaction Structure) to map human roles to intended OV-2 nodes (or 

envisaged assets), including interaction needs between roles 

10 HV-F For each role use an HV-F (Roles and Competencies) to identify further attributes of roles 

including rank required, experience required and technology operated, description of task to 

page 35



Description 

be conducted, task demands, competencies needed, rank, experience, ability to operate 

technology etc. 

11 SV-1 Identify the current structure of technologies and assets, as well as the structure to be used 

for the experiment 

12 HV-C Map human tasks as part of roles to envisaged equipment (draw an illustration of the 

equipment that the warfighter will need to perform the role with (VHF radio, Recognised 

picture, 3d sim view, gun controller) with a representation of the computers and software 

systems required to do each task) 

Combine the pictures for each task into an SE network diagram. 

13 SV-10c Observe behaviour in experiment and represent through task and information flow diagrams; 

Capture of observed behaviour 

14 HV-B Specify expected team behaviour and measures to be used in observations: 

Create taxonomy for expected Team Dynamic (Range of emotions) and Command Style 

(Range of styles), including worst case and best case expectations for development through 

mission phases 

15 HV-G Record observed emotions and team states mapped through mission phases 

16 OV-4/ 

HV-D 

Review and further detail intended organisational structures and processes based on 

observations and based on specifications of the types of interactions to be expected 

between people in roles (e.g. collaborate, cooperate, supervise) 

page 36



Note that the lines show the order of the approach taken on the occasion, not a 

generic order. Also, they do not imply technical dependencies where one View is 

always needed to inform the next. Also note that the figure does not include any 

iteration loops. The figure distinguishes only two levels of abstraction for simplicity. 

The higher layer includes StVs and OVs, together with higher-level HV instantiations. 

The lower layer focuses on resource specifications, including HVs. The two layers 

reflect each other in terms of the technical areas. The HVs drawn in plain white 

around the outside are ‘as-is’ views (i.e. a model of what currently exists), showing 

that they may inform the other ‘to-be’ models (i.e. new design options or decisions). 

Figure 21: Sample progression of HVs development showing two different levels of 

enterprise definitions, with the order shown from one blue star to another. 

page 37



H.3 Commander’s Update Brief 


The Commander’s Daily Update Brief is an operational brief that provides updates 

regarding the readiness and operational assets throughout the command, with a focus 

on the previous 24 hours and the next 24 hours. The staff process that produces the 

brief includes analysing data sources, creating Microsoft PowerPoint slides, and 

numerous review cycles. 

Through automation of formerly manual processes a significant amount of staff time 

was saved, while also allowing presentation of more current and less static 

information. The new system automated the data gathering process using Web 

services that pull data directly from authoritative sources. However, the process is 

still largely stove-piped along functional area divisions. The process of preparing all the 

information into a single presentation to meet the admiral’s information requirements 

is very labour-intensive (Handley & Heacox 2005). 

HVs were used to analyse the impact of an already implemented technology insertion 

on human enterprise components, to evaluate performance changes retrospectively, 

and plan for future projects. Moreover, the HVs can be used provide the foundation 

for reviewing the organisational processes and structures in order to assess redesign 

needs and options. 

The HV products were captured to be able to augment the previously captured DoDAF 

OV and SV products. HVs can help evaluate the efficiency of the baseline system in the 

briefing production cycle. These provide a foundation for determining projected time 

and staff savings when integrating new technologies and processes into the briefing 

production cycle. 

The examples were kindly provided by the NATO RTO HFM 155 working group (NATO 

RTO 2010). They were produced as example material to illustrate the use of a set of 

NATO HVs developed through an international collaboration project. The numbering 

system and definition of the NATO HVs is slightly different. They were transferred into 

the UK HV concepts as far as possible. Moreover, they were developed in relation to 

DoDAF. The equivalent MODAF views are cited. 


Figure 22 traces the approximate path of progressing the HV development for the 

Commander’s Daily Update Brief in relation to MODAF Views. The blue lines between 

numbered star symbols show the order of progression. Table 7 provides a key to the 

numbers. Note that it also includes a reference to the original NATO HVs numbers. 

page 38




UK HV Description of Product NATO 

HV 

1 OV-1 Operational Concept Graphic 

2 HV-B, HV- 

G, HV-C 

(highlevel) 

High-level (pictorial) descriptions of the expected human roles, performance 

criteria and operational conditions (note this is captured by the NATO HV-A: 

Concept, which is not specifically included in the UK HVs) 

3 OV-4 Command Relationship Chart (to be able to break down current definitions of 

posts/jobs to roles) 

4 HV-A Personnel-related constraints – to adjust expected human roles and human HV-B 

functions 

5 HV-F Role Definition: Roles that are required with selected attributes, based on HV-D 

current post definitions 

6 HV-A Existing Skill Inventory: Attributes of personnel currently in roles HV-F 

7 OV-5 

OV-6a, b 


Operational State and Rules Models 

8 HV-E Task Decomposition: The operational activities are decomposed into human 

tasks 

9 HV-F Task Responsibility Matrix: The tasks from the activity decomposition are 

mapped to available roles 

10 OV-2 

OV-3 

Operational Node Connectivity Description 

Operational Information Exchange Matrix 

11 HV-C • Role Groupings: Roles are grouped into functional teams 

• Team Interactions: Interactions of the teams across physical locations are 

analysed 

• Information Requirements: Information Exchanges across the teams are 

depicted 

12 SV-4 

SV-5 

Systems Functionality Description 

Operational Activity to System Function Traceability Matrix 

13 HV-E System Interface Matrix: Systems that are utilized to complete tasks are 

mapped to tasks 

14 SV-1 System Interface Description 

15 HV-A • Training Requirements: Training required to provide personnel with essential 

knowledge, skills and experience for tasks 

• Training Resources: Instruction, education, on-the-job or unit training 

available (or in need to be made available) 

HV-A 

HV-C 

HV-D 

HV-E 

HV-C 

HV-F 

HV-F 

16 SV-7 System Performance Parameter Matrix 

17 HV-B Metrics: Human performance metrics defined (in relation to the defined tasks) HV-G 

18 HV-G Products to assess static data using dynamic modelling tools, including: 

• Dynamic Model: e.g. Coloured Petri nets; business process modelling (BPM). 

• Experimental Conditions and Outcomes: The different conditions under which 

the dynamic model will be run and the outcomes to be measured are defined 

• Model States: The different states of execution for the dynamic models 

HV-H 

page 39





H.4 Tele-working example 


The HV application explored implementation options for new organisational working 

mechanisms through tele-working practices (i.e. introduce opportunity to work from 

home remotely for large proportion of employees for a company). The example was 

populated for demonstration purposes only, without a specific project context (i.e. it 

is an theoretical design for a potential project). Specific examples were produced for 

HV-B, C, E, F. 

page 40



Tele-working practices can reduce the time and effort needed for travelling to offices, 

contributing to reductions in the use of fossil fuels, and to reductions in greenhouse 

gases. In addition, costs for having to provide office-based facilities can be reduced. 

Tele-working implements a distributed working practice that needs to be supported 

through suitable technologies enabling remote communication and information sharing 

for collaboration and cooperation activities. Although such technologies are becoming 

more widely available, their organisational and procedural implementation into 

working practices requires changes that often create barriers and need to be managed 

well. Human-related concerns play an important role in enabling such enterprise 

transformations. 

The example takes on two perspectives: 

It draws out the potential breadth of scope when looking into large-scale 

implementations of tele-working practices. Architectural models can be identified 

as essential tools to cope with the ‘bigger picture’ for initiating a coordinated 

planning of change, supporting early trade-off and cost analyses. 

It discusses how the HVs can be applied to model human-related architectural 

components of tele-working concepts at the smaller scale of the perspective of one 

business aiming to undergo such a transformation. The example application serves 

to explain the utility of each HV. 






Description 

1 SV-9 Use Technology & Skills Forecast to capture major constraints and/or enablers for future 

work and transport patterns that can be expected over certain time scales. 

2 StV-1 Describe wider-reaching tele-working objectives under the ‘Enterprise Vision’ (StV-1). 

3 StV-6 

OV-5 

Describe specific project objectives through a matrix linking capabilities to be achieved to 

operational requirements to be implemented. Identify the types of activities that may be 

suitable for tele-working practices. 

4 HV-E Detail specific tasks that would need to be conducted under the new practices. 

5 HV-F Identify roles and competencies associated with these tasks and assess the impact of teleworking 

(potential new work practices or new technology use due to the increased 

remoteness). 

Identify human-human interaction requirements between task elements where roles need to 

communicate or coordinate without physical co-location. 

6 HV-A Assess implications on personnel requirements including long-term planning of 

available/willing personnel, training courses, and different contract options. 

7 HV-B Break down success criteria and measures to assess continued worker effectiveness and 

efficiency (e.g. project quality, effectiveness of collaboration, worker motivation, efficient 

use of resources, health & safety). 

8 HV-G Capture time-based constraints, such as the need to coordinate project work phases; 

coordination of flexible work rhythms; balance needs for on-site and off-site presence). 

Map situational variations (e.g. work options change based on three main location types: 

home; on the move (e.g. hotel, train); in the office (e.g. using a hot-desk). 

9 HV-C ‘As is’ situation: analysis of a current networking situation and equipment use for an existing 

tele-worker. 

page 41



Description 

10 HV-C Abstract ‘to-be’ – including: 

*assessment of changed need for office facilities (e.g. central offices function primarily as 

meeting places and for provision of access to specific facilities and services). 

*changes in human interaction types that networking technologies need to support. 

11 HV-C Concrete ‘to-be’: 

Specify new technology use options and interaction patterns. 

12 HV-D Capture organisational implications of more flexible working patterns, e.g.: 

Where regular physical proximity as the basis for team building is removed, other structures 

may naturally build around other links (e.g. conferences). 

Formal job definitions need to allow for the additional responsibilities/roles and skill 

requirements of tele-working practice. 



page 42



H.5 UAV Scenario 

The Project: UAV example for dynamic modelling 

HV elements were produced implicitly as the basis for dynamic modelling activities to 

assess human and enterprise performance parameters. Specifically, the impact of 

using UAV technology as part of designing human interaction networks was assessed for 

impact on human performance. The project was a theoretical application for 

establishing proof of principles. Examples equivalent to HV-C, D, E were produced. 

In this model, the activity of the Agents is run as a series of event-based modules. For 

example, the UAV follows a search path around the terrain (the search path can be 

defined by the analyst as a series of waypoints), and when it flies over a target it 

reports a sighting to Agents in the information chain. Each target is specified by the 

analyst, in terms of its location and a set of five parameters (the parameters are 

abstract quantities that are responded to by different Agents in the information chain). 






(the colour code separates different types of assessments). 

UK HV Description 

1 HV-B Define performance parameters and assessment objectives 

2 OV-5 The tasks required to perform a mission 

HV-E 

3 HV-F Define roles (to be taken by people) to perform tasks 

Tasks allocated to roles 

4 HV-D 

HV-A 

List defined job types with certain (standardised) characteristics (e.g. skill, rank), 

depending on currently envisaged personnel 

5 HV-F Existing job types mapped to envisaged roles/tasks 

Personnel characteristics (for person in intended roles) 

Assess: the right skills/characteristics for the right demands 

6 HV-C Team configurations (e.g. size; organisation; information flow) 

Network configuration and associated properties (network properties can be affected by 

human processing and exchange variables) 

• Communication/interaction structure variables 

• Network parameters (e.g. size, coupling: amount of information/knowledge sharing and 

distribution, centralisation) 

• Organisational conditions (e.g. communication between units can vary according to task 

needs: e.g. information chain; exchange patterns; dependencies) 

• Command structure: hierarchical vs. distributed control/authority/information flow 

• Redundancy options 

7 SV-1 Technology use options 

Available channels of communication (e.g. communication technology) 

8 HV-E Resulting tasks and task flow (e.g. sequence diagram; critical path analysis) 

SV-10c 

9 HV-G Conditions, time constraints (e.g. varying time demands, mission phases), task 

dependencies (e.g. rules, information available, finish one before starting next) 

page 43



UK HV Description 

Operating conditions 

Operational phases; settings (e.g. environmental constraints); conditional variations 

Assess: compare resulting tasks for human performance 

(e.g. task time, probability of completion/success rates, overall mission time, reaction 

times, probabilistic error rates, workload) 

10 HV-C Locations, and associated physical variables (e.g. environmental stressors – e.g. thermal 

stress) 

Assess: performance or health degradation 

11 HV-A Actual personnel (actors) with skills/characteristics assigned to roles 

Numbers of people specified 

12 HV-C Location constraints requiring movement of people or material 

13 SV-10 

a, b c 

(++) 

Model of system behaviour (e.g. UAV is managed by both the flight path and the location of 

target) 

Probabilistic transfer models for system state transitions 

Assess: represent the movement of agents relative to the terrain and each other (e.g. 

Petri-net for Petri-net simulation; stocks and flows) - 

‘animate’ physical progression 

14 HV-G Conditional variations (e.g. events causing loss of nodes; variable efficiency of individual 

nodes; loss of communication links) 

Event timeline (e.g. phasing, conditions, disturbances) 

Assess: performance of network exchanges (affected by human constraints) 

E.g. network information exchange performance (speed in passing information, hold-ups, 

quality of information after multiple passing); predict bottlenecks, e.g. routing problem 

15 SV-10 

a,b,c 

Human agent activities (task, sequence, behaviour rules) 

Assess: behaviour of human nodes: 

Human performance (individual; team) for entire task or task sections (compare for team 

configurations; technology use, conditions) – e.g. information overload, task time, error 

rates, delays, decision quality/accuracy 

16 HV-D Define organisation based on preferred network, roles and task sequences 

page 44





H.6 Maintenance Project 

(Covered in the Example Section) 

page 45



ACKNOWLEDGEMENTS 

This work is part-funded by the Human Capability Domain of the UK Ministry of Defence 

Scientific Research Programme, and was initiated by the MOD Research Programme Leader 

Human Capability. 

Many thanks to the HFI DTC consortium for the support received, including collaboration 

opportunities, encouragement, inspiration, feedback, discussions, and example material. 

Special thanks to the experts who have been instrumental in establishing the first MODAF 

HV concepts, by sharing their work, providing ideas, and detailed discussions: 

Holly Handley, Pacific Science & Engineering Group, Inc., US 

(Many thanks, Holly, for your kind provision of examples) 

Kevin Baker, CAE Professional Services, for DRDC Canada 

Gavan Lintern, Cognitive Systems Design, US 

Ian Bailey, Model Futures. 

Particular thanks to people who have particularly supported the HV work, by facilitating 

and providing applications, promoting the concept, and assisting in wider implementation 

options: 

Steve Hitchins, Chief Battlespace Architect, Niteworks 

Matthew Hause, Chief Consulting Engineer, Atego 

co-chair of the UPDM group 

Ian Ross, BAE Systems Insyte. 

Concrete applications of HVs, or of concepts similar to HVs, to realistic projects have been 

an invaluable source of information, including practical experiences, examples, critical 

feedback and help in confirming the value of the HV concepts. Many thanks to: 

Robert Sayers, Systems and Integration Team, Dstl Fort Halstead 

Gary Davis and Keith Washington, Security Sciences Department, Dstl, Fort Halstead, 

Paul Hicks, BAE Systems Insyte 

Wayne Wright, Technology & Engineering Services, Systems Engineering Innovation 

Centre (SEIC), BAE Systems plc. 

Steve Hitchins, Chief Battlespace Architect, Niteworks 

Glen Hewitt, Human Factors Research and Engineering, Air Traffic Organization- 

Operations Planning, FAA 

Kevin Bessell, BAE Systems AeI 

Robert Marshall, Systems Engineering & Assessment Ltd 

Francesco Ciambra, Danelia Frisoni, Andrea Tocci, Manuela Nardini, SELEX-Sistemi 

Integrati S.p.A., B.U. Defence Systems, Italy. 

Many discussions were held with a variety of stakeholders and researchers, that helped 

develop the concepts further. Thank you all for your time and feedback. 

Patrick Gorman, Assistant Head Architecture Framework, CIO-ISP-Enterprise 

Architecture 

Col Luigi Gregori, Head of Enterprise Architectures (CIO-ISP-EntArch) 

John Keefe, CIO-ISP, Enterprise Architectures 

Dai Morris, Head of Capability, Joint Training, Evaluation and Simulation 

Simon Baker, Command Control and Information Infrastructure 

Alan Shoolbread, DEP 

David Garvey, Boeing Defence UK Limited 

page 46



Robert Suzic, Combitech AB, 

Anna Swartling, HCI Group, School of Computer Science and Communications, Stockholm 

Morten Grandt, FGAN – FKIE 

David Parkinson, Head of Capability, Military Air Solutions, BAE Systems (Operations) 

Limited 

The discussion and the workshop held on developing the NATO Human View was an 

invaluable source of information in developing HVs. Many thanks to the NATO Research 

Panel participants (NATO RTG HFM 155). 

The work also received continued support and feedback through the HFI MoD Industry 

Working Group. Thank you all for attending several presentations, and providing 

suggestions. 

Many thanks to the experts who have provided feedback on the Draft HV Handbook, for 

offering invaluable advice: 

John Winters, CHFP, Basic Commerce and Industries, Inc., US 

Anthony Dekker & Chris Janczura, DSTO, Australia 

Peter Bryant, Integration Authority 

Steve Hitchins, Niteworks 

Mark Fenton & Robin Hodges, MBDA 

Colin Brain, SE Validation Ltd. 

Robert Cummings, ATKINS Defence 

Carys Siemieniuch, Grace Kennedy, & Dr Murray Sinclair – Loughborough University/SEIC 

Richard Parsons & Irina Neaga, Loughborough University, NECTISE 

Maj Jo Barnsley, Command Support Development Centre 

Dick Whittington, The Salamander Organization 

Dave Roberts, Emerging Technology Services, IBM 

Mark Linsell, Lockheed Martin 

Dermot Rooney, Wirksworth Defence Consulting Ltd 

Many thanks also to the people who facilitated collaboration efforts and gave useful 

technical advice: 

Colin Corbridge, Dstl 

Adrian Pearson, Integration Authority 

H. Rowbotham, DE&S 

Ian Harryman, Human Factors Integration Policy, DE&S 

Dr Geoff Barrett, Dstl Senior Science Adviser (Human Capability) 

Karen Lane, BAE Systems AeI 

Peter R Wilkinson, Technologist Advisor HFI, Human Factors Shared Service, BAE 

SYSTEMS (Military Air Solutions) 

Louise Rolland, Cap JTES Human Capability 

Jennifer McGovern Narkevicius, Jenius LLC 

Vincenzo Arrichiello, Selex-SI Academy, Head, Intangible Capital Management Dept., 

SELEX Sistemi Integrati SpA 

Christina Aldrin, Swedish Defence Materiel Administration 

Walter Dyck, Defence Research & Development Canada 

Richard Drawbaugh, Principal, Air Force Human Systems Integration (HSI) Office, 

AIRPRINT 

page 47



REFERENCES 

Bruseberg (2008a) The HFI Case Concept: Guidance on Specifying, Tracking and Documenting Human Factors 

Integration Requirements, Acceptance Criteria and Evidence. produced by the HFI DTC for the UK MoD, 

HFI DTC/WP 2.8.1/1, http://www.hfidtc.com/pdf/reports/New%20Reports/HFIDTC-2-2.8.1-1.pdf. 

Bruseberg A (2008b) Applying the Human Views for MODAF to the conception of energy-saving work solutions. 

In Proceedings of INCOSE 2008 (18th Annual International Symposium of the International Council on 

Systems Engineering), Utrecht, The Netherlands, 15-19 June 2008. 

Bruseberg A (2008c) HFI Support for MODAF: The Development of Human Views. Unpublished HFI DTC report 

to UK MoD, report reference HFIDTC/2/WP2.8.4/1. 

Bruseberg A (2008d) Human Views for MODAF as a Bridge between Human Factors Integration and Systems 

Engineering. Cognitive Engineering and Decision Making Journal. Special Section on: Integrating Cognitive 

Engineering in the Systems Engineering Process: Opportunities, Challenges and Emerging Approaches. 

HFES, 2(3), pp 220-248. 

Bruseberg (2009) Cost-Benefit Analysis for Human Factors Integration: A Practical Guide, produced by the HFI 

DTC for the UK MoD, HFI DTC/WP 2.7.2/3, http://www.hfidtc.com/pdf/cost-benefit.pdf. 

Bruseberg A & Lintern G (2007) “Human Factors Integration for MODAF: Needs and Solution Approaches”. In 

Proceedings of INCOSE 2007 (17th Annual International Symposium of the International Council on 

Systems Engineering), San Diego, CA, USA, 24 - 28 June 2007. 

Def-Stan 00-250: Human Factors for Designers of Systems: Human Factors Integration. Issue 1 (May 2008). 

www.dstan.mod.uk 

Dickerson CE, Soules SM, Sabins MR, & Charles PH (2004) Using Architectures for Research, Development, 

and Acquisition. Washington DC: Office of the Assistant Secretary of the Navy (Research Development and 

Acquisition), Report number A169724, 7 Oct 2004. 

DoD (2004a) DoD Architecture Framework Version 1.0: Volume I: Definitions and Guidelines. Department of 

Defense Architecture Framework Working Group, 9 February 2004. 

DoD (2004b) DoD Architecture Framework Version 1.0: Volume II: Product Descriptions. Department of 

Defense Architecture Framework Working Group, 9 February 2004. 

DoD (2004c) DoD Architecture Framework Version 1.0: Deskbook. Department of Defense Architecture 

Framework Working Group, 9 February 2004. 

Handley HAH & Heacox NJ (2005). Department of Defense Architectural Framework Products for the 

Commander’s Daily Update Brief Process, Baseline Version. Technical Report. Pacific Science & 

Engineering Group, San Diego, CA. 

HFI DTC (2008) The Human View Handbook for MODAF. First Issue. Produced by the HFI DTC for the UK MoD. 

Available on-line via http://www.hfidtc.com/MoDAF/HV%20Handbook%20First%20Issue.pdf. 

HFI DTC (2009) The People in Systems TLCM Handbook: A guide to the consideration of People Factors within 

Through Life Capability Management. Edition 1, http://www.hfidtc.com/pdf/TLCM-handbook.pdf. 

Hitchins S (2007) Personal Communication June/July 2007. 

Hitchins S (2008) De-risking future MOD capability using MODAF to support Warfighter Experimentation. 

Presentation given at the Integrated EA ’08, 7 February 2008, by Steve Hitchins, Chief Battlespace Architect 

NITEworks. 

Linsell M & Vance C (2008) Modelling Human Factors using The Systems Modelling Language (WP 2.8.9). 

Unpublished HFI DTC report to UK MoD. 

Lintern G & Bruseberg A (2007). Human Functional Analysis of Lean Staffing: Extensions to the Department of 

Defense Architecture Framework (DoDAF). In Proceedings of INCOSE 2007, San Diego, CA USA, 24 - 28 

page 48



June 2007. 

ISO 13407: 1999. Human-centred design processes for interactive systems. 

MoD (2005a) MoD Architectural Framework: Technical Handbook, Version 1.0, MODAF Partners, 31 August 

2005, MODAF-M7-022. 

MoD (2005b) MoD Architectural Framework: Concepts & Doctrine Community of Interest Deskbook, Version 1.0, 

MODAF Partners, 31 August 2005, MODAF- M10-013a. 

MoD (2005c) MoD Architectural Framework: Customer 1 Community of Interest Deskbook, Version 1.0, MODAF 

Partners, 31 August 2005, MODAF-M10-001. 

MoD (2005d) MoD Architectural Framework: Integrated Project Team (IPT) Community of Interest Deskbook, 

Version 1.0, MODAF Partners, 31 August 2005, MODAF-M10-004. 

MoD (2005e) MoD Architectural Framework: Customer 2 Community of Interest Deskbook, Version 1.0, MODAF 

Partners, 31 August 2005, MODAF- M10-005. 

MoD (2005f) MoD Architectural Framework: Sustainment Community of Interest Deskbook, Version 1.0, MODAF 

Partners, 31 August 2005, MODAF-M10-014. 

MoD (2006a) MAP-01-010 HFI Management Guide (formerly STGP 10), Issue 4, Nov 2006, Sea Systems 

Group, MoD. http://www.hfidtc.com/pdf/MAP-01-010.pdf. 

MoD (2007) The MoD Architecture Framework Version 1.1. was published at www.modaf.org.uk, replaced by 

version 1.2. 

MoD (2008a) The MoD Architecture Framework Version 1.2. http://www.mod.uk/modaf. 

MoD (2008b) The MODAF Meta Model (M3): http://www.modaf.org.uk/m3/. 

MoD (2008c) Implementing Systems Engineering in Defence. Issue 2, 19th March 2008, Director General 

Safety & Engineering, 

http://www.aof.mod.uk/aofcontent/tactical/engineering/downloads/se_implementingindefence.pdf. 

MoD (2009) Policy, information and guidance on the Human Factors Integration aspects of UK MOD Defence 

Acquisition, version 1.0.1 - March 2009. http://www.aof.mod.uk/aofcontent/tactical/hfi/content/hfi_intro.htm. 

NATO RTO (2009) The NATO Human View Handbook. The NATO RTO HFM-155 Human View Workshop. 

Draft Unclassified NATO publication. 

NATO RTO (2010) Human Systems Integration for Network Centric Warfare. RTO Technical Report RTO-HFM- 

RTG-155. Reference RTO-TR-HFM-155 AC/323(HFM-155)TP/287. 

http://www.rta.nato.int/pubs/rdp.aspRDP=RTO-TR-HFM-155 

page 49



ACRONYMS 

AcV 

AOF 

AV 

BPM 

CADMID 

COEIA 

COI 

CONEMP 

CONOPS 

DE&S 

DLOD 

DoD 

DoDAF 

DOTLPF 

Dstl 

EHFA 

FAA 

FoS 

GUI 

HCI 

HF 

HFI 

HFI DTC 

HFIP 

HFM 

HMI 

HSI 

HV 

ILS 

Acquisition View 

Acquisition Operation Framework 

All View 

Business Process Modelling 

Concept, Assessment, Development, Manufacture, In-Service, Disposal 

Combined Operational Effectiveness Investment Appraisal 

Community of Interest 

Concept of Employment 

Concept of Operations 

Defence Equipment and Support 

Defence Lines of Development 

Department of Defense 

Department of Defense Architectural Framework 

Doctrine, Organization, Training, Leadership & Education, Personnel, Facilities 

Defence Science and Technology Laboratory 

Early Human Factors Analysis 

Federal Aviation Administration 

Family of Systems 

Graphical User Interface 

Human-Computer Interface 

Human Factors 

Human Factors Integration 

Human Factors Integration Defence Technology Centre 

Human Factors Integration Plan 

Human Factors and Medicine Panel 

Human-Machine Interface 

Human Systems Integration 

Human View 

Integrated Logistics Support 

page 50



ISO 

IT 

LISI 

M 3 

MoD 

MODAF 

NAF 

NATO 

NEC 

OV 

PT 

RTG 

RTO 

SE 

SME 

SoS 

SoW 

SRD 

SRL 

StV 

SV 

SysML 

TAD 

TLCM 

TNA 

TV 

UAV 

UJTL 

UML 

URD 

V&V 

International Organization for Standardization 

Information Technology 

Levels of Information Systems Interoperability 

MODAF Meta Model 

Ministry of Defence 

Ministry of Defence Architectural Framework 

NATO Architectural Framework 

North Atlantic Treaty Organization 

Network Enabled Capability 

Operational View 

Project Team 

Research Technical Group 

Research Technology Organization 

Systems Engineering 

Subject Matter Expert 

System of Systems 

Statement of Work 

System Requirements Document 

System Readiness Level 

Strategic View 

System View 

System Modelling Language 

Target Audience Description 

Through-Life Capability Management 

Training Needs Analyis 

(Technical) Standards View 

Unmanned Air Vehicle 

Universal Joint Task List 

Unified Modelling Language 

User Requirements Document 

Verification and Validation 

page 51


Version 2/ 11 August 2011 

- End of Document - 

page 52


Version 2/ 11 August 2011

The Human View Handbook for MODAF: Part V â Appendices

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?

The Human View Handbook for MODAF: Part V â Appendices