DI-HFAC-80745C

Human Engineering Systems Analysis Report

The Human Engineering Systems Analysis Report describes human engineering efforts conducted during system analysis and provides data used to evaluate the appropriateness and feasibility of system functions and roles allocated to personnel.

Approval DateDecember 16, 2015

AMSC Number9614

Preparing ActivityAM

Project NumberHFAC-2015-020

OPR—

DTIC ApplicableNo

GIDEP ApplicableNo

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

DI-HFAC-80745B

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Human Engineering Systems Analysis Report (HESAR) describes the human engineering efforts conducted as part of the system analysis and provides data resulting from that analysis. The data are used by the procuring activity to evaluate the appropriateness and feasibility of system functions and roles allocated to operators, maintainers, and support personnel.

a. This data item description (DID) contains format and content preparation instructions for the data delivered resulting from the work task(s) delineated in the contract statement of work (SOW).

b. The DID supersedes DI-HFAC-80745B.

Preparation Instructions

1Format.The HESAR format shall be contractor selected. Unless effective presentation would be degraded, the initial format shall be used for all subsequent submissions. Revisions shall be indicated in a manner consistent with standard editorial practices.

2Content.The HESAR shall contain the following information. For any section below whose content is substantially covered in another document (e.g., system architecture documentation, concept of operations, system design analyses), the contractor has the option to provide the required content in the HESAR, or to provide a summary of the content and reference or link to the document section(s) that contain(s) the content.

2.1Systems objective(s).The system objective(s) shall be described. If the objective(s) are to be met by the system operating in conjunction with other systems not within the scope of the contract, the following shall also be described:

2.1.1The overall (or higher level) objective(s) to be met through the combined operation of systems.

2.1.2The sub-objective(s) to be met by the system being developed under the contract.

2.1.3Interactions required between systems to meet the overall objective(s).

2.2System mission(s).The system mission(s) shall be described. The mission description(s) shall describe the operational and physical environmental context(s) within which the system will meet its objective(s) (e.g., fixed installation versus mobile system operations, geography, mission time constraints, weather, day/night, humidity, terrain, vegetation density, enemy force concentration, enemy weapons and countermeasures capabilities, enemy order of battle, presence or absence of other cooperating systems).

2.2.1The organizational structure of the system and required communication with other operators or support personnel shall be described.This may include the various system or operational modes and associated environments.

2.2.2For legacy systems, any changes between the current and future mission environment shall be identified and described.

2.2.3Any special requirements or considerations due to environmental factors or equipment (i.e., arctic mittens; chemical, biological, radiological, nuclear, and explosive [CBRNE] protective clothing; radios) shall be identified.

2.3Scenarios.The system scenarios shall be identified as follows:

2.3.1Mission use scenarios.Mission scenarios shall be provided that describe the high-level system functionality. The mission capabilities shall be expressed as end to end threads. Each thread shall include all system components that contribute to the execution of the operation described.

2.3.2Operational use scenarios.Operational use scenarios shall be provided that describe the individual operations that are used to fulfill the mission scenarios, either individually or in sequence to complete the mission scenarios. The operational use scenarios shall be representative of actual system use. The operational use scenarios shall describe the sequence of actions taken by the operator and performed by the system for different system operations, and may include high-level scenarios as well.

2.4System functions.The system functions that must be performed to meet the system objective(s) within the mission context(s) shall be described.

2.5Allocation of system functions.The allocation of system functions shall be described and shall specifically address:

2.5.1Information flow and processing.

2.5.2Estimates of potential operator, maintainer, and support personnel requirements.

2.5.3Allocation of functions to the system and to the human.

2.6Equipment identification.The selected design configuration shall be described. Hardware and software component descriptions, including remote or external elements, shall be provided.

2.7Subsystems.Any subsystems defined during the system analysis and design process shall be identified.

2.8Internal interfaces.The interfaces between internal system elements shall be described.

2.9External interfaces.The interfaces to external elements shall be described.

2.10Personnel elements.The personnel required to operate, maintain, and support the system shall be identified.

2.10.1Personnel descriptions.The numbers and types of operators, maintainers, and support personnel of the system shall be identified. This shall include the minimum number of personnel required to operate, maintain, and support the system during any given shift.

2.10.1.1Any special requirements that personnel must possess shall be identified (e.g., must have 20/20 vision or cannot be colorblind).

2.10.1.2Any assumptions made about the system or the personnel that influence the design of the system shall be identified.

2.10.1.3Any derived requirements that are a result of analysis that influence design decisions or that are critical to system performance shall be identified.

2.10.1.4An estimate (in percent) of the target population, by gender, that the system design will accommodate shall be provided.

2.10.1.5Any special strength requirements that personnel must possess shall be identified.

2.10.2Roles.The specific roles in the system (e.g., supervisor, operator, maintenance technician) shall be identified.

2.10.2.1The specific function(s) performed for each role shall be identified.

2.10.2.2Any assumptions made about the personnel roles that affect or influence design decisions shall be identified.

2.10.2.3Any assumptions made about the roles or the ability of personnel to fulfill these roles shall be identified.

2.10.3Profiles and skills.The personnel who will fulfill the system roles, including prerequisites such as rank and years of experience, shall be identified and described.

2.10.3.1The required skill sets of the system personnel (e.g., education, reading level, technical prerequisites, and occupational specialties) shall be identified.

2.10.3.2Any assumptions made about the system personnel shall be identified.

2.11Operational procedures.

2.11.1Setup.Any required setup operations shall be described.

2.11.2Startup.System startup operations shall be described.

2.11.3Normal operations.Operations under normal working conditions shall be described.

2.11.4Failure modes.Operations when failure conditions occur shall be described.

2.11.5Emergencies.Operations under emergency situations shall be described.

2.11.6Shutdown.System shutdown operations shall be described.

2.12Support.A description of the system support shall be provided.

2.12.1Provisioning.The provisioning requirements and operations to fulfill those requirements shall be listed.

2.12.2Maintenance.The maintenance requirements and operations that need to be performed on the system shall be listed.

2.12.2.1Any special maintenance needs, tools, or equipment shall be identified.

2.12.2.2All assumptions regarding who will complete the maintenance and where the maintenance will be performed shall be provided.

2.12.2.3If there is a legacy system, any changes in maintenance requirements between the legacy system and the system being developed shall be described.

2.12.3Training.Any training that needs to be developed to educate personnel on the use, operation, and maintenance of the system shall be described.

2.12.3.1The training type, duration, and format shall be identified.

2.12.3.2Any additional training, specialized training, or prerequisites shall be identified.

2.12.3.3If there is a legacy system, any changes in training requirements between the legacy system and the system being developed shall be described.

2.12.4Deployment.Where the system is to be deployed and in what configuration shall be identified.

2.12.5Upgrade methodology.The process for upgrading the system hardware and/or software over the lifecycle of the program shall be described.

2.13Security.A description of the physical and information security requirements of the system shall be provided. This description shall include the security requirements for the operational and non-operational environment (e.g., trusted systems, multi-level security schemes, or multi-tiered physical security levels).

2.13.1The concepts for addressing the security issues in the system shall be identified.

2.13.2For each of the scenarios identified in 2.c, a description of where security requirements are addressed and met (e.g., when log-on and passwords are required and performed) shall be provided.

References

—

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer