1. Human Views for MODAF Dr Anne Bruseberg Systems Engineering & Assessment Ltd, UK on behalf of the Human Factors Integration Defence Technology Centre (HFI DTC)
The need for Systems Engineering (SE) is increasingly recognised as essential in ensuring a systematic approach to new systems development. SE provides an overview perspective where the integration of many disciplines is needed for complex projects. It is also increasingly recognised that Human Factors Integration (HFI) needs to be understood and practiced as an integral part of Systems Engineering (SE). This is not always common practice, however. Human Factors (HF) practitioners and SE practitioners often find that there are communication difficulties due to differing philosophies and languages.
SE practice uses Architectural Frameworks (AF) to integrate different disciplines based on common models of current and future systems. In the UK, the use of the Ministry of Defence Architectural Framework (MODAF) is now encouraged by the MoD for the support of Acquisition processes, and partially mandated. MODAF has been adapted from the US original, the DoDAF (Department of Defense Architectural Framework). Although MODAF has departed in some details from DoDAF, it still has significant commonalities.
MODAF has been recognised widely as an essential tool to support capability-based acquisition, which enforces the requirement for moving away from technology-focused development. There has been growing concern as to whether both DoDAF and MODAF adequately consider HFI issues for military acquisition.
6 February 2008 Integrated EA Conference 2008

2. The need for Human Views
Ensure Human Factors Integration (HFI)
SE needs HFI
Enable socio-technical systems design
Need to specify people-related design decision areas
Explicitly; Correctly; Early
MODAF (version 1.0) has shortfalls in that
HFI needs SE
Coping with design of complex systems
Opportunity for early involvement

3. What is HFI?

4. Organisational & Social
HFI domains
Human Factors
Engineering
System Safety
Manpower
Training
Personnel
Health Hazards
HFI
Organisational & Social

5. HFI Functions HFI creates value through:
Raising potential issues and preventing risks
Establishing validated insight
Providing methods, processes, data, standards, expertise
Enabling user involvement
Undertaking a design mediation and communication role

6. HFI Value Chain

7. HFI Value Chain

8. HFI Value Chain

9. What are Human Views (HVs)?
Capturing specific human-related components of Enterprise models to enable effective HFI
Ensures common modelling approach
Helps HFI to relate to SE concepts/methods
HFI design decision areas that can generally be perceived as formal definitions.
Not:
the ‘soft’ issues that may be observed
Informal dependencies and behaviours (they are constraints and results)
Functional definitions
extending traditional meaning of ‘functional’ to HFI design areas
“Human Factors Integration (HFI) is a systematic process for identifying, tracking, and resolving human related issues ensuring a balanced development of both technologies and human aspects of capability” ( HFI is an integral part of Systems Engineering (SE). It cannot be conducted in isolation.
HVs ensure that MODAF captures all fundamental elements needed to manage the design of socio-technical systems at a structural level. HVs model human design requirements by capturing the relationships between HFI design elements at different level of abstraction. HVs help to formulate and track the reasoning behind acquisition decisions.
An essential objective in defining the HVs has been to separate the ‘soft’ issues that may be observed in enterprises from those that can be clearly defined and objectively affected through decisions that change future operations. Thus, the design decision areas can generally be perceived as formal definitions. Informal dependencies and behaviours have an effect of such formal definitions. They may establish patterns, sometimes over long periods, which can constrain design decisions in the future.
The HVs for MODAF:
Map HFI design decision areas;
Define values that help assessing the effects of the decisions;
Capture dynamic factors that link structural definitions to behaviours.
Whilst before, HFI concerns have largely been understood as constraints on technology design, HVs now establish that changes in technology may also be conceived as constraints on HFI design – thus widening the definition of what is perceived as ‘functional’ to include the ‘human infrastructure’. Whether or not this wider philosophy will be accepted, the HVs also have a role in better clarifying HFI constraints on technology – primarily those that have a profound impact on how equipment is defined.

10. The HFI question
“Can this person/these people, in this job, with this training, perform these tasks, using this equipment, to these standards, under these conditions”?
SE and HFI have many differences in how they approach design problems – in terms of underlying philosophy, terminology, and scope. The main question asked by HFI practitioners is often this: “Can this person/these people, in this job, with this training, perform these tasks, using this equipment, to these standards, under these conditions”?
The question SE architects may ask is: “Can these capability requirements be achieved through these operational activities/nodes/information networks, fulfilled with these technology functions and structure, over these timescales, given these connectivity standards, technology trends, and organisational structure?”
SE promotes a top-down approach, moving from high-level system requirements to solutions, whilst HFI takes a bottom-up approach where people are in the centre of the attention. HFI often takes the role of informing design, whilst SE often takes the role of managing design.

11. The HV question?
“Can these operational and capability requirements be achieved -
grounded in these HFI objectives and standards,
through these technological and organisational structures,
with these human resources,
fulfilling these functions,
interacting as part of these organisational/task/process dependencies,
in these roles/jobs,
requiring these skills and characteristics,
in these locations,
using this equipment,
over these timescales?“
HVs provide a link between architectural models and HFI concerns. The HFI questions have to be asked at the scope of architectural frameworks, but need to include the HFI design decision elements. Thus, the HV-specific question combining both SE and HFI concerns may be: “Can these operational and capability requirements be achieved, grounded in these HFI objectives and standards, through these technological and organisational structures, with these human resources, fulfilling these functions, interacting as part of these organisational/task/process dependencies, in these roles/jobs, requiring these skills and characteristics, in these locations, using this equipment, over these timescales?“

12. Both MODAF and DoDAF have undergone several developments.
MODAF developments

13. MODAF v. 1.1 (6 Viewpoints, 38 Views)
MODAF version 1.1 made significant changes in definitions underlying the Views to better incorporate all DLOD and support the creation of enterprise architecture including the human element.
All System Views were changed from the single focus on systems as technology only, to take on a wider meaning. The SVs now model ‘resources’ instead of systems only, thus widening the models to be able to include human resources. SV-1 now models human ‘roles’ alongside ‘systems’. ‘Resource interaction’ in SV-1 explicitly includes human-system and human-human interaction, besides system-system interaction. Functions have been defined wider so that they can include human functions. Many of the new examples in the documentation clearly state that system concerns need to be modelled alongside human concerns. This also has implications on how all other SVs are used.
Likewise, for OV-4, TV-1, AcV-2, StV-3 and StV-5 the definitions have been widened, and the visualisations have been updated, to better account for human-related aspects. The OVs have been kept at the ‘logical’ level (i.e. abstract), to reflect requirements rather than solutions or individual resources. They purposefully do not capture statements about specific human resources or solutions. The Meta-Model has been updated and streamlined to be simpler and more accurate. The MODAF documentation is now easier to read, and has several chapters that explain the use of MODAF, for example how it supports the DLOD, and how to use if for trade-off analyses. The descriptions of the HVs have been updated to reflect the changes in MODAF and to relate the HVs to the new concepts.

14. Architecture characteristics
Separation of component concerns
Generic: Conceptual Data Model / Meta Model
Instantiation: Logical and Physical Data Model
View: window/snapshot onto model
Architectural products
Viewpoints
Levels of abstraction
Complexity
Requirements-solutions
MODAF, like other architectural frameworks, uses the following modelling structure:
The complex concerns of the enterprise are broken down and separated into component notions.
These notions, and their dependencies, are described at the highest level in the MODAF Meta Model. “The MODAF Meta Model (M3) is the information model for MODAF, defining the structure of the underlying architectural information that is presented in the Views.” ( DoDAF version 1.5 calls this the Conceptual Data Model. They define (abstract) notions that can be understood as design artefacts (e.g. Capability, Node).
Whilst the Meta-model is a generic model of any Enterprise, each of the components needs to be instantiated with specific models for a particular Enterprise. This may include ‘as-is’ and ‘to-be’ models. The underlying architectural data are stored in computer-based tools or repositories. It is important that data repositories and modelling tools are using common modelling standards, so they can be shared collaboratively, or reused. DoDAF describes this through Logical and Physical Data Model levels.
Views are used to query the Data Model and provide visual representations of architecture components and their dependencies. Views are specific perspectives on the Enterprise structure, or “windows onto an underlying model”, and “snapshots of underlying architectural data”. Thus, “the same information may be represented in more than one View” (
Views are grouped into Viewpoints. Each View can be instantiated by ‘products’, which are particular versions of the actual representations developed for each View. The representations usually evolve, as more detail becomes available, throughout acquisition programmes.
Models are developed at several layers of abstraction to capture requirements-solution relationships in a top-down approach. The higher levels of abstraction are developed early in the system (enterprise) lifecycle, but remain as the guiding principles throughout.

15. MODAF SV-1 (v 1.1)
MODAF now allows and encourages modelling of human roles in the SV-1. Likewise, it models Resource Interactions that can include HCI and human-human interaction.

16. Organisational Resource
MODAF Meta-Model: New
Capability Deployment
Capability
Configuration
Physical
Asset
Organisational Resource
configured with
Standard
subject to
doctrine
hosted on
System
owns
deployed to
Node
realised by
Operational Activity
Function
has
supports
Role
is assigned
operates
conducts
The concept of Capability Configuration was defined as part of the MODAF Meta-Model to provide a generic concept for resource implementation that includes humans structures.

17. New MODAF v1.1 M3 definitions
ResourceInteraction (SV-1)
An assertion that two <<FunctionalResource>>s interact.
Examples: data exchange between systems, conversations between people, people using systems
Function (SV-4)
An activity which is specified in context of the resource (human or machine) that performs it.
Note1: Contrast with <<OperationalActivity>>, where the actor performing the activity is not known (i.e. it is just a logical node). A <<Function>> is implementation-specific.
Role (SV-1, OV-4)
An aspect of a person or organization that enables them to fulfil a particular function.
PostType (OV-4)
A type of point of contact or responsible person. Note that this is the type of post - e.g. Desk Officer, Commander Land Component, etc.
Several modified Meta-model definitions now clearly include human concepts, and clarify their position as part of the Enterprise model.

18. SOA focus in DoDAF v 1.5
Operational Activity to Services Traceability Matrix (SV-5c)
DoDAF version 1.5 has widened its concepts to include Service Oriented Architectures (SOA) – where the focus can be either on Systems (i.e. technology), or Services. Services can include people structures and processes. In a newly created SV-5c, Operational Activities (as requirements) can be mapped to Services for implementing solutions (not just systems). This implicitly includes people aspects, without actually specifying any details for them. DoDAF has also newly defined the concept of the ‘unexpected user’ – thus widening the definitions of potential stakeholders. DoDAF has not explicitly included human definitions in the way MODAF has done.

19. MODAF Human Views

20. UK work: progress / plan
Scoping Study
HV concepts to IA
Draft HV Handbook
Input towards MODAF v1.1
Stakeholder Review
Revised HV Handbook
Published HV Handbook (Issue 1)
Applications and Updates
end Dec 06
8 Feb 07
12 March 07
30 March 07
end July 07
mid Sept 07
Jan 08
ongoing
A set of Human Views (HVs) for MODAF has been developed as part of work conducted under the Human Factors Integration Defence Technology Centre (HFI DTC), a consortium between Industry and Academia funded by the UK MoD. The HVs are proposed as complementary to the existing MODAF Views. HVs clarify the HFI design elements of socio-technical systems.
Analysis and original conception of the HVs is based on studying MODAF version 1.0 through the Technical Handbook and the Deskbooks. The HV concepts evolved in parallel to the upgrade of MODAF to version 1.1 by the UK Integration Authority (IA). This work was able to make some important contributions. An initial set of HV concepts were captured in a Draft Human View Handbook, to collect stakeholder feedback. A revised set of concepts has been produced, and will shortly be published as the First Issue of the HV Handbook. It will undergo further iterations.

21. HVs between OV and SV level
This Figure shows the HVs in relation to a subset of the existing MODAF Views, and in relation to the abstraction layers of MODAF. The most abstract definitions are made as part of the Strategic Views (StVs) at the top of an imaginary cone, whilst the System Views (SVs) produce the most concrete models at the base of the cone. The gray lines trace topical areas that can be found in MODAF and need to be extended to human concepts. They include resource availability (captured through HV-A), relationships & boundaries (HV-C, HV-D, HV-F), functions & activities (HV-E), behaviour & dynamics (HV-G), and values & metrics (HV-B).

22. This Figure shows the relationships between the data elements underlying the HVs – as an HV meta-model. This is a high-level overview version showing how major elements relate and as part of which HV.

23. HV-A: Personnel Availability (example)
Long-term availability of suitable personnel for recruiting is an important factor for which types of roles, posts, and organisational structures can be defined, and for which types of technologies. This can be captured quantitatively comparing demand and supply. It is also essential to capture qualitative cause-effect relationships. For example, HV-A needs to capture causes and effects of personnel fluctuations, to determine the needs for establishing personnel processes. For this example case, a relationship has been mapped between the current practice to minimise training cost, and the potential lack of trained personnel available to work in this post. This may not be a problem, if other factors, such as potentially high injury rates due to health and safety problems, were not present as well.

24. HV-A: Personnel Availability
HV-A captures:
Trend and Development Forecasts;
Personnel Characteristics (e.g. current/future; available/required);
Personnel Numbers (e.g. current/future; available/required);
Formal Personnel Development Structure and Processes.

25. HV-B: Quality Objectives and Metrics (example)
High-level value definitions need to be related to concrete quantified targets. The value categories are specified at different levels of abstraction. This is taking some inspiration from the Abstraction Hierarchy as part of Work Domain Analysis (WDA). WDA specifies Value Priorities only at the second highest level of abstraction, as the basis for functional definitions at the lower levels. The same high-level values can however be broken down also into non-functional values in the same way.
Generic value objectives (e.g. Safety), as capability attributes, can be specified further through quality objectives (sometimes referred to as the ‘ilities’). Most human factors measures need to be linked to expected observable behaviour or performance, based on human tasks/functions to be achieved. Then, measurable metrics can be specified to support these. Explicit targets can be specified for each metric through a one-to-one mapping. Otherwise, relationships can be many-to-many (for example, low workload measures may demonstrate both effectiveness and safety). At the same time, measures need to be combined (e.g. workload cannot be taken as the only proof for either).
This example illustrates one application of this for how HF standards can be included and expanded through different levels of abstractions for values and metrics.

26. HV-B: Quality Objectives and Metrics
This a repository for qualitative HFI acceptance criteria and performance objectives. It requires several levels of abstraction and detail.
HV-C data elements include:
HFI Value definitions (level 1 to n)
HFI Value definition relationships (between different levels)
Human Performance Criteria and Metrics (i.e. what is to be measured)
Target Measures (i.e. which quantifiable amount is acceptable)
Methods of Compliance

27. HV-C: Human Interaction Structure (examples)
Human relationships need to be captured, and the interactions with the work domain. Generalised Views of information exchanges are needed that clarify role dependency constraints set up elsewhere. Virtual and Physical locations need to be defined for assessment.
Both OV-2 and SV-1 implicitly capture human activity and interaction requirements through the functionality of the nodes. However, OV-2 primarily captures a network of communication technology. SV-1 captures its instantiation and actual use. HV-C captures the human network by focusing on what happens at the human elements of the nodes, how human functions may be distributed, and for which human purposes the technology-based communication network enables operations. Thus, it captures essential non-functional requirements underpinning the design of technology. It may also be used as the basis for designing human roles and organisational structures. Two levels of representations arise from this requirement. HV-C captures:
Purpose-related boundary definitions underlying information flows;
Team/organisational structures supported by technologies, including constraints due to locations and physical network.

28. HV-C: Human Interaction Structure
Human relationships need to be captured, and the interactions with the work domain. Generalised Views of information exchanges are needed that clarify role dependency constraints set up elsewhere. Virtual and Physical locations need to be defined for assessment.
HV-C data elements include:
Purposes of information manipulation (e.g. access, transmission, sharing)
Locations
Human Roles
Systems

29. HV-D: Organisation (examples)
HV-D distinguishes between two types of fixed organisational dependencies:
Part-whole structures – expressing subdivisions of larger units into smaller units to the level of individual posts (often reflecting functional divisions);
Individuals’ post/job relationships including:
Authority structures (e.g. location of command/supervisory power);
Rank structures (status, pay, grade, scope of responsibilities); note that they cannot always be equated with command structures.

30. HV-D: Organisation
HV-D may be seen as an extension to the existing OV-4 and SV-1. It captures additional properties of human organisations that need to be formally defined as part of the organisational set-up. HV-D defines the following structures: Static organisational structure definitions; Task-organised structures; Organisational Processes, Procedures, Values and Policies.
HV-D data elements include:
Organisational units (e.g. posts/roles; department)
Organisational relationships
Part-whole
Rank/authority structures
Formal task-organised configurations
Formal process and value definitions

31. HV-E: Human Functions and Tasks (example)
Defining functions as ‘owned’ by either human or system defines them as being either a technical development need, or a human structure development need. A function for a system/technology translates into a requirement to build something enabling that function. A function for a human translates into requirements for how human activities need to be organised, where/how they interface with systems, and how human resources need to be made available. A human function also has implications for further specifying the functionality of system components, in terms of how they will be used.
Standard UML diagrams may be used – without yet specifying roles or specific system elements.
Note: ‘system’ is used here for hardware/technology (in line with MODAF terminology)

32. HV-E: Human Functions and Tasks
HV-E supports resource definition process when moving from abstract OV-5 requirements to concrete SV-4 definitions. MODAF incorporates several levels of Allocation of Function (AoF) definitions. The first of them is the definition of activities as either human or system-specific, and defining the functions and tasks required for resources to be fulfilled.
HV-E data elements include:
Human Functions/Tasks
Human Task Decomposition
System Functions
Human-System Interface Requirements

33. HV-F: Roles and Competencies (examples)
To be able to determine role requirements, they have to be mapped to human task requirements. Roles, Tasks, and Competencies comprise definitions that mutually depend on each other.
For example:
Tasks may determine required skills and knowledge;
Existing role/post definitions may influence task descriptions;
New roles may be defined based on competency groupings;
Roles may require competencies for communicating and collaborating.
Standard UML notations can be used for these mappings, or matrixes.
Note: The ‘A’ in KSA (Knowledge, Skills & Attributes) is sometimes also referred to as Aptitudes, or Abilities.

34. HV-F: Roles and Competencies
HV-F maps human functions/tasks to definitions of roles and competencies. It provides a dedicated repository to capture requirements for defining boundaries of human structures at a detailed level, which can be related to definitions of systems and their components.
HV-F data elements include:
Human Functions/Tasks
Roles
Competencies
Function-Role-Competency Dependencies
Where organisational boundaries are drawn that separate a task to be conducted between human individuals, additional team and communication activities are being defined. Role definitions are a fairly abstract concept that, at some point, needs to be related to more concrete post/job/position definitions (types and actual instantiations) that are to be fulfilled by people. A human role is unique to humans, involving the ability and the requirement to hold responsibility. Roles are often components of post/job definitions.

35. HV-G: Dynamic Drivers of Human Behaviour (example)
Handley et al (2006) suggest the need for visualising role re-assignments during changes in organisational tasking configurations (see Figure 46). Flexible organisational units are defined as ‘cells’, based on groupings of human functions that were derived through an OV-5 decomposition.
Handley, HAH, Sorber, TJ, Dunaway, JD (2006) Maritime headquarters with Maritime Operations Center, Concept Based Assessment Focus Area: Organization, Human Systems Performance Assessment Capability Final Report, (September 2006). Pacific Science & Engineering Group, San Diego, CA.

36. HV-G: Dynamic Drivers of Human Behaviour
Design starts and ends with observing behaviour. Capturing aspects of behaviours may have either of two main functions:
Inform design aspects by capturing the ‘essence of’ actual behaviour – i.e. capturing aspects of ‘as-is’ behaviour;
Conduct behaviour assessments to evaluate design decisions, by modelling essential aspects of ‘to-be’ behaviour.
Thus, there is a difference between actual behaviour, as can be observed, and behaviour expectations, as a prediction or a target definition. Underlying both is a set of constraints on what people do, how they do it, and how resources need to be designed and organised. These driving factors are the main focus of HV-G.
HV-G does not capture actual behaviour (since this can be very complex and requires a set of tools), but the dynamic factors underlying behaviour (e.g. time constraints, logical order of activities, task rules in response to task conditions). By capturing such constraints on operations, expectation for essential aspects of behaviour can be expressed. These can also be understood as non-functional constraints on functional definitions.
HV-G data elements include:
Conditions
Representative Scenarios – i.e. a combination of conditions (e.g. critical, frequent, typical situations)
Time Units
States (e.g. snapshots, stable configurations) and Configuration/State Changes, e.g.
Task-based changes of organisational configurations;
Flexible use of resources (e.g. role switches, adaptive automation);
Dynamic behaviour properties/characteristics;
Performance measures (as indicators of expected behaviour).

37. Summary
The need to model an entire Enterprise as a socio-technical system is well recognised.
Enterprise Architectures are being conceived to specify requirements and solutions for all DLOD.
MODAF version 1.1 has significantly modified many of its underlying definitions.
The HVs further expand on this development.
The complementary HVs for MODAF aim to bring together SE and HFI as two related disciplines.
Whilst SE and HFI depend on each other, each is grounded in a set of approaches and philosophies not immediately compatible.
By choosing a SE approach to express HFI design decision areas, HFI professionals are provided with means to communicate to Systems Engineers.
HV elements have the potential of changing traditional SE approaches that can be overly technology focused.