T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r T h i r d Q u a r t e r - 2 0 0 4 12 Introduction Task Analysis is a tool frequently used by human factors experts in analyzing human-machine systems and processes. It examines various aspects of tasks or functions for the following purposes: · Check that human-machine interfaces are compatible with operator abilities. · Aid in the development of training plans and manuals. · Assist in the manpower planning process. A thorough task analysis provides a substantial amount of insight into the task or function that the designer intends the human to perform. As one matures the task analysis, design trades become more apparent. The information obtained in the task analysis can be useful to reliability engineers as well as human factors spe- cialists because the task analysis identifies factors that might affect the reliability of the human elements of a system as well as the reliability of the non-human system elements. This article discusses the applications of task analysis and pro- vides a description of the process of performing a task analysis. To assist both the human factors specialist and the reliability engineer in merging task analysis into other system design activ- ities, the article provides a brief checklist that includes reliabili- ty topics as well as human factors topics. Task Analysis Applications One should conduct a task analysis as part of the design and development of any system or process that includes humans as operators, maintainers, or support personnel. Not only is a task analysis useful in the design of systems that are used in the field, such as radars and automobiles and their maintenance, but also it is extremely useful in the formation of manufacturing and assembly processes and even business processes such as finan- cial processing. Medical instrumentation and procedures could benefit from task analyses. One could even apply a task analy- sis to commercial operations such as sales clerk positions and inventory control. The use of the checklist at the end of this arti- cle, regardless of the level of detail explored for each topic, could lead to revelations about factors that might cause both human errors and the attendant safety and economic conse- quences of those errors. One might ask about when to conduct a task analysis. Like many design analyses, a task analysis evolves as the design evolves. The reader might construe the use of the word "design" to apply only to operational systems, but this would be incorrect. To be both reliable and efficient, manufacturing and business process- es should be designed in an organized manner. Thus, this article applies the word "design" not only to operational systems but also to processes. A task analysis actually is an extension of the "functional analy- sis" that is performed in system engineering. A functional analy- sis is the activity that identifies the specific actions that are required to meet the specific system or process requirements. Functional analyses usually are hierarchical decompositions of system requirements and the actions that are required to meet the requirements. When a suitable level of detail is reached, then one can start the task analysis. Performing an initial task analy- sis early in the design process can aid in the proper allocation of functions to humans, hardware or software. Based on the initial task analysis, one could use Fitt's Law (see Reference, page 34) to perform the functional allocation. As the design evolves and the functions progressively become more "locked in," the task analysis becomes more detailed. The various aspects of each function can be "fine-tuned" to enhance performance and relia- bility. Figure 1 illustrates how task analysis evolves with system or process design. Basics of Task Analysis A task analysis identifies the skills and information required to complete the task, the equipment requirements, the task setting, time and accuracy requirements, and the probable human errors and consequences. The results of a task analysis may be used to adjust the performance parameters, change the operating proce- dures, add or modify job aids and personnel, modify the operat- ing environment, and adjust the maintenance and support processes that are associated with the subject of the analysis. The task analysis categorizes and analyzes tasks by means of the following taxonomy: · Mission · Duty · Scenario and conditions · Task · Function · Subtask · Job · Task element For each task, one collects and analyzes the following: · Equipment acted upon · Consequence of the action · Feedback information resulting from the action · Criterion of task accomplishment · Environments, safety, and health factors · Estimate of probability of error · Estimate of the time to perform the task successfully · Relation of the time and error rate associated with each critical task to the performance time and error rate for the overall system. The checklist provided at the end of this article expands consid- erably on the preceding list. An Introduction to Task Analysis By: Kenneth P. LaSala, Ph.D., KPL Systems T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r T h i r d Q u a r t e r - 2 0 0 4 13 The exact mechanics of conducting the task analysis are actual- ly quite flexible provided they result in the collection of the required data. The most logical mechanism for conducting the task analysis is a multidisciplinary team that includes human fac- tors personnel, reliability engineers, and other hardware and soft- ware engineers. This team can perform the task analysis at dis- crete points in the system development process, as implied by Figure 1, or it can operate on a more or less continuous basis continually updating the initial task analysis with the design details that become available as the system or process evolves. As mentioned previously, one member of the task analysis team should be a reliability engineer. The need for this person should become apparent when one observes that error probability (or unreliability) is an important part of the task analysis. Error probability alone certainly is informative, but an analysis of error context adds greatly to the value of the error assessment. Reliability engineering tools such as fault tree analyses, failure modes, effects, and criticality analyses, and even reliability predic- tion establish that needed context and help identify the tradeoffs that are available. Note that the recommended reliability tools include reliability prediction even though reliability prediction methods for human elements are still evolving. Figure 2 shows, in a very simple way, how neglecting the reliability of the human can lead to serious overestimates of system or process reliability. The task analysis should be kept current with the design effort during each phase of system or process development. The use of a database may help maintain currency. In all cases, the current version of the task analysis should be traceable to earlier versions. System Requirements Definition System Functional Analysis Initial Task Analysis Preliminary Synthesis and Allocation of Requirements Trade-off and Optimization Is Design Approach Acceptable? No Yes DISAPPROVAL Synthesis and Definition Detailed Task Analysis APPROVAL System Design Review Figure 1. Task Analysis and System Development (Expanded from B.S. Blanchard and W.J. Fabricky, System Engineering and Analysis 2nd Ed., Prentice Hall, 1990, page 58) T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r T h i r d Q u a r t e r - 2 0 0 4 14 Task Analysis Design Checklist Table 1 is a checklist that may be used for conducting a task analysis that also explicitly considers reliability. This checklist may be used in any stage in the development of a system or process that consists of hardware, software, and humans. Naturally, the collected data will become more specific as the system or process evolves. For each task or human function in a system or process, collect and analyze the data as shown in Table 1. Note that a "Yes" or "No" answer is only the first step in evaluating the design of a task or function. For items to which a "Yes" response has been given, "how acceptable?" must be asked. The reader is referred to the Reference for more information about specific task analysis tools and design acceptability criteria. For those seeking a more inter- active environment, there is the short course entitled Human Reliability (), available from the Reliability Analysis Center (RAC) at . For exploring the quantitative impact of various parameters on task/function and sys- tem/process reliability via the Reliable Human-Machine System Developer (REHMS-D) decision support software, please visit . Reference K. LaSala, A Practical Guide to Developing Reliable Human- Machine Systems and Processes, Reliability Analysis Center, RAC-HDBK-1190, August 2002. About the Author Kenneth LaSala currently is the Director of KPL Systems, an engineering consulting firm that focuses on reliability, maintain- ability, systems engineering, human factors, information tech- nology, and process improvement. Dr. LaSala has over 33 years of technical and management experience in engineering. He has managed engineering groups and served as a senior technical staff member in systems engineering, reliability and maintain- ability (R&M), and product assurance for the Air Force, the Navy, the Army, the Defense Mapping Agency, and NOAA. He was the President of the IEEE Reliability Society during 1999- 2000 and is the chairman of the IEEE Reliability Society Human Interface Technology Committee. He also currently participates in the DoD Human Factors Engineering Technical Advisory Group and the DoD Advisory Group on Electron Devices. His publications include several papers on R&M, systems require- ments analysis, and other engineering topics. He also is the author of a chapter on human machine reliability in the McGraw- Hill Handbook of Reliability Engineering and Management, a co-author of the IEEE video tutorial on human reliability, and the author of a MIL-HDBK-338 section on the same topic. His research interests include techniques for designing human- machine systems and progressive system engineering approach- es. He received the B.S. degree in Physics from Rensselaer Polytechnic Institute, the M.S. in Physics from Brown University, and the Ph.D. in Reliability Engineering from the University of Maryland. R = 0.98 BUT human error has not been considered! Radar R = 0.99 Air Controller R = 1 (Ignored) Transmitter R = 0.99 Aircraft located Positioning instructions sent R = 0.78!! Human error has been considered Radar R = 0.99 Air Controller R = 0.8 Transmitter R = 0.99 Aircraft located Positioning instructions sent Figure 2. Impact of Human Reliability T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r T h i r d Q u a r t e r - 2 0 0 4 15 (Continued on page 17) Required Information Yes No Date & Reviewers 1. Is there a top-level system reliability requirement that has been allocated to the specific task or function? 2. Has the task or function been properly assigned to a human rather than hardware/software? 3. Has an Operational Sequence Diagram been developed for the task or function? 4. Has the equipment acted upon been identified? 5. Has the consequence of the action been identified? 6. Has the feedback information resulting from the action been identified? 7. Have the criteria of task accomplishment been identified? 8. Has an estimate of the time to perform the task successfully been identified? 9. Have the following input parameters been identified? a. Information required b. Information available c. Initiating cues d. Data display format 10. Have the following central processing parameters been identified? a. Decision or evaluation processes b. Decisions reached after evaluation c. Job knowledge required d. System knowledge required e. Academic knowledge required f. Significant memorization required 11. Have the following response parameters been identified? a. Actions taken b. Body movements required by action taken c. Workspace envelope required by actions taken d. Workspace envelope available for actions taken e. Physical skills required f. Frequency or interval of actions g. Tolerances of actions h. Tools and job aids used i. Support and test equipment j. Power required k. Spares or parts required l. Adequacy of space support m. Controls used n. Controls locations o. Instrumentation, displays, and signals used p. Instrumentation, display, and signal locations 12. Have the following feedback parameters been identified? a. Feedback required b. Feedback available c. Cues indicating task completion d. Rate of feedback update e. Format of feedback 13. Have the following environmental parameters been identified? a. Workspace available b. Workspace envelope required c. Workplace arrangement d. Environment contamination level e. Climate (temperature, humidity, oxygen) f. Noise g. Shock, vibration, motion h. Lighting i. Workspace accessibility j. Workplace accessibility Table 1. Task Analysis Design Checklist T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r T h i r d Q u a r t e r - 2 0 0 4 17 Root Cause Analysis for Beginners, QUALITY PROGRESS, pub- lished by American Society for Quality, July 2004, page 45. This article provides a good introduction to root cause analysis, defines what it is, describes its purpose, and describes a four-step process for determining the root cause of an event. A useful Root Cause Map is provided to help explain the process. Using Software metrics and Program Slicing for Refactoring, CROSSTALK, published by Software Technology Support Center (USAF/AMFC), July 2004, page 20. This article explains how using specific software metrics, and a technique called program slicing, designers can develop software systems that have higher quality and are more maintainable than would be otherwise pos- sible. Pentagon Setting Guidelines for Aircraft Interoperability, NATIONAL DEFENSE, published by NDIA, July 2004, page 47. With the increasing number and variety of unmanned aerial vehi- cles (UAVs), the Pentagon is considering establishing interoper- ability standards for UAVs. Although not advocating standard or common operating systems, the Pentagon is looking at requiring standard interfaces to allow UAVs to interact with each other. Six Sigma and Supply Chain Excellence, QUALITY DIGEST, pub- lished by QCI International, August 2004, page 34. The article presents a 12-step approach for integrating six sigma and lean and applying the result to the supply chain. The Challenge of Producing Quality Material in an Environment of Reform, DEFENSE AT&L, published by the Defense Acquisition University, September-October 2004, page 30. In this article, the author presents his views of how acquisi- tion reform has negatively affected the role of the quality disci- pline in military hardware production programs. Solutions for strengthening quality are presented that stress a back-to-basics approach. Bridging the Military-Commercial Reliability Gap, DEFENSE STANDARDIZATION PROGRAM JOURNAL, published by the Defense Standardization Program Office, April-June 2004, page 58. The authors describe a gap between the approaches to reliability used by the military and commercial industry. They propose that the military modify its approach to bridge the gap. Evaporative Spray Cooling for Electronic Assemblies and Systems, DEFENSE STANDARDIZATION PROGRAM JOURNAL, pub- lished by the Defense Standardization Program Office, April- June 2004, page 68. The authors examine the advantages and limitations of using evaporative spray cooling for electronics. They compare evaporative cooling with traditional air-based cooling on the basis of cost, reliability, maintenance, and per- formance. An Introduction to ... (Continued from page 15) Required Information Yes No Date & Reviewers k. Life support and protective gear 14. Have the following safety parameters been identified? a. Types and locations of safety hazards b. Cause of safety hazard c. Frequency of safety hazard d. Consequences of safety hazard e. Safety procedures f. Recommendation to eliminate or minimize safety hazard 15. Have factors that affect health been fully identified and evaluated? For example, chemicals, flame and fire, heat, vapors. (See RAC Reference this article, Section 4.3.3) 16. Have performance standards and workload parameters (e.g., accuracy assessments, workload time line) been identified and evaluated? (See RAC Reference this article, Section 4.3.3) 17. Have social and organizational parameters, such as personnel interdependence, been identified and evaluated? 18. Has the impact on system or process reliability been determined qualitatively or quantitatively? a. Has the task or function reliability block been modeled as a combination of human, hardware, and software blocks? b. Has a fault tree been constructed for the task or function? c. Has a failure modes analysis been conducted for the task or function? d. Has a quantitative reliability estimated been developed for the task or function? e. Has the relation of the time and reliability associated with each critical task to the performance time and reliability for the overall system or process been identified? Table 1. Task Analysis Design Checklist (Cont'd) RMSQ Headlines