Air Force Institute of Technology

AFIT Scholar

Faculty Publications

9-2017

Human-Centered Design Using System Modeling Language

Michael E. Watson
Air Force Institute of Technology

Christina F. Rusnock
Air Force Institute of Technology

John M. Colombi
Air Force Institute of Technology

Michael E. Miller
Air Force Institute of Technology

Follow this and additional works at: [Link]

Part of the Systems Engineering Commons

Recommended Citation
Watson, M. E., Rusnock, C. F., Colombi, J. M., & Miller, M. E. (2017). Human-Centered Design Using System
Modeling Language. Journal of Cognitive Engineering and Decision Making, 11(3), 252–269.
[Link]

This Article is brought to you for free and open access by AFIT Scholar. It has been accepted for inclusion in
Faculty Publications by an authorized administrator of AFIT Scholar. For more information, please contact
[Link]@[Link].
705255
2017
EDMXXX10.1177/1555343417705255Journal of Cognitive Engineering and Decision MakingHuman-Centered Design Using System Modeling Language

Human-Centered Design Using System Modeling

Language
Michael E. Watson, Christina F. Rusnock, John M. Colombi, and
Michael E. Miller, Air Force Institute of Technology

The human user is important to consider during will be using them (Semsei Greenhouse, 2012).
system design. However, common system design mod- HCD builds on and extends the framework
els, such as the system modeling language, typically rep- established by user-centered design, which
resent human users and operators as external actors, focuses on the human’s goals, preferences, tools
rather than as internal to the system. This research
needed, and tasks performed, to ensure that the
presents a method for integrating human consider-
ations into system models through human-centered
end system will be best suited for what the user
design. A specific system is selected to serve as the case needs (Norman & Draper, 1986). HCD extends
study for demonstrating the methodology. The sample user-centered design by considering not just
system is analyzed to identify the task and information the end user but all of the humans who may
flow. Then, both system- and human-centered diagrams interact with or be affected by the system. HCD
are separately created to represent different view- involves applying human factors, ergonomics,
points of the [Link] diagrams are compared and and usability heuristics to the system design
analyzed, and new diagrams are created that incorpo- process. Thus, HCD is a process that is system
rate both system and human considerations into one design oriented (vs. user feedback oriented) and
concordant representation of the system model. These is capable of being applied early in the design
new views allow systems engineers and human factors
process, before there is even a system that could
engineers to effectively communicate the role of the
user during early system design trades.
enable user feedback. HCD is particularly rel-
evant for systems with stakeholders, in addition
Keywords: human systems integration, design meth- to the end user (e.g., maintainers, supervisors,
ods, system dynamic analysis, robotics, military, com- supported users, system administrators), who
mand and control interact with the system and for systems where
adoption and acceptance are based on mission
Introduction needs (e.g., military systems, industrial process
Human-centered design (HCD) holds the control systems, corporate financial manage-
promise of creating system designs that are ment systems) rather than user preferences.
more usable, efficient, and productive. HCD is a Great strides have been achieved in imple-
design process that focuses on creating designs menting HCD in consumer product develop-
based on information about the people who ment; however, it has been much more challeng-
ing to incorporate HCD into large-scale develop-
ment governed by the systems engineering (SE)
Address correspondence to Christina F. Rusnock, Department
process. SE approaches design and development
of Systems Engineering and Management, Air Force Institute by focusing on the complete system and decon-
of Technology, 2950 Hobson Way, Building 640, WPAFB, structing it into its multiple components (Interna-
OH 45433-7765, [Link]@[Link]. tional Council on Systems Engineering, 2015).
Author(s) Note: The author(s) of this article are U.S.
During design, the SE process largely focuses on
government employees and created the article within the the technical system, often viewing the human as
scope of their employment. As a work of the U.S. federal an external actor. However, a true systems
government, the content of the article is in the public domain. approach would recognize that the human is a
Journal of Cognitive Engineering and Decision Making vital part of many systems and that the human
2017, Volume 11, Number 3, September 2017, pp. 252­–269 plays an integral role in determining overall sys-
DOI: 10.1177/1555343417705255 tem performance and degree of mission success.
Human-Centered Design Using System Modeling Language 253

The design of the National Aeronautics and achieve an objective. Methods support processes
Space Administration’s crew exploration vehicle by defining in greater detail how to accomplish
Orion provides an example of the need to con- those activities. Tools are the enabling mecha-
sider the human as an internal component of the nisms that facilitate and enhance the implemen-
system. Not only did the engineering design team tation of a given method (Martin, 1996). There
need to be concerned with the crew’s safety, mis- may be more than one tool capable of support-
sion tasks, and human needs, but the presence of ing a particular method; likewise, there could
the crew also had a direct impact on subsystem be multiple methods capable of supporting a
requirements. For example, the total system’s process. For example, as part of an overall SE
(including the crew’s) mass directly affected the process for architectural and logic design activi-
launch vehicle requirements. Launch vehicle ties, a growing method is the object-oriented
limitations encouraged lower mass and volume systems engineering methodology that defines
requirements, whereas the ability for the human a sequenced set of activities for operational and
crew to perform their duties encouraged larger system design. This method is implemented
volume requirements—thus creating a trade-off with SysML, which is implemented in a soft-
between human performance and volume, both ware-based design tool.
of which have impacts for overall system and
mission performance (Morin et al., 2008). SE Process, Methods, and Tools
One approach to increase the visibility of SE is a process that has become an increas-
human considerations during system design is to ingly important part of the overall life cycle
fold the HCD process into the SE process rather management of Department of Defense (DoD)
than performing the HCD process separately systems, to the point of becoming an institution-
from the SE design process. This paper seeks to alized disciplinary approach to the development
demonstrate a method for incorporating human of defense acquisition programs (DoD, 2015).
capabilities and needs into system designs, by To support this consideration throughout the life
focusing on accounting for the human within cycle, the SE process is composed of 22 techni-
system modeling products using the system cal and technical management subprocesses,
modeling language (SysML), a graphical lan- ranging from stakeholder needs and require-
guage that provides a means of communicating ments definition to architecture definition, inte-
and visualizing system design information. In gration, verification, and disposal (International
SysML, the human is typically represented as an Council on Systems Engineering, 2015).
external actor rather than as an internal compo- Traditionally, SE has been implemented
nent of the system (Delligatti, 2014). By folding through a document-based method where design
HCD into traditional SE products, human fac- is driven by the development of a set of docu-
tors engineers gain a way to incorporate the ments, such as requirements or design specifica-
human and HCD practices into the SE process, tions. This document-based approach has begun
and systems engineers gain a way to incorporate to be replaced by a model-driven approach:
critical human considerations into their existing model-based SE (MBSE). MBSE allows for the
SE framework, thus improving communication development of the same information through a
between design disciplines during system design series of tightly integrated and interrelated mod-
and ideally improving system design. els that form a complete system model (Frieden-
thal, Moore, & Steiner, 2014). The MBSE
method results in improved team communica-
Background
tion, increased quality of the system’s specifica-
Processes, Methods, and Tools tion and design, and the ability to reuse the
Human-centered considerations can be model throughout the system’s life cycle (Frie-
embedded into SE practices at the process, denthal et al., 2014).
method, or tool level. For the purposes of this If MBSE is a method of practicing SE, then
paper, a process is defined as the set and order SysML can be considered a tool with which to
of what activities should be accomplished to implement MBSE. There have been many
254 September 2017 - Journal of Cognitive Engineering and Decision Making

Figure 1. System modeling language (SysML) diagram taxonomy (adapted from Delligatti, 2014).

graphical modeling languages available for SE as the “process by which to design and develop
applications over the years, and SysML is just systems that effectively and affordably integrate
one of the latest (Delligatti, 2014). Others human capabilities and limitations.” HSI is the
include the Integrated Definition family, func- process of integrating—and making trade-offs
tional flow block diagrams, UML (Unified of—human considerations across nine domains:
Modeling Language), and data flow diagrams. HFE, manpower, personnel, training, surviv-
SysML (an extension of UML) is a graphical ability, habitability, environment, safety, and
language that provides a means of communicat- occupational health.
ing and visualizing system design information There are various methods of practicing HFE—
via a selection of nine uniquely purposed dia- many of which have aspects that easily relate to
grams. These diagrams are composed of a stan- and align with SE methods—including mission
dardized set of precise, unambiguous graphical and scenario analysis, function analysis, function
notations, enabling the modeler to communicate allocation, and task analysis. Although it is useful
requirements and behavioral, functional, and for human factors engineers to use their own set of
structural aspects of the system. Figure 1 dis- tools that support these HFE methods, maintain-
plays the diagram types and their relationships ing a separate set of design products provides
to one another. SysML provides a language to a potential barrier to team communication.
describe a system; however, it does not provide HFEs can build on their knowledge of domain-
a modeling methodology (Delligatti, 2014). specific tools, such as timelines, function flow
diagrams, and operational sequence diagrams
Human Systems Integration (NATO Defence Research Group Panel 8,
The human should be a critical consideration 1999), to aid in communication of human-centric
during system development and the SE process needs, requirements, and limitations.
in general. The U.S. Air Force seeks to extend There have been several efforts to better inte-
human considerations beyond human factors grate human systems considerations into the SE
(designing products, systems, and processes to process. These efforts strive to solve the prob-
account for the human and the interaction of lem by focusing on the issue at varying levels of
these products, systems, and processes with the scope: the process level, the methods level, and
human) by establishing a process to trade off all the tools level.
aspects that involve humans, from traditional
human factors engineering (HFE) to broader Process-Level Integration
considerations beyond the system design, such Integration efforts at the process level strive
as manpower and training. The U.S. Air Force to fundamentally change or augment the SE
(2010) defines human systems integration (HSI) and/or HSI process. Chua and Feigh (2011)
Human-Centered Design Using System Modeling Language 255

offer various ways in which human factors may Although these process-level integration efforts
be generally included in early system develop- take strides toward increased communication and
ment. They organize their ideas according to merging of HFE and SE, they do not guarantee—
four system design stages: requirements acqui- or even provide a mechanism—to directly incor-
sition, concept generation, preliminary, and porate HCD considerations into SE products.
detailed design. Chua and Feigh provide, admit-
tedly at a high level of detail, general sugges- Methods-Level Integration
tions in an effort to encourage communication Efforts at the methods level strive to enhance
between systems engineers and human factors integration of SE and HFE by seeking to
engineers and to promote awareness of human improve one of the existing SE design or analy-
factors during system design. sis methods or proposing a new method. Crisp,
Hardman and Colombi (2012) extend the Hoang, Karangelen, and Britton (2000) do the
idea of augmenting the SE process by highlight- latter. Continuing the ideas put forth by Hard-
ing the necessity for quantitative methods of man et al. (2008), Orellana and Madni (2014),
expressing HSI requirements, permitting these and Bruseberg (2008), once a common language
requirements to be properly considered by pro- between SE and HFE is established, Crisp et al.
gram management during system development. (2000) propose a way to further establish effec-
As such, these authors outline areas in which to tive integration through an integrated informa-
emphasize HSI throughout early requirements tion data repository featuring a common data
analysis, function allocation, and design, further interchange format. This repository responds to
suggesting the usage of empirical data, such as the need for systems engineers to synchronize
safety investigations and human-subjects exper- and balance multiple disciplines, providing a
iments, to minimize subjectivity. software interchange and physical exchange
Another process-level idea is to standardize standard that could implement a common data
the terminology between SE and HSI practitio- schema to translate information among disci-
ners. Hardman, Colombi, Jacques, and Miller plines’ unique software tools.
(2008) suggest clarifications to terminology Hardman et al. (2008) and Piaszczyk (2011)
used across the DoD to reduce inconsistencies propose an augmentation to the DoDAF to
among numerous DoD, SE, and human factors improve integration. They examine how each of
and HSI publications: the DoD architecture the nine HSI domains are related to the existing
framework (DoDAF; DoD, 2009), the defense 51 DoDAF views for capturing design informa-
acquisition guide (DoD, 2013), and the Interna- tion. For example, since the manpower domains
tional Council on Systems Engineering’s (2015) deal with the numbers of users, operators, and
SE handbook. The idea of standardization may maintainers, this design information could be
be extended from the DoD to the entire SE com- captured by DoDAF’s operational views to iden-
munity (Madni, 2009; Orellana & Madni, 2014). tify and describe performers, organizations, or
Orellana and Madni (2014) argue that there is a organizational types. HFE is a key domain to
lack of HSI efforts because of differences in ter- address system limitations as a result of human
minology. A proposed solution is to build a com- involvement and human system interaction.
mon ontology to connect the semantics of the Several DoDAF views could be used to identify
two fields, thus providing a means to address risk areas or trade-off opportunities, especially
HSI concerns during system design (Madni, across the human-computer interface, such as
2009; Orellana & Madni, 2014). Bruseberg the systems interface description (SV-1), sys-
(2008) corroborates Orellana and Madni’s claim, tems-systems matrix (SV-3), and the systems
citing several examples of differences between functionality description (SV-4). The methods
HSI and SE in their interpretations of terminol- proposed by Hardman et al. (2008) and Piaszc-
ogy. For instance, whereas the term activity has zyk (2011) present ways to include HSI in the
a high-level operational connotation to systems DoDAF without developing new products.
engineers, its scope is often of a low-level human An alternative integration method is to create
task to human factors engineers. new, human-focused views to augment existing
256 September 2017 - Journal of Cognitive Engineering and Decision Making

architecture frameworks. In 2007, representa- side of system development, thus bridging the
tives from the United States, United Kingdom, communication gap between systems engineers
Canada, and the Netherlands convened the and human factors engineers. The MODAF
North Atlantic Treaty Organization (NATO) human view is composed of seven products,
Human View Panel to examine the current state HV-A through HV-G. These products largely
of human modeling descriptions. They proposed parallel the NATO human view’s eight products.
a standard human viewpoint that could be Another goal of adding a human view directly
adopted by any architecture framework (Hand- into an architecture framework is to enable sys-
ley & Smillie, 2008). The resultant NATO tems engineers and HSI analysts to collaborate
human viewpoint is composed of eight products: early in system development, thus contributing
more effectively to design (Smillie & Handley,
HV-A: Concept 2009). Several applications of human views
HV-B: Constraints have been described by Handley (2011), Hand-
HV-C: Tasks ley and Knapp (2014), and Sharples (2014).
HV-D: Roles However, by creating separate views, these
HV-E: Human network efforts fail to ensure that the system-centric
HV-F: Training views will account for the human. Although
HV-G: Metrics these methods provide a means of capturing
HV-H: Human dynamics human-centered considerations in the system
architecture, they do not ensure that human-cen-
All these products are designed to address tered considerations will continue to be captured
different human aspects that are important to in the system preliminary or detailed design.
consider during system design and develop-
ment. For example, HV-A (concept) offers Tools-Level Integration
a high-level look at the human component The most in-depth, narrowly scoped way
of the system, whereas HV-B (constraints) to integrate the HSI and SE processes is to
focuses on capabilities and limitations that the approach integration at a tools level. Efforts at
human brings that affect the system. HV-B can this level focus on improving the way in which
be further subdivided into subviews, such as tools such as SysML can be used to incorporate
manpower projection constraints and personnel the human into SE. Although some researchers
policy constraints. Since most of these views advocate the use of modeling and simulation in
are static by nature, HV-H (human dynamics) general to consider HSI (Boy & Narkevicius,
is designed to address the dynamic aspects 2013), other efforts have used MBSE modeling
from each of the other views, to include state to accomplish this task. Bodenhamer (2012)
changes, conditions, time units, and perfor- provides an excellent start for including human
mance measures. The human view was intended considerations into system-level products, such
to force systems architects to consider the as those developed with SysML. Bodenhamer
human in its own architecture framework view states that to understand the human’s interac-
instead of arbitrarily adding human consider- tion with the system, the human must first be
ations into other views. Interestingly, at about deconstructed into the functional components
the same time, Bruseberg (2008) proposed a necessary to operate the system. These compo-
human view specifically for the British Ministry nents include sensory channels, cognitive pro-
of Defence architecture framework (MODAF). cessing, psychomotor capabilities, and physical
Listing several of the same human-related short- interfaces. The system itself must also be decon-
comings in the MODAF, as does Handley and structed into its components, treating the user
Knapp (2014) for the DoDAF, Bruseberg details as one of these components. Using a landmine
ways in which her human view can improve the detector system as a case study, Bodenhamer
MODAF’s representation of the human during created a high-level architectural concept of the
system development. She argues that human system to demonstrate this concept. He modeled
views aid in modeling the “soft systems” human the behavioral aspects of the system by creating
Human-Centered Design Using System Modeling Language 257

activity and sequence diagrams. Demonstrating where decisions have identifiable and measur-
that the original products consider the human able implications for human-system interac-
as an outside actor, Bodenhamer updates the tion. Additionally, most efforts have focused
diagrams to include the human as internal inter- on integration at only the early conceptual or
faces to the system. These diagrams are thus architectural phase of a system’s life cycle. Dur-
able to visually highlight the human-system ing these early phases, HCD is largely focused
interaction that is necessary for mission suc- on requirements specification. Few integration
cess. By doing so, Bodenhamer claims that the efforts have focused on the preliminary and
modeler can identify HSI-related problems that detailed design phases, where in-depth analysis
could affect system performance or mission of human capabilities and limitations through
success. modeling or usability studies is most likely to
Ramos, Ferreira, and Barcelo (2013) address occur.
human integration from the process, methods, The purpose of this paper is to present a dif-
and tools levels. As part of their larger effort to ferent integration approach by focusing on the
enhance the overall SE process, they amalgam- tools level used during the preliminary or
ate aspects from a variety of methodologies to detailed design phases, later in the system’s life
present a revised, more agile MBSE methodol- cycle. Ideally, this approach should be used in
ogy. However, their main focus is at the tools combination with the other integration efforts so
level. HSI is considered a part of the overall that the human is considered at each phase. By
methodology, in which Ramos et al. advocate a focusing on integration at the tools level during
systems engineer-focused implementation of these design phases, the resulting system models
HSI via SysML diagrams such as activity and allow for human consideration at a lower level
internal block diagrams. of system detail. Figure 2 shows that this paper’s
Orellana and Madni (2014) also address inte- research lies in the preliminary design and
gration from multiple levels of scope. After pro- detailed design stages of the SE Vee model, in
posing their process-level HSI ontology, they contrast to other integration efforts from the lit-
narrow to the tools level. Orellana and Madni’s erature, which have been primarily focused on
ontology is influenced by defining the human in conceptual design.
terms of SysML diagrams. The goal of the ontol- This paper examines human and system con-
ogy is to “bridge the gap” between systems engi- siderations through SysML. These diagrams are
neers and human factors engineers by allowing sequentially built embracing concepts from both
systems engineers to define the human using SE and HFE. The premise is that by incorporat-
their own MBSE modeling methods. Orellana ing HCD directly into SE products—with
and Madni provide a high-level description of SysML and/or any integrated analysis tools—
ways in which the human can generally be rep- systems and human factors engineers will be
resented through SysML diagrams. Ahram and able to better identify, communicate, and correct
Karwowski (2009) also recommend a common design issues or invalid assumptions, thus
language by incorporating a HSI framework into improving system design.
systems engineers’ SysML modeling practices.
Methodology
Research Gap The methodology of incorporating HCD
There have been several efforts to integrate directly into SE products can serve a number of
the HSI and SE processes. These efforts have purposes, including system evaluation, system
addressed the integration problem from various redesign, and system documentation. The first
standpoints: the process level, methods level, step in the methodology is selecting a specific
and tools level. Numerous processes and meth- system and purpose for integrating HCD into
ods have been proposed, but relatively few the SE products. Next, the sample system is ana-
efforts integrate SE and HSI at the tools level. lyzed to identify the task and information flow.
The tools level is where a number of specific Then, system- and human-centered diagrams
design decisions are made; thus, this is the level are separately created to represent different
258 September 2017 - Journal of Cognitive Engineering and Decision Making

Figure 2. Integration efforts in the Vee process model (adapted from Forsberg, Mooz, & Cotterman, 2005).

viewpoints of the system. These diagrams are allows for results to be more easily generalized
compared and analyzed, and new diagrams are to other systems.
created that incorporate system and human con- Using Vigilant Spirit, the pilot performs a
siderations into one concordant representation surveillance mission attempting to locate and
of the system model. track a high-value target (HVT) who is walking
through an urban marketplace. The HVT is iden-
tified by the specific weapon (rifle) it is carry-
Case Study Description ing, but there are also distractors walking
This study uses a synthetic task environment throughout the market who are unarmed, armed
called Vigilant Spirit as the system case scenario with the incorrect weapon (pistol), or carrying
with which to demonstrate integration. Vigi- shovels. Participants are seated in a control sta-
lant Spirit is used by the U.S. Air Force, 711th tion that displays the simulated RPA camera
Human Performance Wing (HPW) at Wright- feed and a communications window. They use a
Patterson Air Force Base, Ohio, to conduct computer mouse to click within the camera feed
human-in-the-loop experiments studying the window to move the camera and recenter the
effects of certain tasks on participants’ perfor- RPA’s loiter circle, and they scroll the mouse
mance, workload, and physiology (Hoepf, Mid- wheel to zoom the camera in and out. Subjects
dendorf, Epling, & Galster, 2015). This system use a keyboard to indicate to the system when
is a research prototype that will be modified, they locate the HVT. Beside the primary task of
many times over, as new research investigations surveilling the HVT, there is also a secondary
are developed. Thus, this paper demonstrates communication task. Throughout the mission,
the creation of an “as is” baseline to support the operator is asked a series of math-based
future “to be” modifications. In particular, this route navigation questions through a headset. To
analysis focuses on how aspects relevant to answer the questions, the operator uses the key-
operator workload and human/system allocation board to open a communication line to orally
affect interface design, because these areas are respond via headset. Figure 3 shows the experi-
the focus of many research studies conducted mental setup for the Vigilant Spirit environment.
with Vigilant Spirit.
Vigilant Spirit was designed to simulate Develop Task and Information Flow
remotely piloted aircraft (RPA) missions, with a After the system to be analyzed is identified,
single operator controlling multiple RPAs. The the task and information flow are captured to
multiaircraft control mission contains many identify the relevant processes and activities, to
interesting human-system challenges (Colombi enable these elements to be accurately represented
et al., 2012). This synthetic task environment is in subsequent models. The mechanism for captur-
a suitable case study because the overall system ing the task and information flow will depend on
requires a combination of human and system the specific system’s design maturity. For exam-
activities. Vigilant Spirit is a relatively simple ple, if the system is in conceptual or preliminary
system, allowing the study to remain narrow in design, this step will be performed by analyzing
scope to focus on the methodology instead of the the functional architecture. However, if an “as
intricate details of a complex system. This scope is” system exists (or at least a prototype), then a
Human-Centered Design Using System Modeling Language 259

Figure 3. Vigilant Spirit experiment setup.

task analysis would be appropriate. Additionally, and with external entities, and what information
because the human is now inside the boundary of is passed back and forth therein. The task analy-
the system, identification of task and information sis’s identification of the system’s internal tasks
flows may include tasks required of the operator and processes is particularly useful for building
to perform the mission that are outside the bound- activity or sequence diagrams because the focus
ary of the system under design. of such diagrams is to represent the activities
This study’s task analysis of Vigilant Spirit is involved in performing a certain mission, with
accomplished through physical observation of varying levels of detail. Within this study’s
the simulation itself during an experimental dry human context, the most relevant diagrams will
run, as well as through analysis of the human be behavior and activity based.
subjects’ data collected by the 711th HPW. The
behavioral data set from the 711th HPW’s exper- Build Human-Centered Diagrams
iment is used to analyze the activities that the Building the human-centered diagrams is
subjects accomplished, the order that activities accomplished similarly to the system-centered
were performed, and tasks in which the subjects diagrams. Whereas the system-centered dia-
succeeded or failed. The analysis is used to build grams represent the system primarily from the
task networks as a way of visually representing systems engineer’s point of view, the human-
system and human tasks. centered diagrams instead represent that same
system from the unique perspective of the
Build System-Centered Diagrams human factors engineer. Building these human-
In some cases, the SysML diagrams may centered diagrams can be accomplished by
already exist. If not, the systems engineer will using an HCD approach—focusing on how the
need to build these diagrams. To build the human interacts with the other subsystems. The
SysML diagrams of the system, the neces- specific human-centered content that is captured
sary information must first be identified and in these diagrams will depend on the goals of
collected. The requisite information is dic- the current effort and those factors deemed to be
tated to some extent by the focus of the mod- most relevant by the human systems integrator.
eler, whether looking at structural, physical, or Examples of operator-based aspects to consider
behavioral aspects of the system. Regardless of for potential inclusion when developing these
focus, at a minimum the information collected diagrams include the following: workload, task-
will include identification of relevant subsys- load, attention availability or capacity, cogni-
tems, how they communicate with one another tive channels, physical limitations, physical or
260 September 2017 - Journal of Cognitive Engineering and Decision Making

ergonomic requirements, manpower, learning, and human factors engineers are seeking to iden-
errors, training, task flow, knowledge, skills, tify (1) unique information that needs to be cap-
abilities, and communication. tured in the integrated diagrams and (2) common
Although using HCD does not create require- anchor points that can be used to link this infor-
ments to include or exclude specific items from mation. The information that needs to be captured
any diagrams, each SysML diagram is tailored to in the integrated diagrams will depend on the spe-
convey specific information about the system; cific purpose for which these diagrams are being
thus, the selection of which diagrams are created generated. In general, the human factors engineer
with human-centered versions implicitly specifies should indicate the system design requirements
the type of data that will be included. For example, that have emerged from creating the human-cen-
sequence diagrams would require the specifica- tered diagrams. In this case example, the goal is
tion of interfaces and data flows between the to communicate with the engineering design team
human and other subsystems and the sequence of to support future redesign efforts; thus, the focus
those data flows, whereas activity diagrams will is on the system interface. Specifically, the con-
capture decision-making processes and decision cern is with how operator workload and cognitive
flows. Depending on the goals of the analysis, channels affect interface design; thus, the human
other items may need to be included in the dia- factors engineer needs to identify system require-
gram, which might require additional SysML dia- ments relating to these aspects. However, if we
grams suited to those aspects of the system. were focusing on a different aspect (e.g., train-
If possible, human factors engineers should ing), then different features would be retained for
interact directly with the end user or other stake- integration (e.g., information on tasks performed
holders, to define human consideration based on by the human operator).
how the system is experienced from the user’s per- To identify the common anchor points, the
spective. Through user feedback, aspects of the relevant diagrams from both the system’s and
human and its interaction with the system may be the human’s focus are examined for similar ele-
uncovered that would otherwise go unaccounted. ments. These common elements found in both
In the case of developing the Vigilant Spirit “as sets of diagrams may be used as common anchor
is” baseline, the purpose in creating the human- points with which to compare the system’s han-
centered diagrams is to effectively communicate dling of tasks versus that of the human. For
with engineering design team; thus, we focus on example, a single task may include both human
system interface and how the user communicates and system involvement; therefore, the task will
with the system. What interfaces are used to com- appear on each of the separate diagrams. This
municate with the system, and which of the user’s common task would serve as an anchor point,
senses are utilized to interact with those inter- connecting the separate human and system
faces? Cognitive processes are also analyzed with inputs that feed into that task. Since this case
respect to these interactions: the choices or deci- example is based on SysML activity and
sions that the user makes, how the interface design sequence diagrams, the anchor points can
affects the user’s workflow, and the user’s desired include any of the typical diagram elements:
workflow. The focus for these diagrams is on the
user’s interaction with the system. As part of the •• Tasks, functions, activities
HCD approach, the process of understanding and •• Data and information objects
modeling the system may involve a few iterations •• Interfaces—shown as an object or control pass-
of user or stakeholder interaction to get the dia- ing between subsystems, where each subsystem is
grams to a desired level of design maturity. indicated in a unique swim lane to improve inter-
pretability
Compare and Analyze the Differences
The generated system- and human-centered Create an Integrated Set of Diagrams
diagrams are qualitatively compared to iden- The key differences noted by comparing the
tify and analyze the differences between them. separate system- and human-centered diagrams
When comparing diagrams, systems engineers can be used to create new diagrams that integrate
Human-Centered Design Using System Modeling Language 261

the system and human perspectives. The infor- activities that it performs for the surveillance
mation that should be included in the integrated and communication tasks, each of which pre-
diagrams will depend on the specific goals of cipitates response activities from the human
the systems and human factors engineers. Any operator. For example, the system spawns a
system design requirements that have emerged random HVT at the beginning of each of four
from creating the human-centered diagrams iterations, for which the operator must search,
should be captured in the integrated diagrams. indicate if found, and then zoom in and follow.
The result of creating an integrated set of dia- The system also asks four iterations of com-
grams is a single set of depictions that account munications questions, prompting calculations
for both the system and the human—enabling and answers from the operator. A SysML activ-
the system designers to perform trade studies ity diagram was selected to represent these
that account for human-system interactions and tasks, as shown in Figure 4. Activity diagrams
human performance. Reiteration with the same are conducive to representing task flows dur-
HCD concepts as in the human-centered dia- ing early system design because they are able
grams may also be helpful with these integrated to visually depict mission activities at a high
diagrams to ensure that relevant human consid- level, allowing modelers to consider the actors
erations have been maintained. (vertical swim lanes), decisions, and task flows
involved.
Limitations and Assumptions The activity diagram in Figure 4 also offered
To apply the method described herein, sev- our first look at representing the system through
eral assumptions are made, including the estab- SysML diagrams. Its broad depiction of the sys-
lishment of initial performance and functional tem’s activities and interactions served as a basis
requirements, manpower requirements, alloca- with which to expand on and incorporate more
tion of functions to humans and systems, and details in new diagrams. Sequence diagrams
preliminary design. These aspects of the system were used for this purpose, as they are better
are necessary to effectively generate the sys- suited for illustration of subsystem activities and
tem- and human-centered SysML diagrams. intersystem communication.
These items need to exist in only their prelimi- The Vigilant Spirit system is composed of
nary form; it is quite possible that these initial two subsystems: surveillance and communica-
requirements, allocations, and designs may be tion. The surveillance and communication tasks
altered after the creation of the human-centered occur independently of each other from a system
diagrams and the incorporation of emergent standpoint and would likely use different hard-
requirements into the integrated diagrams. ware, which may be obtained in separate acqui-
One limitation of this method is that it con- sition programs in a real-world implementation.
siders only one design implementation at a time. Therefore, we divided the surveillance and com-
Thus, if the system and human factors engineers munication subsystems into their individual
are evaluating multiple design options, each of components, with separate sequence diagrams,
these design options will require its own itera- instead of representing them as one system.
tion. Another limitation is that this analysis is Doing so allows for a functional allocation of
qualitative/logical and not quantitative. How- who or what will be handling these different sys-
ever, the diagrams produced through this analy- tem aspects. The system-focused sequence dia-
sis can be used to inform quantitative analyses. grams of the surveillance and communication
tasks are shown in Figures 5 and 6, respectively.
These make use of a generalized model-view-
Results and Analysis controller software design pattern internally. In
The results of the “develop task and infor- the figures, the human is labeled an external
mation flows” step revealed three separate “actor.” This is the traditional software engi-
processes occurring during the simulation: neering method of representing the human as an
two system processes and one human pro- external (from system) entity with goals and
cess. The system has an independent set of roles.
262 September 2017 - Journal of Cognitive Engineering and Decision Making

Figure 4. Activity diagram of Vigilant Spirit tasks. HVT = high-value target.

In the surveillance diagram in Figure 5, the to the controller via the UI to move the RPA
system is divided into five abstract subcompo- camera and adjust the zoom level until the oper-
nents: the user interface (UI), controller, target, ator finds the HVT. By contrast, the activity dia-
distractors, and score. The use of a UI and con- gram in Figure 4 represents searching for the
troller is common when depicting software- HVT simply by a single action node. The com-
based systems. Note that even though these are munication diagram in Figure 6 is similarly
system-centered diagrams, the human is still focused, with the system divided into four sub-
represented to a degree. The operator, repre- components: the UI, controller, question bank,
sented by a single lifeline on the leftmost side of and score.
the diagram, interacts solely with the UI. The Because the sequence diagrams were built
controller manages the system’s activities and from a systems engineer’s perspective, less
timing, creates and manipulates objects (e.g., the emphasis is placed on the (external) user. These
HVT and distractors), and delegates tasks, such are now generated from a human factors engi-
as continuously updating the score until the mis- neer’s perspective. The construction of the
sion has ended. The sequence diagram generally human-centered diagrams can be the creation of
depicts the same task flow as the activity dia- completely separate diagrams or additions, dele-
gram but with more details of what data or infor- tions, or decompositions of the existing SE dia-
mation is consumed or generated with each task. grams. In this case, the objective is to detail the
For example, searching for the HVT consists modalities in which the user interacts with the
of the operator continuously sending commands system; thus, the diagrams are modified to con-
Human-Centered Design Using System Modeling Language 263

Figure 5. Sequence diagram of system-centered surveillance task. HVT = high-value target; UI = user interface.

Figure 6. Sequence diagram of system-centered communication task. UI = user interface.

264 September 2017 - Journal of Cognitive Engineering and Decision Making

vey this information by decomposing the human Because the medium with which the user and sys-
element. In the same manner that the system was tem communicate to each other is the UI, this
split into subcomponents, the user can be repre- served as the bridge to connect the two diagram
sented by several resources (Wickens, 2008), perspectives. The integrated diagrams are shown
where each performs specific tasks. For exam- in Figures 9 and 10, with the UI’s subcomponents
ple, listening tasks, such as hearing the commu- denoted as “UI.”
nication question, can be performed by only the Because the goal of creating the integrated set
human’s auditory system. Likewise, response of diagrams is to convey interface design infor-
tasks, such as indicating the HVT as found and mation to the engineering design team, incorpo-
answering the question, are performed by the rating the UI’s subcomponents into the inte-
human’s motor systems. Although Vigilant grated diagrams provides the systems engineer
Spirit is an existing system, if the system had not insight into human-system interaction without
yet been designed, the human factors engineer needing to include the human’s resources. Thus,
would have options for the implementation of the diagrams allow for the necessary amount of
certain tasks. For example, responding to the detail for a systems engineer’s area of interest in
communication question could occur orally a modeling language with which the engineer is
through headset or manually through keyboard. familiar. It is important that the human is consid-
These options could have implications not only ered and included in the system diagrams; its
for system design but for overall system perfor- resources are implied by the UI breakout and
mance. Note that the system-centric diagrams sufficiently represented therein.
focus on function allocation but do not account The benefit of creating these integrated dia-
for the level of design specification necessary grams is the ability to gain insight into the human
for human factors engineers to assess human processes and interfaces involved while the user is
performance implications. interacting with Vigilant Spirit. For instance, by
As these diagrams are purely human cen- depicting the user as being internal to the system
tered, less emphasis is placed on intersystem and by capturing the types of interfaces with which
events, and instead the system is abstracted to the user interacts and when the user must use them,
just focus on its interaction with the user. The the potential for imbalance of resource allocation
redesigned, human-centered sequence diagrams may be more easily identified. An example of an
are shown in Figures 7 and 8, in which the imbalance would be if the user were required to
human is divided into its visual, auditory, cogni- answer the question by typing the answer while
tive, and psychomotor components (denoted still needing to search for and indicate the HVT,
“human”), and the system’s UI is further divided thus requiring the use of the same keyboard and
into three subcomponents with which the user mouse interface for concurrent tasks. When the
interacts: the computer keyboard, mouse, and human is considered external to the system, these
monitor (denoted as “UI”). conflicting demands on the user’s limited capabili-
Having sets of diagrams from the system’s and ties—expecting the same user to accomplish two
human’s perspectives, we qualitatively compared tasks simultaneously—would not be apparent,
the diagrams to find similarities and differences. whereas they are easily realized when the human is
The system-centered sequence diagrams con- internal to the system. This benefit of identifying
tained detailed depictions of Vigilant Spirit’s sub- human capabilities and limitations comes without
systems and its intersystem communication while needing to sacrifice detailed models of Vigilant
treating the user as a “black box.” Conversely, the Spirit and its subsystems.
human-centered sequence diagrams focused on Another important aspect of MBSE is the
the human’s resources and interfaces with the sys- power to now integrate these early design defini-
tem while treating the system as a “black box.” tions (Figures 5–10) with analysis. SysML
However, each set of diagrams’ narrow focus is includes a parametric diagram. This is used to
also its unique strength, providing system and define and relate constraints, metrics, and design
human insights into Vigilant Spirit that demon- parameters of system components (i.e., blocks).
strate the benefit of creating an integrated set. Many tools allow these parameters to be simulated
Human-Centered Design Using System Modeling Language 265

Figure 7. Sequence diagram of human-centered surveillance task. HVT = high value target; Op = operator; UI
= user interface.

Figure 8. Sequence diagram of human-centered communication task. Op = operator; UI = user interface.

outside a descriptive design tool. This creates the •• importing those diagrams into a MBSE tool that
potential to experience the results of design deci- enables dynamic simulation of the models;
sions by •• assessing the effectiveness of select design param-
eters;
•• conceptually designing a human-system in •• conducting trade studies or sensitivity analysis by
SysML; adjusting those design parameters; and, finally,
266 September 2017 - Journal of Cognitive Engineering and Decision Making

Figure 9. Sequence diagram of integrated surveillance task. HVT = high-value target; UI = user interface.

•• optimizing the selected design parameters to ing HCD concepts provides advantages for sys-
achieve high performance. tem designs in other contexts. Systems engineers
understand the benefit of dividing the system
In our case example, potential upgrades to Vigi- into its subcomponents, functionally decompos-
lant Spirit include a number of system redesign ing system requirements, apportioning constraints
options that involve making trade-offs—for exam- and -ilities (reliability, availability, maintainabil-
ple, camera feed quality (resolution) versus video- ity), and balancing cost, schedule, risk, and per-
feed delay time or automated searching algorithms formance. Human-centered diagrams, based on
speed versus accuracy. These trade-offs, including SysML, represented the human’s visual, auditory,
the impact of human performance, could be simu- cognitive, and psychomotor subcomponents as
lated to select the parameters that would achieve resources and its use of system interfaces. By
the highest overall system performance. revising system diagrams to include the human,
systems engineers can gain insight into (1) the
Discussion and Conclusion possibility for the human to perform all or some
Aside from the specific Vigilant Spirit sce- of its allocated tasks; (2) the potential for conflicts,
nario, creating a set of SysML diagrams embrac- workload issues, and changing interface designs;
Human-Centered Design Using System Modeling Language 267

Figure 10. Sequence diagram of integrated communication task. UI = user interface.

and (3) the use of targeted autonomy. These con- To better integrate human considerations into
siderations are not necessarily accounted for by system designs, it is necessary for systems engi-
normal SE practices. neers to first acknowledge and consider the
Future work in this area of study will focus human as an important part of the system. How-
on further bolstering human considerations into ever, mere acknowledgment is not enough if the
SE processes with human performance model- human is not sufficiently integrated into the SE
ing. A discrete event simulation software tool, process. Similarly, human factors engineers
IMPRINT (Improved Performance Research need to be a part of the SE process to ensure suf-
Integration Tool), will be used to capture the ficient human integration. Integration needs to
dynamic aspects of the human’s cognitive per- be sufficiently scoped and at a level of detail that
formance. By using IMPRINT, it is possible to is able to capture the important aspects of the
analyze the interaction between the system and human (e.g., workload, taskload, attention avail-
human across a range of dynamic activities ability or capacity, cognitive channels, physical
occurring in the Vigilant Spirit environment. limitations, physical or ergonomic requirements,
Additionally, this proposed integration method manpower, learning, errors, training, task flow,
need not be limited to the specific MBSE and knowledge, skills, abilities, and communication)
HSI tools that this research used. There may be as well as implications for human-based system
other modeling tools besides SysML that would performance effects. At the tools level, SysML is
yield the same benefits from integrating human a language that enables the integration of human
considerations. Likewise, although this paper considerations into SE products, and this study’s
focused on the HFE domain to integrate, a future approach provides an avenue to achieve that
goal is to expand integration efforts across the goal. The details of this integration—with
rest of the nine HSI domains. respect to which diagrams to modify and what
268 September 2017 - Journal of Cognitive Engineering and Decision Making

human-specific information needs to be Friedenthal, S., Moore, A., & Steiner, R. (2014). A practical guide
to SysML: The systems modeling language (3rd ed). Waltham,
included—will ultimately depend on the spe- MA: Morgan Kaufmann OMG Press.
cific purpose for which the diagrams are being Handley, H. A. (2011). Incorporating the NATO human view in the
generated. Incorporating HCD early in the SE DoDAF 2.0 meta model. Systems Engineering, 15(1), 108–117.
process will allow for a reduction in total system Handley, H., & Knapp, B. (2014). Where are the people? The
human viewpoint approach for architecting and acquisition.
life cycle cost, while still achieving human-sys- Defense Acquisition Research Journal, 21(4), 852–874.
tem effectiveness—the mandate of HSI. Handley, H. A., & Smillie, R. J. (2008). Architecture framework
human view: The NATO approach. Systems Engineering,
Acknowledgments 11(2), 156–164.
Hardman, N., & Colombi, J. (2012). An empirical methodology
This work was supported in part by the Human for human integration in the SE technical processes. Systems
Research and Engineering Directorate, U.S. Army Engineering, 15(2), 172–190.
Hardman, N., Colombi, J., Jacques, D., & Miller, J. (2008). Human
Research Laboratory. The views expressed in this
systems integration within the DoD architecture framework. In
paper are those of the authors and do not reflect the IIE Annual Conference and Expo (pp. 840–845). Vancouver,
official policy or position of the U.S. Air Force, the Canada: IIE.
U.S. Army, the Department of Defense, or the U.S. Hoepf, M., Middendorf, M., Epling, S., & Galster, S. (2015). Phys-
iological indicators of workload in a remotely piloted aircraft
government.
simulation. In 18th International Symposium on Aviation Psy-
chology (pp. 428–433). Dayton, OH: Curran.
International Council on Systems Engineering. (2015). Systems
References engineering handbook. Hoboken, NJ: Wiley.
Ahram, T., & Karwowski, W. (2009). Human systems integration Madni, A. M. (2009). Integrating humans with software and sys-
modeling using systems modeling language. Proceedings of tems: Technical challenges and a research agenda. Systems
the Human Factors and Ergonomics Society Annual Meeting, Engineering, 13(3), 232–245.
53(24), 1849–1853. Martin, J. N. (1996). Systems engineering guidebook: A process for
Bodenhamer, A. (2012). Adaptations in the US Army MANPRINT developing systems and products. Boca Raton, FL: CRC Press.
process to utilize HSI-inclusive systems architectures. Proce- Morin, L., Whitmore, M., Laux, L., Hamblin, C., Stephens, J. P.,
dia Computer Science, 8, 249–254. Rajulu, S., . . .Fairey, L. (2008). The role of human engineer-
Boy, G. A., & Narkevicius, J. M. (2013). Unifying human centered ing in the design of the Orion spacecraft. Proceedings of the
design and systems engineering for human systems integra- Human Factors and Ergonomics Society Annual Meeting,
tion. In Proceedings of the Fourth International Conference 52(1), 26–30.
on Complex Systems Design and Management (pp. 151–162). NATO Defence Research Group Panel 8. (1999). Analysis tech-
Paris, France: Springer. niques for human-machine systems design. Wright-Patterson
Bruseberg, A. (2008). Human views for MODAF as a bridge AFB, OH: Crew Systems Ergonomics/Human Systems Tech-
between human factors integration and systems engineering. nology Information Analysis Center.
Journal of Cognitive Engineering and Decision Making, 2(3), Norman, D. A., & Draper, S. W. (1986). User centered system
220–248. design: New perspectives on human-computer interaction.
Chua, Z. K., & Feigh, K. M. (2011). Integrating human factors Hillsdale, NJ: Erlbaum.
principles into systems engineering. In Digital Avionics Sys- Orellana, D. W., & Madni, A. M. (2014). Human system integra-
tems Conference proceedings (pp. 6A11–6A111). Seattle, WA: tion ontology: Enhancing model based systems engineering to
IEEE. evaluate human-system performance. Procedia Computer Sci-
Colombi, J., Miller, M. E., Schneider, M., McGrogan, J., Long, D. ence, 28, 19–25.
S., & Plaga, J. (2012). Predictive mental workload modeling: Piaszczyk, C. (2011). Model based systems engineering with
Implications for system design. Journal of Systems Engineer- Department of Defense architectural framework. Systems
ing, 15(4), 448–460. Engineering, 14(3), 305–326.
Crisp, H. E., Hoang, N. T., Karangelen, N. T., & Britton, D. A. Ramos, A. L., Ferreira, J. V., & Barcelo, J. (2013). LITHE: An
(2000). An integrated tools environment for human centered agile methodology for human-centric model-based systems
design of complex systems. In Proceedings of SPIE—The engineering. IEEE Transactions on Systems, Man, and Cyber-
International Society for Optical Engineering (pp. 155–163). netics: Systems and Humans, 43(3), 504–521.
San Diego, CA: SPIE. Semsei Greenhouse, E. (2012). Human-centered design. Retrieved
Delligatti, L. (2014). SysML distilled: A brief guide to the systems from Livable New York Resources Manual: [Link]
modeling language. Upper Saddle River, NJ: Addison-Wesley. [Link]/LivableNY/ResourceManual/[Link]
Department of Defense. (2009). DoDAF V2.0, Vol 2: Architectural Sharples, R. A. (2014). Introduction of human views into opera-
data and models. Washington, DC: Author. tional capability development within an architectural
Department of Defense. (2013). Defense acquisition guidebook. framework. In IEEE International Systems Conference
Washington, DC: Author. (pp. 325–329). Ottawa, Canada: IEEE Computer Society.
Department of Defense. (2015). DoD instruction 5000.02: Operation Smillie, R., & Handley, H. (2009). Human-centered design focus in
of the defense acquisition system. Washington, DC: Author. systems engineering analysis: Human view methodology. In Pro-
Forsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing proj- ceedings of the International Conference on Contemporary Ergo-
ect management (3rd ed). Hoboken, NJ: Wiley. nomics (pp. 310–319). London, England: Taylor & Francis.
Human-Centered Design Using System Modeling Language 269

U.S. Air Force. (2010). Air force human systems integration hand- John M. Colombi is an associate professor of sys-
book. Washington, DC: Author.
tems engineering at the Air Force Institute of Tech-
Wickens, C. (2008). Multiple resources and metal workload.
Human Factors, 50(3), 479–487. nology. He received his PhD in 1996 and MSEE in
1992 from the Air Force Institute of Technology,
Michael E. Watson received a bachelor of science with a BSEE degree from the University of Lowell.
in aerospace engineering from The Pennsylvania He has 21 years of military experience as a develop-
State University in 2009. He recently graduated mental engineer. His research interests include sys-
with a master of science in systems engineering tems and enterprise architecture, complex adaptive
from the Air Force Institute of Technology in systems, acquisition process modeling, and human
2016, where his master’s research focused on systems integration. He is a member of the Interna-
human systems integration. Capt. Watson is cur- tional Council on Systems Engineering and IEEE.
rently a project engineer at the Space and Missile
Systems Center at Los Angeles Air Force Base, Michael E. Miller is an associate professor of human
California. systems integration at the Air Force Institute of
Technology. His research interests include human
Christina F. Rusnock is an assistant professor of sys- systems integration, modeling and measurement of
tems engineering at the Air Force Institute of Technol- human performance, and human interface design,
ogy. She earned her PhD in industrial engineering in particularly human-display integration. Prior to join-
2013, a MS degree in industrial engineering in 2011, a ing the Air Force Institute of Technology, Dr. Miller
MS degree in R&D management in 2008, and a BA in spent more than 15 years with Eastman Kodak Com-
economics-government in 2004. Her research interests pany as a systems and human factors engineer. He is
include human performance modeling, mental work- a member of the International Council on Systems
load, and situation awareness, with a focus on human- Engineering, Human Factors and Ergonomics Soci-
computer interaction. She is a member of the Institute ety, and a senior member of the Human Factors and
of Industrial Engineers and the Human Factors and Ergonomics Society, and a senior member of the
Ergonomics Society. Society for Information Display.