Step 4.1

4.1 HSI in the technology opportunities and user needs phase (pre milestone A)

Overview

Pre-Systems Acquisition. Pre-system acquisition is composed of on-going activities in development of user needs, in science and technology, and in concept development work specific to the development of a materiel solution to an identified, validated need. The responsible authority defines policies and directives for development of user needs and technological opportunities in science and

User Need Activities. According to DoD 5000.2R, the MNS shall identify and describe the projected mission needs of the user in the context of the threat to be countered or business need to be met. The user representative, with support from the operational test and evaluation community, develops the needs expressed in the MNS into requirements in the form of Capstone Requirements Documents (CRDs, if applicable) and Operational Requirements Documents (ORDs). CRDs contain capabilities-based requirements that facilitate the development of individual ORDs by providing a common framework and operational concept to guide their development. The CRD is an oversight tool for overarching requirements for a family of systems. Validated ORDs translate the MNS and, if applicable, CRDs into broad, flexible, and time-phased operational goals that are further detailed and refined into specific operational capability requirements contained in the final ORD at System Demonstration.

Technological Opportunity Activities. Technological opportunities within DoD laboratories and research centers, from academia, or from commercial sources are identified within the Defense Science and Technology (S&T) Program. The DoD S&T Program mission is to provide the users of today and tomorrow with superior and affordable technology to support their missions, and to enable them to have revolutionary war-winning capabilities. The S&T Program is uniquely positioned to reduce the risks of promising technologies before they are assumed in the acquisition process.

Analyze Alternatives and Develop Concepts and Technologies. One path into systems acquisition begins with examining alternative concepts, including cooperative opportunities and procurement or modification of Allied systems or equipment, to meet a stated mission need. This path begins with a decision to enter Concept and Technology Development at Milestone A. The phase ends with a selection of a system architecture(s) and the completion of entrance criteria for Milestone B and System Development and Demonstration Phase.

HSI in the Technology Opportunities and User Needs Phase The significant contributions of HIS to the Technology Opportunities and User Needs Phase include determining human performance and safety issues with the proposed system, identifying opportunities for workload reduction, providing HIS inputs to the Analysis of Alternatives (AoA), assessing HIS aspects of affordability and risk, and providing HIS inputs to the MNS.

Relationship to the systems acquisition process

In this step the HSI Program will identify HSI issues and requirements which will set the stage for applying HSI in the system acquisition process.

Step 0.1 Identify HSI Issues and Requirements

Overview - At the outset of an HSI program, attention must be given to defining the HSI issues and requirements to be addressed in the acquisition of the system. The HSI issues and requirements specify the HSI concerns in the analysis of alternatives, assessment of technology, and development of the Mission Needs Statement.

Relationship to the System Acquisition Process In this step the HSI Program will identify HSI issues and requirements which will set the stage for applying HSI in the system acquisition process.

Inputs: The inputs to this Phase include HSI lessons learned and high drivers.

Outputs: The products of this Phase include:

HSI inputs to the MNS
Assessments of HSI aspects of affordability and risk
HSI inputs to the analysis of alternatives
Evaluation of the HSI program at Milestone A

Substeps/Activities/Guidelines The actions required to complete this Step are described in the following sections.

0.1.1 Identify HSI Issues

HSI issues include the major areas where HSI mjust be considered in system acquisition. The key HSI issues in the Technology Opportunities and User Needs Phase of new system acquisition include the following:

0.1.1.1 The extent to which design of alternative approaches should consider the requirements for and implications of human performance and safety;

0.1.1.2 The importance of reduced workload and manning in the development of the new system;

0.1.1.3 The extent to which quality of life and quality of work will be important considerations in the operation of the system;

0.1.1.4 The extent to which human interaction with automation will be important for system performance effectiveness;

0.1.1.5 The extent to which system alternatives will require changes to Navy training systems and equipment, and to the personnel management system;

0.1.1.6 The extent to which information systems will require human involvement in the acquisition , verification, integration, interpretation, and dissemination of information, and the conversion of information to knowledge;

0.1.1.7 For systems where interoperability is expected to be a key performance parameter, the extent to which the human performance will contribute to interoperability of the elements of a family of systems;

0.1.1.8 The extent to which technology options have addressed HSI considerations, and technology is usable and safe;

0.1.2 Identify HSI Requirements

HSI requirements in the Technology Opportunities and User Needs Phase of new system acquisition include the following:

0.1.2.1 HSI deficiencies in existing systems will be identified through a process of acquiring lessons learned and identifying high drivers;

0.1.2.2 Technology opportunities fore alternate system concepts will consider HSI requirements ;

0.1.2.3 Human workload and manpower requirements for alternative approaches will be defined through a process of top down requirements analysis, including mission/ function analysis and function allocation, definition of the roles and requirements for humans and automation, and analysis of human tasks and workload, and skills and knowledge needed to conduct these tasks;

0.1.2.4 Throughout this Phase, and all subsequent Phases of system acquisition, HSI will contribute to system design through a process of human-centered design, embracing development of concepts for reducing human workload, through function automation, consolidation, elimination, and simplification, and conceptual and detail design of human-machine interfaces and embedded training capabilities;

0.1.2.5 Throughout all phases of system acquisition, HSI test and evaluation activities will be conducted, including modeling and simulation, especially human and team in the loop simulation, and verification and validation of design concepts.

Step 0.2 Conduct HSI Front-End Analysis

Overview: The overall thrust of HSI in ship acquisition is to address how to reduce ship manning and human workloads (resulting in reduced ship life cycle costs) while at the same time enhancing the performance and safety of the shipboard warfighter. To accomplish this, HSI must define the complete range of requirements for human involvement, human utilization, human performance, and human safety from the earliest stages of ship system development. Since HSI is a systems engineering discipline, the application of HSI represents a systems approach. The front-end ana;ysis described herein is an adaptation of the top down requirements analysis described in detail in Step 1.0 of this Guide.

Top Down Requirements Analysis (TDRA) is the HSI process for defining human requirements early in system development. It represents a systems engineering approach to specifying the concerns for the human in ship systems. As a systems engineering approach, TDRA is requirements-driven, and is focused on defining system interfaces. In terms of requirements, TDRA is concerned with identifying, analyzing and integrating requirements for missions, system functions, and human involvement in the performance of functions. These requirements lead ultimately to development of design requirements for human-machine interfaces. In terms of a concern for systems interfaces, the scope of TDRA includes the interfaces between the human and other system elements (hardware, software, information, procedures, organizations, and environments).

Bottom-up analysis, on the other hand, is a reengineering process concerned with modifying existing systems. Bottom-up analysis is constraint-driven in that the results of the analysis are constrained by the design of the existing system. Therefore, bottom-up analysis in and of itself will not result in optimal manning reduction since it is too dependent on the existing system, and will not provide the bases for the innovative and creative engineering insight needed to significantly and effectively reduce manning levels.

Bottom-up analysis does however support TDRA in identifying high-drivers. TDRA results in mission requirements and scenarios, functions and requirements. Rather than addressing all possible missions, scenarios and functions, TDRA should be based on high driver missions, scenarios, and functions. These have resulted in high cost, risk, manning, and training in existing systems. Addressing high drivers in TDRA results in: 1) avoiding deficiencies in existing systems; 2) supporting the reengineering of the existing function allocations; and 3) reducing the time and cost of the TDRA by focusing on the important missions, scenarios, and functions from the perspectives of system affordability, risk reduction, human performance, and safety.

Relationship to the System Acquisition Process The front-end analysis is integrated with the system engineering process.

Inputs: Inputs include missions and functions proposed for the new system.

Outputs: The results of the front-end analysis include requirements for human involvement in system operation and maintenance.

Substeps/Activities/Guidelines The actions required to complete this Step are described in the following sections.

0.2.1 Define missions and mission scenarios

Mission scenarios include statements of mission requirements, criteria for mission success, initial and terminal conditions, mission events, mission timeline, and top level functions. Mission conditions under which functions are to be performed include logistics conditions (length of supply lines, resupply frequency), conditions of readiness (systems operational or not operational, extent of damage, etc.), environmental conditions (lighting and visibility, weather, temperature, sea state, etc.), tactical conditions, and operational conditions (sustained operations, operations tempo, clothing conditions, etc.).

0.2.2 Conduct Function Analysis

The ship system HSI Function Analysis will, for each system and scenario identified above, identify functions to be analyzed and prepare a functional flow block diagram depicting the sequence of functions for the system completing a mission scenario. The functions will be analyzed to successively greater levels of detail, and functional flows shall be prepared at the successive sub-function levels.

0.2.3 Allocate Functions to Human or Machine Performance

Through a reverse engineering process, operations and tasks in existing systems which impose heavy workloads on humans, and human performance and safety impacts, are identified, and requirements for alternative allocations are specified. The HSI approach to influencing system design early in system acquisition, with special emphasis on reduction of workload in the emerging system, addresses the issue of assessing the established role of the human in a four step process: 1) identifying existing and alternative roles of the human; 2) identifying specific requirements attendant to these roles for specific scenarios for system areas; 3) modeling human performance as expected in the existing and alternative human roles for the scenarios; and 4) assessing the existing and alternative role-of-human concepts in terms of effectiveness, affordability, and risk reduction.

0.2.3.1 Identify actual and alternative human roles. In identifying the roles of the human in the system, the emphasis, from a reduced workload perspective, is to automate tasks which are currently performed manually. This involves assessing the adequacy of the allocation of functions to human or machine performance in these systems, and identification of where human functions and tasks can be reallocated to automated performance. This assessment requires a reverse engineering of the function allocation approach underlying the design concept implemented in the baseline or existing system. Through the reverse engineering technique the rationale for allocation decisions can be made explicit and opportunities for alternate allocations can be explored. Alternative role of the human concepts involve alternate approaches to automation, providing decision aiding to reduce human workload, and improved design of human-machine interfaces to simplify tasks and reduce workloads.

0.2.3.2 Identify specific requirements attendant to candidate human roles. The requirements associated with specific function allocation/role of man concepts include (a) task requirements (information, performance capabilities, decision and support requirements, task sequencing, and time dimensions of tasks), (b) human knowledge/skill requirements, and (c) requirements for reducing human errors. These requirements are generated for specific scenarios which represent configurations of mission objectives, system conditions of readiness, and special conditions (environmental, operational, logistic, and tactical).

0.2.3.3 Model human performance. For the task sequences and attendant requirements associated with specific mission scenarios, human performance must be modeled to identify potential problem areas. The modeling process is two-fold. First, a task performance model is developed through application of task analysis. When task sequences and requirements are sufficiently understood, a task network simulation is conducted to assess the impact of the function allocation/role of man approach on human performance and workload.

0.2.3.4 Assess the alternative role-of-human concepts. The HSI assessment of function allocation/role of human concepts will include an assessment of technology requirements associated with the concept (in Step 0.4), and, for individual concepts, assessment of effectiveness, affordability and risk. The technology assessment will focus on the extent to which technology advancements are needed to support implementation of a specific alternative concept. The assessment of concept effectiveness will address the extent to which the concept meets system requirements and will enhance system operability, usability, maintainability, supportability, survivability, and safety. The assessment of concept affordability will determine the extent to which life cycle resource requirements are met for operational manpower, maintenance manning, training, personnel non-availability due to accident, expected human error rates, expected time to repair, supportability, and expected system downtime. The assessment of alternative function allocation/role of human concepts in terms of risks involves a determination of critical factors that will have a significant impact on, and have risks for, readiness, life cycle costs, schedule, performance, or design. These include such items as: tasks, task sequences, and task complexity; environments and environmental controls; equipment design features; maintenance requirements; information requirements; manning requirements and associated workloads; personnel skill levels and training requirements; and potential existence of health and safety hazards.

0.2.4 Conduct Task Analysis

Task analysis shall be used as basic information for developing preliminary manning levels; equipment procedures; skill, training and communication requirements; and a s logistic support analysis inputs, as applicable. Those tasks identified during HSI analysis which are related to end items of equipment to be operated or maintained by personnel and which require critical human performance, reflect possible unsafe practices or are subject to compromising improvements in operating efficiency shall be further analyzed.

The next step is to identify workloads and manning requirements associated with alternate function allocation schemes. This step entails (1) developing tasks lists for system personnel, (2) task activity sampling to gather quantitative time for tasks, (3) generation of task networks and associated data (task times, distributions, queuing, branches), (4) preparation of tasks networks for input to the IDEA SIMWAM (Simulation for Workload Assessment and Modeling) simulation tool, and (5) conduct of workload assessment simulations using SIMWAM.

Close cooperation will be needed among NAVSEA, Carlow, and JJMA to select a suitably representative ("typical") ship system operation to ensure that data are generalizable. At least one ship visit will be needed to provide the data for the simulations. This visit should occur aboard a ship while deployed.

Step 0.3 Identify Lessons Learned and HSI High Drivers

Overview When legacy system functions have been identified and analyzed, a comparability analysis will be conducted to identify high driver functions and lessons learned. High drivers are functions which, in legacy systems, are labor intensive, impose demands on human performance, are unsafe, are difficult to train, and require high levels of skill. Lessons learned are design or operational approaches which include problems and positive aspects. Problems should be avoided and positive aspects should be continued in the new system.

Relationship to the System Acquisition Process Lessons learned serve to identify deficiencies in existing systems which are inputs to the MNS.

Inputs: Descriptions of existing systems

Outputs: Lessons learned and HSI High Drivers

Substeps/Activities/Guidelines The actions required to complete this Step are described in the following sections.

0.3.1 Define the Legacy or Baseline Comparison System (BCS)

0.3.1.1 review system functions from the mission/function analysis

0.3.1.2 review prior decisions concerning equipment to be included, functions to be automated, and design approaches to be implemented.

0.3.1.3 identify the baseline system as the system or systems which currently enables the performance of the functions within the constraints

0.3.2 Define HSI Measures of Effectiveness (HMOEs)

0.3.2.1 Identify HMOE Objectives

identify HSI concerns or personnel readiness requirements which are critical for system performance effectiveness, including specific performance constraints, known safety hazards, protection requirements, designated human capability levels, and human availability limitations
determine whether or not HSI has been applied for the item
Identify the objectives of HMOE application: the objectives of HMOE application can include 1) assessment of the HSI process, how effective was HSI in meeting its goals; 2) assessment of HSI products, adequacy of the design concepts and criteria, training program, and personnel utilization approach; and 3) assessment of the personnel readiness asdpects of NDI, an existing system to be improved, or a baseline comparison system.

0.3.2.2 Identify HMOE Evaluation Data Requirements

specify the data required in order to evaluate the effectiveness of HSI application or to assess the personnel readiness of the system or item which had not had HSI applied in its data requirements by each personnel readiness category:
personnel availability/utilization
personnel capability/competence
personnel performance
personnel safety and health

0.3.2.3 Select Evaluation Methods and Conditions

identify evaluation methods which meet HMOE objectives and data requirements
identify conditions to be included or simulated in the evaluation identify conditions to be included or simulated in the evaluation
develop a sampling plan to ensure representativeness and fidelity of test conditions to actual or expected conditions. Sampling factors to be considered in ensuring representativeness and fidelity of test conditions to actual or expected conditions

0.3.2.4 Identify Evaluation Criteria

Identify system requirements criteria against which data are to be evaluated.
- Identify human factors engineering standards against which data are to be evaluated.
- Identify safety/biomedical standards against which data are to be evaluated.
- Identify HSI requirements against which data are to be evaluated.

0.3.2.5 Identify Evaluation Measures for evaluation of system design and readiness

Evaluation of system design for fightability
- time to detect and range at detection
- first round accuracy
- target engagement performance
- performance throughout graceful degradation
- performance of battlefield management activities
- performance of command and control activities
- performance of surveillance activities
Evaluation of system design for operability
- adequacy of communications
- error occurrence and recovery rates
- environmental effects
- information handling performance
- human-machine interface design compliance
Evaluation of system design for maintainability
- fault detection performance
- fault isolation - troubleshooting performance
- time to repair
Evaluation of system design for safety
- identification of hazards
- evaluation of design to remove hazards
- evaluation of guards
- evaluation of warnings and instructions
- accident incidence and severity rates
- adequacy of protection systems
Evaluation of system design for habitability
- evaluation of free volume
- evaluation of environmental effects
- evaluation of traffic patterns
- evaluation of workspace layout
- evaluation of the acceptability of living spaces
Evaluation of system design for survivability
- evaluation of protection systems and devices
- evaluation of human performance wearing protective ensembles
- evaluation of countermeasures
Evaluation of system design for supportability
- evaluation of system documentation
- assessment of the adequacy of spares access
Evaluation of system design for transportability
- time and effort involved ip preparing for transport
- performance in monitoring system condition during transport
Evaluation of system design for installability
- time and accuracy in setting up
- performance in making and mating subassemblies
Evaluation of personnel availability
- adequacy of manning levels
- potential for reduced manning
- adequacy of workloads and workload distribution
Evaluation of personnel utilization
- adequacy of the assigned role of the human vs. automation
- adequacy of the human roles in automated functions
Evaluation of personnel training
- training effectiveness measures
- training pipeline measures
- cost of training
Evaluation of usability ñ see Step 0.4.1.10

0.3.2.6 Identify evaluation measures for evaluation of the adequacy of HSI products

completeness
accuracy
feasibility
quality
timeliness
consistency
in compliance

0.3.3 Identify High Driver Functions

0.3.3.1 Conduct a comparability analysis to identify high drivers

collect data from appropriate subject matter experts (SMEs) on task criteria as they relate to each function and sub-function for the mission scenarios described in the mission analysis
identify functions, tasks, task performance conditions, and performance situations which are: labor intensive, have high error rates, are accident prone,,or require complex skills and training.

0.3.3.2 Analyze High Driver Functions

conduct a task analysis of each high driver task
identify characteristics of a task, task condition or situation which cause it to be a high driver
identify potential problems with performance of the task

0.3.4 Identify Lessons Learned from the baseline comparison system

0.3.4.1 Acquire lessons learned data

conduct documentation searches
conduct interviews of job incumbents
conduct observations of ongoing activities
- acquire measurements of workplaces and environments

0.3.4.2 Analyze lessons learned data ñ identify problems or positive factors associated with:

training
personnel skill
operations
environmental effects
information management/quality
human performance
safety and health
human workload
allocation of functions to humans and machines
system effectiveness

0.3.4.3 Validate lessons learned data

identify data needing validation
identify/resolve data inconsistencies
validate problems and causal factors

0.3.4.4 Prioritize lessons learned data

prioritize in terms of mission impact
prioritize in terms of personnel performance and safety

0.3.4.5 Use lessons learned to identify conditions, scenarios, design features, etc., which cause a function to be a high driver

0.3.4.6 Integrate high driver/lessons learned data

identify problems which are HSI problems
identify possible causes for problems
identify positive aspects of the BCS
identify positive aspects of BCS which should be retained

0.3.4.7 Identify potential solutions to HSI problems

identify design solutions
identify NDI solutions
identify product improvement solutions
identify manning solutions
identify selection/training solutions
identify policy/procedural change solutions
integrate problem solutions

Step 0.4 Identify Opportunities to Reduce Workload and Conduct HSI Technology Assessments

Overview The potential to reduce workloads will be conducted in terms of four alternative approaches and combinations of these. The approaches are: determine workload reduction potential through (a) automation; (b) task simplification; (c) function elimination; and (d) function consolidation.

1) Determine the potential for function automation to reduce workload. This effort entails a determination of which tasks is increased automation feasible, identification of the role of the human for tasks for which the level of automation has been increased, and a determination of how automation will modify task sequences and/or reduce the likelihood of human error.

2) Determine the potential for function simplification to reduce workload/manning. This activity focuses on identification of the potential for reducing physical task demands, cognitive task demands, and perceptual-motor task demands. The overall objective is to reduce: amount of information to be processed, complexity of the information processing, number of decisions and options to be handled, complexity of actions, needs for interactions with other operators, extent and complexity of communications, task performance accuracies required, special skills and knowledges required, levels of skills, the level of stress associated with the performance of tasks under representative mission conditions, and time constraints.

3) Determine the potential for function elimination to reduce workload. This activity requires a determination of the potential with which system functions performed onboard can be offloaded to shore-based elements, to other ships or platforms, or to other ship systems.

4) Determine the potential for function consolidation and cross training to reduce workload. This effort entails determination of tasks for which consolidation and cross training is feasible; identification of the role of the human for tasks for which consolidation/cross training has been implemented, and determination of how consolidation/cross training will modify task sequences and/or reduce the likelihood of human error.

Relationship to the System Acquisition Process: This step results in workload reduction approaches and technology assessments for alternate system concepts.

Inputs: Alternate concept descriptions, and technology descriptions.

Outputs: Workloads associated with each alternative.

Substeps/Activities/Guidelines The actions required to complete this Step are described in the following sections.

0.4.1 Assess Technologies to Describe Alternate Design Concepts

0.4.1.1 Identify HSI Requirements by System Function

review alternative system operational and support concepts
identify functions associated with concepts
review function requirements
review projected operator/maintainer tasks/sequences by function
identify HSI requirements by function

0.4.1.2 Survey the State-of-the-Art in Technology

0.4.1.3 Identify technology requirements for function automation

automated information processing
- priority assignment
- information coding/classification
automated decision making
- expert system algorythms
- real time simulation of outcomes
- automated troubleshooting/diagnosis
automated action initiation
- target engagement
- countermeasures
automated control
- robotics
- advanced control
automated system reconfiguration
- system model
- real time simulation
automated system status determination
- readiness determination
- equipment status determination
- crew status determination
automated planning
- gaming simulation
- assessment of options
- formulation of recommendations
automated testing
- automated test equipment (ATE)
- built-in test equipment (BITE)

0.4.1.4.Identify technology requirements for function consolidation

task integration
- cross training
- procedures integration
- workstation integration
  - HFE standard
  - multi-modal watchstation
information integration
- sensor fusion - integration
- integrated displays

0.4.1.5 Identify technology requirements for function elimination

function obliteration

function integration into other function(s)
function offloading
tele-operation
tele-maintenance
tele-command and control

0.4.1.6 Identify technology requirements for function simplification

reducing physical task demands
- lifting aids
- reach aids
reducing cognitive task demands
- on-line help
- decision aids - support
- operator's associate
- expert systems
- intelligent tutoring
reducing perceptual-motor task demands
- visual aids
- auditory aids
- locomotion aids

0.4.1.7 Identify technology requirements associated with achieving interoperability and integration of a family of systems. According to DoD 5000.1, interoperability is the ability of systems, units, or forces to provide data, information, materiel, and services to and accept the same from other systems, units, or forces, and to use the data, information, materiel, and services so exchanged to enable them to operate effectively together. Interoperability within and among United States forces and U.S. coalition partners is a key goal that must be addressed satisfactorily for all Defense systems so that the DoD has the ability to conduct joint and combined operations successfully. The use of standardized data shall be considered to facilitate interoperability and information sharing. To the extent possible, systems and software shall be designed to permit use in a multi-national environment.

standards for common displays, display formats, feedback, alerts and alarms
standards for common and consistent procedures and methods for system operation and maintenance
standards for common protocols and architectures for information retrieval, integration, and dissemination
standards for common verbal and written communications message structure, format, syntax, and semantics
techniques for visualization of system architecture
- to depict system structure
- to depict the system environment
- to facilitate navigation through the architecture
standards for common tactical frames of reference
to enhance communications
to support decision making
to facilitate maintaining situation awareness and tactical perspective

0.4.1.8 Rank Order Technology Alternative

identify technology requirements
develop criteria for ranking technology alternatives in terms of applicability for the system
conduct ranking

0.4.1.9 Assess Technology Availability and Applicability

high rank technology requirements - identify available techniques
determine the extent to which available techniques meet technology requirements
rate technology applicability - the adequacy of alternative techniques
identify technology availability - technology ready date

0.4.1.10 Assess technology representations in terms of usability ñ a major requirement for advanced technology is that it must be usable by the sailor irrespective of his or her level of computer literacy. Usability requires that user expectancies are met, that operations are intuitive, that displays are readable, that presented information and communications are immediately meaningful , and that human interfaces are designed in conformity with human engineering design standards. The activities involved in assessing the usability of technology are as follows:

identify and characterize operator/user problems with use of the technology
assess user productivity
determine the extent to which human-computer interfaces have been designed in accordance with user cognitive, perceptual, and short-term memory capabilities and limitations
determine the degree of transparency of software command modes to the user
determine the degree to which displays and display formats are standardized and are easily read and interpreted
determine the extent to which the user is always aware of where he or she is in a program, and what action is required next
determine the extent to which the user understands the capabilities of the system and the procedures required to exercise these capabilities
determine the extent to which procedures are logically consistent
determine the extent to which user documentation is clear, easily accessed, and readable
determine the extent to which on-line help is available and responsive
determine the extent to which the user is only provided with that information needed when it is needed
determine the extent to which the user understands how to navigate through a program and retrieve needed information

0.4.1.11 Describe Needs for Advanced Technology

identify gaps in the available technology
identify technology requirements for filling the gaps
identify technology development requirements

0.4.2 Define Reduced Workload/HSI Design Concepts

0.4.2.1 Develop alternate design concepts

0.4.2.2 Describe the distinguishing features of design concepts

0.4.2.3. Define workload for alternative concepts - The assigned roles of human vs machine for each function and task will be assessed in terms of impact on workloads through use of task network simulation . The net result of the simulation is a first approximation of which roles of the human are feasible, what workloads are associated with these roles, what problems are to be expected in specific role of human models, and what human performance characteristics should be further investigated.

0.4.2.4. Based on the results of simulation exercises assessing the workloads and performance problems associated with alternate manning strategies, feasible manning reduction concepts will be selected. For these concepts, assessments will be made of how to reduce the manning required at functional duty stations, and the impact of manning reductions on readiness, effectiveness, and safety.

0.4.3 Conduct Tradeoffs to Select Feasible Concepts

0.4.3.1 Identify criteria to be used in making concept tradeoffs. Criteria include effects of alternate concepts on system performance and readiness, and impacts on personnel availability, utilization, capability, performance, productivity, and safety.

0.4.3.2 Assign importance weights to criteria

0.4.3.3 Conduct tradeoffs and select feasible approaches to reduce workload and manning for alternate concepts.

Step 0.5 Provide HSI Inputs to the Analysis of Alternatives (AoA)

Overview: According to DoD 5000.2R, analyzing alternatives is part of the Cost as an Independent Variable (CAIV) process. Alternatives analysis shall broadly examine multiple elements of program alternatives including technical risk and maturity, price, and costs. The analysis shall explicitly consider continued operations and support costs of the baseline. For each alternative, it shall consider requirements for a new or modified Information Technology (IT), or support infrastructure. The analysis shall include sensitivity analyses to possible changes in key assumptions (e.g., threat) or variables (e.g., selected performance capabilities). Where appropriate, the analysis shall address the interoperability and commonality of components or systems that are similar in function to other DoD Component programs or Allied programs . The analysis shall aid decision makers in judging whether any of the proposed alternatives to an existing system offers sufficient military and/or economic benefit to justify the cost. For most systems, the analysis shall consider and baseline against the system(s) that the acquisition program will replace, if they exist. The analysis shall consider the benefits and detriments, if any, of accelerated and delayed introduction of military capabilities, including the effect on life-cycle costs.

The analysis shall be quantitative, and induce decision makers and staffs at all levels to engage in qualitative discussions of key assumptions and variables, develop better program understanding, and foster joint ownership of the program and program decisions. There shall be a clear linkage between the AoA, system requirements, and test and evaluation measures of effectiveness. The analysis shall reveal insights into the program knowns and unknowns and highlight relative advantages and disadvantages of the alternatives being considered.

Relationship to the System Acquisition Process For all programs regardless of acquisition category, DoD Components shall determine the source of support for all new, modified, and replacement systems based on, manpower mix criteria and risk assessment. They shall consider the advantages of converting from one source of manpower to another (military, civilian, or private contract), shall determine manpower and contract support based on both peacetime and wartime requirements, and shall establish manpower authorizations at the minimum necessary to achieve specific vital objectives. As part of this process, DoD Components shall assess the risks involved in contracting support for critical functions in-theater, or in other areas expecting hostile fire. Risk mitigation shall take precedence over cost savings in high-risk situations or when there are highly sensitive intelligence or security concerns.

Inputs: Alternative design concepts

Outputs: HSI inputs to the AoA.

Substeps/Activities/Guidelines The actions required to complete this Step are described in the following sections.

0.5.1 identify alternative approaches for the role of the human in the operation and maintenance of the system for each design alternative.

0.5.2 provide HSI assessment and tradeoff of design alternatives.

0.5.3 identify manpower requirements and state manpower sources for each alternative concept.

0.5.4 define requirements for special skills, new occupational specialties and high quality personnel for each alternative concept.

0.5.5 identify training requirements and assess expected effectiveness of training systems for each alternative concept.

0.5.6 summarize results of HSI studies, analyses, and tradeoffs of alternative design concepts.

0.5.7 provide HSI inputs to life cycle costs for each alternative concept.

0.5.8 describe how human factors engineering and safety/health hazards lessons learned will be applied for each alternative concept.

0.5.9 determine requirements for interoperability for system alternatives, and define specific human performance requirements associated with interoperability

0.5.10 identify and manage HSI cost, schedule, and design risk areas for each alternative concept.

0.5.11 incorporate HSI considerations into the acquisition strategy for each alternative concept.

0.5.12 identify personnel requirements for operators and maintainers for each alternative concept.

0.5.13 identify HSI test and evaluation requirements for each alternative concept.

Step 0.6. Assess HSI aspects of affordability and risk associated with alternative concepts

Overview: An HSI assessment system alternatives is in essence part of the AoA. The HSI assessment integrates the results of all HSI domain assessments into a source document for input to the decision review process. HSI assessments will be conducted prior to milestone decision reviews on all acquisition programs, including materiel change and nondevelopmental items. The objective of the HSI assessment is to determine the status and adequacy of HSI efforts in the materiel acquisition program and to present any unresolved HSI issues or concerns to decision makers at the appropriate decision points. Individual domain assessments (HFE, system safety, health hazards, and manpower, personnel, and training) as well as other pertinent information will be used to formulate the overall HSI assessment.

Relationship to the System Acquisition Process: : In this step the HSI Assessment determines the status and adequacy of the HSI efforts for the AoA, and presents any unresolved HSI issues or concerns to decision makers.

Inputs: System alternatives

Outputs: HSI inputs to assessments of affordability and risk of design alternatives

Substeps/Activities/Guidelines: The actions required to complete this Step are described in the following sections.

0.6.1 Conduct an HSI Affordability Assessment

0.6.1.1 Review affordability objectives - Affordability objectives from a HSI perspective should address the cost risks identified for each alternative . The objectives should include the following:

reduced acquisition costs through HFE/MPT/safety and health integration
reduced acquisition costs through reduced need to redesign systems and equipment to resolve unmet user needs
reduced life cycle costs through reduced operations manning
reduced life cycle costs through reduced maintenance manning
reduced life cycle costs through reduced training time and training pipelines
reduced life cycle costs through reduced needs for new training facilities
reduced life cycle costs through reduced accident rates
reduced life cycle costs through reduced human error rates
reduced life cycle costs through reduced time to repair
reduced life cycle costs through reduced supportability requirements
reduced life cycle costs through reduced system downtime
reduced life cycle costs through reduced personnel non-availability

0.6.1.2 Identify affordability constraints - identify limits on:

operational manpower
maintenance manning
training time and training pipelines
new training facilities
accident rates
human error rates
time to repair
supportability requirements
system downtime
personnel non-availability

0.6.1.3 Conduct an Affordability Assessment

0.6.1.3.1 For each candidate Acquisition Strategy and Alternative design concept, identify life cycle resource requirements for

operational manpower
maintenance manning
training
personnel non-availability due to accident
expected human error rates
expected time to repair
supportability
expected system downtime

0.6.1.3.2 Determine if the proposed acquisition strategy is in line with Defense Planning Guidance and long-range modernization and investment plans.

0.6.1.3.3 Determine the adjustments required of the proposed acquisition strategy due to HSI affordability factors

0.6.1.3.4 Recommend changes to the acquisition strategy, or alternative acquisition strategies to resolve problems due to HSI affordability factors

0.6.1.3.5 Assess alternative design concepts on HSI affordability factors

0.6.1.3.6 Identify alternative design concepts having problems with HSI affordability factors

0.6.1.4 Recommend changes to alternative design concepts to improve performance HSI affordability factors

0.6.2 Conduct a HSI Risk Assessment

0.6.2.1 Summarize cost, schedule and design risks

0.6.2.1.1 Identify Risk Assessment Requirements

Review alternative system operational and support concepts
Review anticipated operator and maintainer tasks associated with alternative concepts
Conduct an SHIP-SHAPE Comparability Analysis to Identify High Drivers in terms of MPT, human performance & safety, and costs
Describe each alternative in terms of requirements for manufacturing, support, cost, schedule, and design factors
Describe each alternative in terms of requirements for
- manufacturing - processes, required resources
- support - magnitude required, special support requirements
- cost - acquisition and life cycle costs
- schedule - factors unique to the alternative which will impinge on schedules
- design factors - special design features of prime equipment or training devices

0.6.2.1.2 Identify/Assess Cost Risks

Review alternative system operational and support concepts
Identify risks due to operational manning levels
Identify risks due to maintenance manning levels
Identify risks due to training costs
Identify risks due to reqmts to redesign to satisfy user needs
Identify risks due to extended down time/sys non-availability
Identify risks due to excessive time to repair
Identify risks due to excessive supportability reqmts
Identify risks due to excessive accident rates
Identify risks due to excessive personnel non-availability
Integrate/assess cost risks
- Review risks
- Determine impact of individual risks
- Prioritize isks
- Summarize risks for each alternative

0.6.2.1.3 Identify/Assess Schedule Risks

Review alternative system operational and support concepts
Identify risks due to non-availability of data
Identify risks due to non-availability of tools and methods
Identify risks due to non-availability of resources
Identify risks due to non-availability of technology
Integrate/assess schedule risks
- Review risks
- Determine impact of individual risks
- Prioritize isks
- Summarize risks for each alternative

0.6.2.1.4 Identify/Assess Design Risks

Review alternative system operational and support concepts
Identify human performance risks for each alternative - Identify tasks/conditions with an alternative which
- increase the likelihood of human error.
- are at or beyond human physical performance capabilities.
- are at or beyond human cognitive performance capabilities.
- contribute to excessive workloads.
- contribute to inadequate productivity.
- contribute to unsatisfactory team performance/interaction.
Identify safety and health hazard risks associated with each alternative - Identify tasks/conditions with an alternative which:
- increase the likelihood of accidents.
- increase the likelihood of health hazards.
- increase the likelihood of psychological stress.
- increase the likelihood of physiological stress.
- increase the likelihood of physical stress (e.g. extreme exertion, cramped environment)
- increase the likelihood of dealing with environmental constraints
- increase the likelihood of dealing with unsafe operating, test, maintenance and emergency procedures
- fail to take in to account life support requirements and their safety implications
- increase the likelihood of dealing with unsafe facilities and support equipment
- do not provide safety-related equipment, safeguards, and possible alternate approaches such as interlocks, system redundancy, subsystem protection, fire suppression systems, personal protective equipment, industrial ventilation, and noise or radiation barriers
- Identify risks due to human error
- Identify risks due to expected accident rates
- Identify risks due to unacceptable performance levels
- Identify risks due to expected inadequate productivity
- Identify risks due to expected ineffective training
- Identify risks due to expected excessive workloads
- Identify risks due to inadequate function allocation
- Identify risks due to excessively complex tasks
- Identify risks due to expected health hazards
- Integrate/assess design risks

0.6.2.1.5 Summarize cost, schedule, and design risks resulting from HSI factors

0.6.2.2 Highlight current human system cost drivers, MPT drivers, human performance, and safety high drivers

0.6.2.3 Identify HSI tradeoff decisions to be made at each milestone. Tradeoffs include:

Role of the human vs automation
Approaches to reduced manning including improved design, task simplification, decision-aiding, automation, or cross-training
Design, manning, or training approaches to reduce high drivers
Alternative human-machine interface design concepts
Hazard elimination, guarding, warning, or training
Training vs job aiding
Required skill levels of personnel
School house training vs organic
Training media-fidelity/cost tradeoffs
Use of advanced technology vs state-of-the-art

0.6.2.4 Conduct a Risk Assessment

0.6.2.4.1 Identify critical Human System Factors in design alternatives that will have a significant impact on readiness, life cycle costs, schedule, or performance:

tasks, task sequences, task complexity;
environments and environmental controls;
equipment design features;
maintenance requirements;
information requirements;
user-computer interface features;
manning requirements;
workloads;
personnel skill levels;
training requirements;
hazards

0.6.2.4.2 Assess risks in terms of high, moderate, or low.

0.6.2.4.3 Identify critical risk subsystem or component for high or moderate risks.

0.6.2.4.4 Identify required action to reduce risks.

0.6.2.4.5 Provide risk assessment/reduction inputs to the Integrated Program Summary

Step 0.7. Provide HSI Inputs to the Mission Needs Statement (MNS)

Overview: The determination of the extent to which mission needs can be satisfied by nonmateriel solutions is defined in this step. The Mission Need Statement discusses the results of the mission area analysis, Identifies any changes in doctrine, operational concepts, organization, and training that were considered in the context of satisfying the deficiency, and describes why such changes were judged to be inadequate.

The MNS identifies known systems or programs addressing similar needs that are deployed or are in development or production. It indicates potential areas of study for concept exploration and definition including the use of existing commercial systems or product improvements of existing systems.

As potential HSI difficulties are identified in existing systems, their validity and impact can be investigated and documented through the review of accident reports, near miss investigations, formal operator interviews and focus groups, HSI studies, etc. A deficiency or shortfall in existing mission capability can itself be the direct or indirect result of HSI problems. If severe enough, the HSI problem can require the development of a new system or the identification of a non-acquisition solution.

Alternatively, HSI problems can contribute to the inability of a system to adequately fulfill its mission. For instance, a system which requires human performance at (or beyond) known limits invites errors. To the extent that such errors are critical to mission accomplishment, the system is deficient. The HSI practitioner can identify such deficiencies or shortfalls in existing systems and provide updates to the "Identify User Needs" activity.

Since the practitioner should also be generally aware of developing human-system interface technologies, he or she should be able to identify such technologies which are maturing to the point that they constitute a potential opportunity for performing a mission more effectively or economically. A perceived need, once authenticated by mission needs analysis, will preferentially be resolved through non-material means. The HSI practitioner can provide input to this process, based on appropriate analyses:

function analysis
task analysis
workload analysis
link analysis
training requirements analysis

The outcome of such analyses can lead to HSI recommendations for non-material solutions to the authenticated need. Such solutions might involve:

personnel requirements change (e.g., increased skills/aptitudes, increased staffing)
training change (e.g., modified curriculum, modified training technique)
procedural change (e.g., re-requirements documentering of tasks, re-assignment of tasks)
software-based human-computer interface change (e.g., screen redesign)

Relationship to the System Acquisition Process: The MNS is the major document investigating user needs

Inputs: System requirements, and existing systems

Outputs: Inputs to the MNS

Substeps/Activities/Guidelines:

0.7.1 identify HSI deficiencies with the baseline system.

A perceived need or deficiency is submitted and reviewed during Phase 0. Results of the Mission Area Analysis, including training, are discussed. Key boundary conditions related to infrastructure support that may impact on satisfying the need, including MPT constraints, operational environments, and level of desired mission capability are discussed.

0.7.2 investigate the resolution of HSI deficiencies through nonmateriel solutions, including changes in doctrine, concepts, tactics, organization, or training.

0.7.3 for a materiel solution, identify HSI operational constraints.

A mission need may be to establish a new operational capability or to improve an existing capability . It may also reflect a desire to exploit an opportunity that will result in significantly reduced ownership costs or improve the effectiveness of existing materiel.

0.7.4 Provide HSI inputs to the MNS

Mission needs must first be evaluated to determine if they can be satisfied by nonmateriel solutions. Nonmateriel solutions include changes in doctrine, operational concepts, tactics, training, or organization. When a need cannot be met by such changes, a broad statement of mission need -- expressed in terms of an operational capability not a system-specific solution -- is identified in a Mission Need Statement. The mission need should be prioritized relative to other documented needs.
The Mission Need Statement also identifies the threat to be countered and the projected threat environment.
The Mission Need Statement discusses the results of the mission area analysis, Identifies any changes in U.S. or Allied doctrine, operational concepts, tactics, organization, and training that were considered in the context of satisfying the deficiency. It describes why such changes were judged to be inadequate.
The Mission Need Statement dentifies known systems or programs addressing similar needs that are deployed or are in development or production by any of the Services or Allied nations. It discuss the potential for inter-Service or Allied cooperation and it indicates potential areas of study for concept exploration/definition including the use of existing U.S. or Allied military or commercial systems or product improvements of existing systems.

Step 0.8. Evaluate the HSI Program at Milestone A

0.8.1 Conduct an assessment of the HSI Program

0.8.1.1 Is the HSI Program based on a thorough mission/function/requirements analysis?

0.8.1.2 Does the HSI Program address requirements for subcontractors and suppliers?

can HSI requirements can be enforced in the procurement of non-development items (NDI);

is there a specification approach for defining HSI requirements, including a functional specification describing what must be accomplished; a performance specification, defining the required level of performance; and a design specification describing how HSI requirements are to influence system design.

0.8.1.3 Is there an active HSI Joint Working Group?

0.8.1.4 Are there scheduled and pre-planned HSI Program Reviews?

is there identification of the issues and concerns to be addressed in the reviews;
are there methods and measures to demonstrate the status of the HSI program;
are there techniques to spotlight actual or expected problem areas and requirements for Government action;

0.8.1.5 Does the Program provide for identifying, analyzing, and correcting HSI Deficiencies?

are there specified requirements to validate an identified deficiency;
are there requirements to prioritize HSI deficiencies;
are there requirements to track individual deficiencies;
are there criteria for assessing the effectiveness of corrective actions.

0.8.1.6 Does the HSI Program provide for technical evaluations?

0.8.1.7 Does the HSI Program provide for formal studies and analyses?

are resources made available to conduct studies;
are HSI issues addressed in system engineering studies.

0.8.1.8 Does the HSI Program provide for the formal use of models and mockups

does the Program address mockup fidelity issues, including structural fidelity, functional fidelity, response fidelity, and personnel fidelity;
does the Program provide for the use of engineering mockups for HSI studies;
does the Program provide for the use of use of CAD as a supplement to physical mockups and models.

0.8.1.9 Are sufficient stable resources available for conducting the HSI Program as planned?

0.8.1.10 Are personnel assigned to the HSI program qualified in the individual HSI domains?

0.8.1.11 Is HSI Program planning adequate?

0.8.1.12 Are there factors which increase the risk of attaining the stated HSI objectives?

0.8.1.12 Are schedules realistic?

0.8.1.13 Are funding levels adequate?

0.8.1.14 Are interfaces with other elements of the system engineering program adequate?

0.8.2 Assess the HSI Inputs to the MNS

1) do HSI inputs to the MNS investigate the resolution of HSI deficiencies through nonmateriel solutions, including changes in doctrine, concepts, tactics, organization, or training?

2) do HSI inputs to the MNS for a materiel solution, identify HSI operational constraints?

3) do HSI inputs to the MNS address the need to exploit an opportunity that will result in significantly reduced ownership costs or improve the effectiveness of existing materiel, and productivity and safety of personnel?

4) Is the identification of HSI constraints as input to the MNS based on a review of human factors policies and constraints

5) Are HSI constraints based on design constraints affecting the role of the human

6) Are HSI constraints as input to the MNS based on a review of doctrine relevant to system/mission

7) Are HSI constraints as input to the MNS based on a review of problems and deficiencies identified in the baseline comparison system

8) Do HSI inputs to the MNS address requirements and constraints on number of operating personnel

9) Do HSI inputs to the MNS address requirements/constraints on number of maintenance personnel

10) Do HSI inputs to the MNS address requirements/constraints on personnel workloads

11) Do HSI inputs to the MNS address requirements/constraints on personnel workload distribution

12) Do HSI inputs to the MNS address requirements/constraints on personnel selection

13) Do HSI inputs to the MNS address requirements for reduced staffing

14) Do HSI inputs to the MNS address expected problems with staffing levels

15) Do HSI inputs to the MNS address expected problems with workloads

16) Do HSI inputs to the MNS address constraints on personnel complement composition

17) Do HSI inputs to the MNS address constraints on the role of the human in system operation

18) Do HSI inputs to the MNS address constraints on the role of the human in system monitoring

19) Do HSI inputs to the MNS address constraints on the role of humans in system maintenance

20) Do HSI inputs to the MNS address constraints on the role of humans in system support

21) Do HSI inputs to the MNS address requirements for automation

22) Do HSI inputs to the MNS address expected problems with function allocation

23) Do HSI inputs to the MNS address minimum skill level projection

24) Do HSI inputs to the MNS address training requirements

25) Do HSI inputs to the MNS address constraints on training overhead

26) Do HSI inputs to the MNS address directed training decisions

27) Do HSI inputs to the MNS address training effectiveness objectives

28) Do HSI inputs to the MNS address constraints on training equipment and facilities

29) Do HSI inputs to the MNS address requirements for special skills

30) Do HSI inputs address constraints on the training pipeline

31) Do HSI inputs address requirements for embedded training

32) Do HSI inputs address requirements for computer assisted instruction

33) Do HSI inputs to the MNS address expected problems with training and skills

34) Do HSI inputs address required levels of human performance

35) Do HSI inputs address requirements for sustained performance

36) Do HSI inputs to the MNS address human performance objectives

37) Do HSI inputs to the MNS address directed design decisions to support or which will impact human performance

38) Do HSI inputs to the MNS address system performance objectives which impact human performance

39) Do HSI inputs to the MNS address information availability and quality constraints on human performance

40) Do HSI inputs address time constraints on human performance

41) Do HSI inputs to the MNS address environmental constraints on human performance

42) Do HSI inputs to the MNS address system/equipment design constraints on human performance

43) Do HSI inputs to the MNS address software design constraints on human performance

44) Do HSI inputs to the MNS address procedural constraints on human performance

45) Do HSI inputs to the MNS address operational constraints on human performance

46) Do HSI inputs address team performance requirements

47) Do HSI inputs to the MNS address requirements for

performance monitoring/measurement

48) Do HSI inputs to the MNS address duration of operation impact on human performance

49) Do HSI inputs to the MNS address mean time to repair estimate effects on maintainer performance

50) Do HSI inputs address mean time to perform preventive maintenance

51) Do HSI inputs to the MNS address high driver missions, operations, tasks and conditions

52) Do HSI inputs to the MNS address expected hazardous conditions

53) Do HSI inputs to the MNS address directed design decisions concerning safety

54) Do HSI inputs to the MNS address system/equipment constraints on human safety and health

55) Do HSI inputs to the MNS address software constraints on human safety and health

56) Do HSI inputs to the MNS address procedural constraints on human safety and health

57) Do HSI inputs to the MNS address operational constraints on human safety and health

58) Do HSI inputs to the MNS address biomedical constraints

59) Do HSI inputs to the MNS address habitability constraints

60) Do HSI inputs address requirements for protective equipment

61) Do HSI address requirements for warnings and alarms

62) Do HSI inputs to the MNS address identified constraints/ issues

63) Do HSI inputs to the MNS address prioritize constraints and issues