Task And Error Analysis For Battlefield Technology Evaluation: A Battle Management System Case Study

Introduction

The application of structured human factors methods during the design and evaluation of work systems and technologies has long been championed by those within our discipline [1,2]. This proposition is especially relevant in the context of battlefield technologies where new and advanced technologies are continually being exploited, and the consequences associated with poor design can be extreme. As the military continues to move towards the digitization of processes such as mission planning and battle management, there are concerns regarding the usability of these systems and also the problems that inappropriate design may create; Kuper and Giurelli [3], for example, argue that digitization of military processes will lead to additional ‘emergent’ work, including more direct work as well as the work associated with digital system operation. Further, a large body of literature in the field of usability demonstrates how inappropriate design can significantly hinder performance on computer-based systems [4].

One element of this widespread digitization is the development of digitized laptop-based Battle Management Systems (BMS), which are typically designed to replace more traditional approaches such as paper map and acetate-based mission planning and battle management processes. The aim of this paper is to demonstrate how human factors methods can contribute to the evaluation and redesign of such technologies, and indeed battlefield technologies generally. An application of two core human factors methods, task analysis and error prediction, for the evaluation of a new digitized BMS is presented. Specifically, Hierarchical Task Analysis (HTA) [5] and the Systematic Human Error Reduction and Prediction Approach (SHERPA) [6] were used to evaluate the usability of the new BMS and to generate design guidance for correcting usability issues.

Hierarchical task analysis

HTA is a commonly used task analysis approach that focuses on the hierarchical decomposition of goals (an objective or end state). The method was developed in the 1960s in response to increases in the complexity of work tasks around that time; older task analytic methods, borne out of the Taylorism movement, could not deal with the cognitive components of new work tasks. HTA was thus proposed, and was unique in that, in addition to physical tasks, it was able to describe the cognitive aspects of goal attainment. The method has since flourished and is seen by many in the discipline as the cornerstone of human factors analyses.

HTA works by decomposing systems into a hierarchy of goals, sub-ordinate goals, operations and plans; it focuses on “what an operator…is required to do, in terms of actions and/or cognitive processes to achieve a system goal” [7, p. 1]. HTA outputs specify the overall goal of a particular system, the sub-goals to be undertaken to achieve this goal, the physical and cognitive operations required to achieve each of these sub-goals and the plans, which dictate the order and conditions under which goals and sub-goals are pursued.

The process is simplistic, involving collecting data about the task or system under analysis (through techniques such as observation, questionnaires, interviews with Subject Matter Experts (SMEs), walkthroughs, user trials and documentation review to name but a few) and then using these data to decompose and describe the goals and sub-goals involved. The utility of the method for system evaluation design efforts is largely down to the various additional analyses that can be undertaken using the initial decomposition; for example, HTA outputs have been used to date for various system design efforts, including interface design and evaluation [8] user error prediction [9] and allocation of functions analysis [10]. These additional analyses allow HTA outputs to be used for the evaluation and design of work systems.

SHERPA

Human Error Identification (HEI) works on the premise that, when one understands the nature of the tasks being performed and the characteristics of the technology being used, errors resulting from the interaction between man and machine can be identified. Although many HEI methods exist, the Systematic Human Error Reduction and Prediction Approach [4] is one popular approach that has consistently achieved acceptable results in terms of the accuracy of its error predictions when compared to real world data (see, for example [8,11,12]).

Using HTA as its input, SHERPA involves classifying task steps into one of five behaviours (action, retrieval, checking, selection, and information communication). Each class of behaviour has a series of associated errors which are then considered in order to identify any credible errors that might occur during performance of the task step in question. Following identification of an error, its consequences, recovery steps, probability and criticality are specified. Finally, remedial measures, designed to modify the design so that the error will not be made, are proposed.

The beauty of using HTA and SHERPA together is that design flaws that hinder performance and create the ideal conditions for human error are identified. With the right team of analysts they can then be designed out of the system through appropriate system re-design. Also attractive is the fact that both approaches can be used throughout the design lifecycle from the design concept stage, to prototype stage, to operational product stage. The latter is particularly useful since Human Factors input is often neglected until problems are identified in new operational systems.

Battle management system case study

The present study involved a Human Factors analysis of a new digitized BMS designed to support land warfare activities. Researchers were given access to Brigade and Battle Group headquarters during a three week long operational field trial involving the BMS. The BMS itself provides support (i.e. planning tools and real time situational display) for land warfare mission planning and battle management tasks, providing users with various tools, such as mission analysis, decision support overlay matrix, synchronisation matrix construction tools, a Local Operational Picture (LOP) display presenting real time friendly and enemy location and movement information and also various collaborative tools such as instant messaging and email facilities. The BMS has been designed to replace the existing paper map system, whereby planning is supported through paper maps of the battlefield area, and planning products are produced on acetate overlays and flipcharts. During battle management, radio communications are used to maintain a real time representation of the battle on a paper map of the battlespace.

Design

The study involved direct observation of mission planning and battle management activities within the Brigade and Battle Group Headquarters (HQ) during a full operational field trial.

Materials

The materials used for this study included the BMS terminals, the other materials used throughout the trial, including those at each HQ (such as maps, pens, VHF radios, acetates, tables, chairs, smart boards, and standard operating instructions) and also on the battlefield (such as vehicles, equipment, and weapons). Various materials were used by the analysts for data collection purposes, including notepads and pens, digital cameras, and Dictaphones for audio recording purposes.

Procedure

For a detailed description of how HTA and SHERPA are applied, the reader is referred to [1]. Prior to the trial, the authors were given an introductory training course in the BMS and also the land warfare mission planning process. During the trial, the analysts undertook direct observation of activities in the Brigade and Battle Group HQs. During this time analysts were given access to planning products, logs, briefs and SMEs.

Typically analysts observed activities during a particular mission planning cycle, followed by execution and management of the battle. Upon completion of the planning/execution activities, analysts then held informal discussions with the key personnel involved in order to gather more details regarding events of interest, to clarify unclear elements of the events observed, or to interrogate users of the BMS regarding its usability and performance.

HTAs were constructed by one analyst for mission planning and battle management activities. The analyst used data derived from observations and discussions with SMEs, along with the BMS itself, to describe the goals, sub-goals and physical and cognitive operations required when using the BMS to plan missions and manage battles. A HTA software tool was used to support this process. Upon completion, the HTAs were reviewed by the other analysts. One analyst then conducted walkthrough analyses using the HTA and the actual BMS in order to identify design flaws limiting performance efficiency with the system. The observational data was also used for this purpose. The analyst responsible for creating the HTAs then used SHERPA and the BMS to identify the errors likely to be made by end users during mission planning and battle management activities. This involved taking each bottom level task step from the HTA outputs and using the SHERPA error taxonomy to identify any credible errors that could be made during performance of that task step using the BMS. For each error identified, task walkthroughs on the actual BMS were used to determine the error’s consequences, recovery steps, probability and criticality. The SHERPA output was reviewed by one of the other analysts.

Results

This paper reports the analysis of mission planning activities only. HTAs were constructed for each step of the Combat Estimate process, which is the planning process currently used by UK land warfare forces. The process entails working through seven questions (such as what is the enemy doing and why? What have I been told to do and why? and What effects do I want to have on the enemy and what direction must I give to develop my plan?). The process required for each question is outlined below, followed by the findings from the HTA analysis for each question.

Question one involves the conduct of battlefield area evaluation, threat evaluation and threat integration processes. Battlefield area evaluation involves conducting a terrain analysis using maps of the battlefield followed by an assessment of the effects of the battlespace on enemy and friendly operations. It also involves the identification of key areas of terrain, including likely mobility corridors, areas of cover and concealment, avenues of approach and manoeuvre areas. Other key aspects analysed include the weather, restricted areas, and potential choke points.

Threat evaluation involves identifying the enemy’s likely modus operandi by analysing their tactical doctrine, past operations and their strengths and weaknesses. Upon completion an understanding of how the enemy is likely to given the current terrain and situation is generated. Key inquiries here include the enemy’s strengths and weaknesses, their organisation and planning and battle management effectiveness, equipment and doctrine and also their tactics and preparedness. The physical outputs are a series of doctrinal overlays which portray the enemy’s organisation, equipment and doctrine, and tactics and preparedness.

The threat integration phase involves combining the battlefield area evaluation and threat evaluation outputs in order to determine the enemy’s intent and how they are likely to operate. The outputs include an enemy effects schematic, which depicts the enemy’s mission and intent, situation overlays for each potential enemy course of action and an event overlay, which depicts where and when key tactical events are likely to occur. Key elements identified during this phase include Named Areas of Interest (NAIs) and likely enemy courses of action.

The HTA for Question one is presented in Figure 1. The HTA analysis revealed that undertaking question one with the BMS is an overly difficult, error prone and time consuming process. The process of analysing the battlefield area is made especially difficult due to problems with the BMS mapping, screen size and screen resolution. These problems mean that the entire battlefield area cannot be viewed in its entirety on one screen. During the exercise users had to continually zoom in and out of the battlefield area, a process which resulted in them losing awareness of what area of the battlefield they were actually looking at. Further, poor levels of screen resolution and inadequate mapping meant that users could not see specific areas (such as towns) in the level of detail required. Users also failed to identify key areas (such as small towns, rivers, dams, and roads) on the map.

The BMS drawing tools, which are integral to question one activities, were found to be difficult to learn and use, convoluted and counter-intuitive; for example, many processes were found to counter-intuitive and did not conform to standard conventions. Placing items on the map, for example, involves having to left click on the map, then right clicking on a drawing object whilst holding control.

Question two, the mission analysis, asks ‘what have I been told to do and why?’ Of interest are the specified and implied tasks and the freedoms and constraints associated with the mission. Question two involves completing a mission analysis record, which requires a statement of the mission two up (that is, two echelons up the command chain) and one up (one echelon up the command chain), a statement of the main effort, description of the specified and implied tasks, their deductions, Requests For Information (RFIs) and Commanders Critical Information Requirements (CCIRs).

Completing the mission analysis component using the BMS entails manually entering a description of the mission, the specified and implied tasks, any mission constraints and any additional information using the mission analysis tool. Following this, CCIRs and RFIs are entered manually. The BMS mission analysis component utilises a simple text box and keyboard entry system.

Completing the mission analysis on the BMS was found to be a straightforward process. The key benefit of the BMS here is that the mission analysis record can be quickly disseminated to other agents using the system’s messaging functionality. One problematic aspect revealed by the analysis, however, is the lack of a free text entry function for the specified and implied tasks section. Currently the user has to use an ‘add specified/implied task’ button, which opens up a new window in which the details are subsequently entered. Again this is convoluted and allowing the user to enter the text directly into the first specified/implied task text box would be more appropriate. Additionally (although this is a problem throughout the system), the use of an (X) icon, rather than an ‘OK’ icon, to exit completed data entry windows is counter-intuitive.

During Question three, the Commander specifies the desired effects on the enemy. Based on the situational understanding derived from the outputs from questions one and two, the Commander identifies the effects required to achieve the mission and also prevent the enemy from achieving their mission. These effects are specified through an effects schematic overlay, which gives the Commander’s purpose and his direction to the staff for each of the effects specified. The Commander also specifies what the main effort will be and the desired mission end state and confirms any CCIRs and RFIs.

The BMS Question three process involves the use of the user defined overlay and BMS drawing tools to construct the Commander’s effects schematic. The usability issues associated with drawing and overlay construction issues described above are thus also present here.

Questions four, five, six and seven are primarily concerned with the development of the Courses of Action (COA) required to achieve the Commander’s desired end state. Since the questions are typically undertaken together or in parallel the BMS contains a Q4-7 COA development tool.

Question four involves identifying where each of the actions and effects specified by the Commander will be best achieved within the battlespace area. The Commander’s effects, NAIs, Target Areas of Interest (TAI) and Decision Points (DP) are placed on the map. The output of question four is a draft Decision Support Overlay (DSO) which contains the Commander’s effects, NAIs, TAIs and DPs for the mission.

Undertaking question four on the BMS involves manually adding the commander’s effects, NAIs, TAIs and DPs to the battlefield area and then textually adding these features using the DSO tool. Again due to the usability issues associated with the BMS’s drawing tools, producing the DSO is both time consuming and error prone. For example, observation of this process during one instance showed that it took approximately four times longer (one hour after significant training and practice) to produce the DSO using the BMS as opposed to around fifteen minutes using paper maps and acetates.

Question five involves specifying the resources required in support of each of the Commander’s effects, NAIs, TAIs and DPs. Effects are considered along with the e mission, type, size and strength of the enemy at each NAI and TAI. The output of question five is a series of potential COAs for each effect, NAI and TAI and a Decision Support Overlay Matrix (DSOM). A decision is then made on how to resource each effect, NAI and TAI, which leads to the production of the final DSOM. The DSOM is produced semi-automatically on the BMS; however, some portions require completion, namely the purpose, assets and remarks sections. The analysis indicated that a lack of explicit links between the NAIs, TAIs and DPs within the BMS is problematic and users cannot easily discern the relationship between the NAIs, TAIs and DPs. Further, since the BMS auto produces the DSOM there is some concern that the lack of user involvement may enhance error potential since the user is not refining the details as they complete the DSOM. Moreover, it is likely that these errors will not be identified by users.

Question six focuses on the time and location of each course of action i.e. when and where do the actions take place in relation to one another? A synchronisation matrix is produced, which includes a statement of the overall mission and the concept of operations and then a breakdown of events related to time, including enemy actions, and friendly force components’ activities and decision points. The output of question six is a draft synchronisation matrix and a decision support matrix.

Question six is completed on the BMS using the synchronisation matrix (synch matrix) tool. The synch matrix tool was found to be problematic during the exercise and the HTA. For example, in one instances, the synchronisation matrix product took around six hours to complete. The old process involved manually drawing a synchronisation matrix on a whiteboard and populating it as appropriate. The BMS process involves first constructing a synchronisation matrix template and then populating it by adding different action groups (such as enemy and friendly forces), actions (such as recce and arty) events and timings. The synchronisation matrix is then distributed via a publish and subscribe feature, following which it can be printed out.

Many errors were observed during the synchronisation matrix construction process. Further, there was often much consultation and discussion with others regarding how the tool should be operated. The user in this case made many errors and had to consult with various other personnel on how to undertake the process correctly. Instances of users having to give up, after a significant time investment (for example, up to one hour), and start over were as they could not rectify an earlier error were also observed. The menu icons were also found to be unintuitive and users had to continually float the mouse over the menu icons in order to see what they actually were.

Printing the synchronisation matrix itself was also problematic as the printers used could not print the entire synchronisation matrix on one page, which meant that the entire matrix could not be viewed at once. As a result of the problems identified above, in one instance the synchronisation matrix was not ready and the orders were sent without it.

Question seven involves identifying any control measures that are required for the courses of action specified. Control measures are the means by which activities are coordinated and controlled. Control measures include phase lines, boundaries, fire support coordination measures and lines, assembly areas and rules of engagement. On the BMS control measures are added to the map using the drawing tools and the details are entered textually within the Q4-7 COA development window. The drawing tool issues described above impacted the question seven process.

A number of general usability issues were also revealed via the HTA analysis. These included that one screen is insufficient to support mission planning activities, processing power issues, and an unnecessary complex logging on process.

The HTA outputs revealed several issues associated with the BMS interface and mission planning tools that could potentially limit user performance and usability. A summary of the main findings in relation to the mission planning tools produced, along with suggested remedial measures, is given in Table 1.

SHERPA

The SHERPA analyses were undertaken based on the HTA task descriptions and the BMS. This involved the analyst walking through the HTA using the actual BMS and using the SHERPA taxonomy to predict design induced errors. An extract of the SHERPA analysis is presented in Table 2.

Whilst the HTA analysis focused on general design flaws, the SHERPA analysis predicted a range of specific errors that could potentially arise when using the BMS. First, various action errors were identified on the user input tasks. These included operation too little/too much errors, such as the user failing to scroll down menus enough or scrolling too far down menus, misalign errors, such as the user selecting the wrong area on the map display when marking up maps, selecting the wrong item from menus or pressing the wrong button or command on the interface, right operation on wrong object errors, such as the user selecting the wrong function from the toolbar or drop down menus and clicking on the wrong item/button/command on the interface (due to inadequate design of icons), wrong operation on right object errors, such as incorrect data entry errors, and operation omitted errors, such as the user failing to perform a task (for example, failing to save current file).

The other errors identified including checking errors, such as failing to check data entered into the system and failing to check data presented by the system. Information retrieval errors included misread errors on behalf of the user and finally wrong selection errors involved the user making a wrong selection of some sort, such as selecting the wrong function from the tool bar or drop down menus and the user selecting inappropriate positions.

A series of remedial measures were proposed in order to eradicate or reduce the potential of the identified errors occurring.

Discussion

The analysis presented demonstrates how task and error analysis can contribute to the evaluation and redesign of battlefield technologies. HTA was used to describe the operation of a newly developed BMS, following which usability issues, identified through undertaking HTA tasks on the BMS were identified. SHERPA was then used to predict the errors that would likely be made by users operating the BMS.

Various usability-related issues were identified. The analysis indicated that the majority of planning tools are counterintuitive, difficult and time consuming to use, and prone to a range of user errors. A lack of standardised conventions was identified throughout the BMS, with the designers failing to exploit standardised user conventions from existing (and well used) systems, such as Microsoft, IBM and Apple. Examples include the ‘BMS copy process’ (which involves holding control on the keyboard and right clicking the mouse to copy, and then left clicking to paste), having to click on the X icon in some windows upon completion of a task and the lack of a drag and drop drawing function. All represent instances of where standardised conventions have been overlooked and are thus often alien to new users. The icons used (that is, for buttons on toolbars) were also found generally not to be standard and were often confusing for users.

The HTA also indicated that a number of the processes were difficult and highly convoluted. For example, the marking up of maps and the development of overlays were found to be overly complicated, requiring many intricate task steps. This is particularly problematic since the old process is extremely simplistic, quick and intuitive, involving the use of acetates and marker pens overlaid on map of the battlefield area. In both cases designers have failed to exploit users’ mental model of the current process and also standardised conventions.

The BMS menu structures were also found to be problematic. Many were long and contained too many items, increasing user interaction time and also the potential for error. For example, the create/modify menu contained 38 different items. The BMS drawing tools (for marking up maps etc) were found to be unintuitive and overly complex. As a consequence, drawing processes (for example, marking up of maps, overlay construction) were time consuming and complex and the outputs were often inaccurate; so much so that the old paper map and acetate drawing process was the preferred option during the field trial.

Consistency within systems is considered to be a one of the golden rules of interface design [13], ensuring “common action sequences, terms, units, layouts, colour, typography and so on within an application program” [11, p. 13]. The HTA analysis revealed a general lack of consistency across the various BMS interfaces. For example, in some cases the user can click on ‘OK’ icons to finish a process, where in other instances there are no ‘OK’ icons and the user has to click on an ‘X’ icon.

Finally, the analysis highlighted problems with the clarity of the systems interface. Certain aspects of the interface were found to be unclear (i.e. in terms of what planning function they supported) or not sufficiently prominent. Consequently, new users may take a considerable amount of time to find functions or to determine what they actually are.

Despite users receiving considerable BMS training prior to the operational field trial, the usability issues identified had a significant effect on performance. Notably, the fears expressed by Kuper and Giurelli [3] that digitization will create a requirement for further work was evidenced. To get around the usability problems, planners used a combination of the old paper map process and the new BMS in order to plan missions. As certain aspects of the BMS system were either too time consuming or error prone, and thus deemed unusable, many planning activities were undertaken using paper maps, acetates and traditional drawing or marking up tools (such as pens and stickies). Although this appeared to work well, ultimately a point was always reached where the end planning product had to be produced on the BMS to enable dissemination. The result of this was effectively a doubling of process (that is, the process is undertaken on paper and then undertaken again on the BMS). This had the effect of lengthening the overall planning process and ultimately reducing operational tempo.

As part of the analysis a range of remedial measures were proposed. Some of the specific remedial measures are presented in Table 1; however, other more general recommendations included:

• Adoption of accepted conventions, such as those used by Microsoft, IBM and Apple. Most users are highly familiar with these yet they do not appear on the current graphical user interface.
• Simply the menu and menu navigation structure.
• Hide excessive and additional functionality from users.
• Provide a new, standard and simplified drawing system.
• Customisation of the interface for different staff roles.
• Improve screen resolution and refresh rates for panning and zooming.
• Limit the maximum number of windows that can be displayed at one time.
• Provide immediate and relevant feedback on all user actions.
• Clear all text entry forms as a default option.
• Provide meaningful error messages with suggested user actions.

A pressing question raised by this analysis relates to the technology-driven digitization of military processes. That is, precisely what components of land warfare planning and battle management should actually be digitised and what parts should remain non-digital? For example, it is questionable whether the process of analysing the battlefield area (question one) can be facilitated in any way via digitisation. Since it is a mainly a cognitive process, the skills for which have been developed and refined using traditional media (such as paper maps), the extent to which digitisation is beneficial is questionable; the traditional paper maps suffice in terms of providing an accurate representation of the battlefield area, and planners can ‘zoom in and out’ of the battlefield area using maps of different scale. Drawing on acetates is also much easier and user friendly than drawing on the BMS. The outputs of question one consist of various overlays and textual descriptions and thus it is only here where value is added by the BMS, since electronic outputs can be disseminated more rapidly and to a wider audience. However, this could easily be achieved via the use of scanners or smart boards. As a general design principle, the production of electronic documents should be as easy as the analogue process. The present analysis found that this was not the case, leading to a hybrid process of traditional paper maps and acetates and digital BMS. Hybrid BMS, exploiting the capabilities of traditional media and modern technologies, may thus be a logical step until a more usable digital BMS is produced.

The next pertinent question is what form digitization should take? The analysis demonstrated how elements of the BMS, such as the drawing tools, created significant usability problems. It is likely that this is in part down to the fact that they are so different to the existing process. It is these authors opinion that designs which exploit existing, well developed, skill-sets will be more usable and enable better performance. In the case of marking up maps and creating overlays, for example, opportunities to use metaphor-based designs, whereby existing components are built into the digitized system, have been missed. Acetates, overlays, stickies and so on are no longer part of the process, despite having been used for decades within the paper map process. Transformational design, whereby a step-change in process is created, has created more problems than it has solved. The analysis suggests that, when users are so well versed with one process, elements of that process should be built into the new digitized system. For example, a digitized interface incorporating pens, acetate overlays, and stickies would be far more usable than the interface analysed.

It is acknowledged that various usability assessments methods are available; however, it is notable that the most commonly applied methods are checklists (see, for example, [14]) and questionnaires (see, for example, [15]). As a corollary, assessments often produce ratings based on user-opinions and do not specifically identify design flaws or errors. Further, remedial measures are not typically generated through this process. This paper has demonstrated how the simplistic process of task analysis followed by error prediction can make a significant contribution to the evaluation of battlefield technology usability. This approach goes beyond questionnaires and checklists, identifying specific design flaws and user errors and generating remedial measures.

There are notable advantages and disadvantages associated with the approach. Although the present study focussed on an operational system, a significant advantage of these methods is that they can be applied throughout the product design lifecycle. For example, both analyses can be undertaken at the design concept stage using paper or functional drawings. Prototype systems can also be subject to the same analysis. This allows potential design flaws to be eradicated early in the design process, before remedial measures become costly to implement (as in the present analysis). Both task analysis and error prediction approaches are also easy to learn and use, require little resources, and have previously achieved acceptable levels of reliability and validity (see, for example, [9]). On the downside, both approaches are time consuming to apply, with the present analyses incurring a significant time cost both in data collection (three weeks) and analysis (10 days).

One notable limitation of the study presented is acknowledged. Although the analyses were built based on real-world data, the outputs produced were not validated using real world data. For example, the errors predicted were not compared to errors observed in the real world; however, in the case of SHERPA, many previous studies have demonstrated a good level of sensitivity based on errors predicted against errors occurring in the real world. In addition, the outputs from both methods were subjected to expert review.

Conclusions

It is concluded from the HTA and SHERPA analyses that the current version of the BMS has a number of design flaws which limit its usability and also hinders performance on a number of mission planning tasks. In addition, the analysis suggests that HTA and SHERPA can be used together as a valid approach for usability assessment in the battlefield technology context. Further applications of both approaches for this purpose are therefore urged.

Acknowledgement

The work reported in this chapter was undertaken as part of the Human Factors Integration Defence Technology Centre, which is part-funded by the Human Sciences Domain of the UK Ministry of Defence Scientific Research Programme. Dr Paul Salmon’s contribution to this article was funded through the Australian National Health Medical Research Council post-doctoral training fellowship scheme. Finally, the authors are grateful to the many Armed forces personnel who willingly participated in the study described

References

Authors

Dr Paul Salmon, PhD, is a senior research fellow in the Human Factors team at the Monash University Injury Research Institute and currently holds an Australian National Health Medical Research Council post-doctoral training fellowship.

Professor Stanton, PhD, holds a chair in Human Factors in the Transportation Research Group at the University of Southampton, UK.

Dr Dan Jenkins, PhD, is the founder and director of Sociotechnic Solutions, an independent consultancy specialising in the design and optimisation of complex sociotechical systems.

Dr Guy Walker, PhD, is a senior lecturer in the School of the Built Environment at Heriot-Watt University, Edinburgh, UK.

Dr Laura Rafferty, PhD is a post doc research fellow in the Transportation Research Group at the University of Southampton, UK.

Ms Kirsten Revell is currently studying for a PhD in the Transportation Research Group at the University of Southampton, UK.

Figure 1. HTA for question 1 of the mission planning process.

Table 1. Summary of HTA BMS analysis.

Table 2. Extract of SHERPA output from BMS analysis.