This article has been accepted for inclusion in a future issue of this journal.

Content is final as presented, with the exception of pagination.

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

Transitioning Systems Thinking to Model-Based

Systems Engineering: Systemigrams to
SysML Models
Robert Cloutier, Member, IEEE, Brian Sauser, Senior Member, IEEE, Mary Bone, and Andrew Taylor

AbstractA fundamental challenge for system engineers is to

capture a problem with an effective model or framework and
then facilitate transferring the information of that captured problem to practical systems engineering tools and methods. The
early problem definition phase requires an application of systems thinking with adequate modeling tools and methods. Then,
the later problem definition phase and early system architecting
phase requires transferring the captured problem to systems engineering tools and methods through emerging techniques such as
model-based systems engineering (MBSE) using SysML (MBSE
is the practice of using a modeling tools to capture systems
engineering diagrams). This paper presents a method for capturing a problem through systemigrams and the Boardman soft
systems methodology and then directly translating the systemigrams into SysML diagrams. With MBSE increasing in usage,
this method could provide a time savings opportunity during
model development along with the possibility of lowering information distortion or loss that can occur during transformation
of systems thinking to systems engineering activities. This paper
includes a case study which demonstrates how the proposed
approach was applied on a problem being considered by the
U.S. ArmyContingency Basing for Small Combat Units. Finally,
this paper will provide the conclusion on the development of
the method and describe future research directions that can
allow systems thinking and MBSE to function in a congruent
methodology.
Index TermsModel-based systems engineering (MBSE),
SysML, systemigram, systems thinking.

I. I NTRODUCTION
HIS paper aims to address two questions: 1) how
might system engineers better understand an unstructured problem and apply an effective model or framework
to the problem in order to better define it and 2) what is
the method for transferring this understanding to practical

Manuscript received June 6, 2014; accepted August 15, 2014. This work
was supported by the Systems Engineering Research Center (SERC). SERC
is a federally funded University Affiliated Research Center managed by the
Stevens Institute of Technology. This paper was recommended by Associate
Editor K. W. Hipel.
R. Cloutier is with the Stevens Institute of Technology, Hoboken,
NJ 07030-5991 USA.
B. Sauser is with the University of North Texas, Denton,
TX 76203-5017 USA (e-mail: brian.sauser@unt.edu).
M. Bone is with the Stevens Institute of Technology, Hoboken,
NJ 07030-5991 USA.
A. Taylor is with the U.S. Army Natick Soldier Research, Development,
and Engineering Center, Natick, MA 01760 USA.
Color versions of one or more of the figures in this paper are available
online at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TSMC.2014.2379657

Fig. 1. Capturing and modeling stakeholder concerns to enable portfolio

management.

systems engineering tools and methods even if systems engineers can effectively accomplish this problem definition? To
address these questions, this paper will describe the application of a systems thinking and problem definition methodology
(i.e., Boardmans soft systems methodology (BSSM) [1])
with emerging model-based systems engineering (MBSE)
practice to present a method for transitioning from problem to solution. This paper represents the first steps in a
longer-range vision as depicted in Fig. 1 that will allow for
capturing and modeling of stakeholder concerns to create
effective systems engineering artifacts in systems modeling
and concepts of operations (CONOPS) to enable portfolio
management. As an initial proof of concept, this paper focused
on the first two phases of Fig. 1systemigram [2] creation and system modeling. After describing the approach
taken in this paper, we will verify the approach with a case
study on development of contingency basing (CB) for Small
Combat Units (SCU) from the Systems Engineering Research
Center (SERC) and the U.S. Army RDECOMNatick Soldier
RD&E Center (NSRDEC) efforts. Finally, we will provide the
conclusion on the development of the method and describe
future research directions as depicted in Fig. 1.
II. BACKGROUND
Systems thinking have been articulated as a core competency in the practice of good systems engineering [3][6].

c 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
2168-2216 
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
2

Frank [7] described the asset of systems thinking in systems

engineering as engineering systems thinking. In solving
problems for systems engineering, we need to be able to
understand the unstructured problem, with the big picture
in mind, and appreciate that there are multiple perspectives
(with conflicting objectives [8]). The inability to effectively
do this has been described as a key point of failure in
the practice of systems engineering [9]. Doing this right,
is what Senge [10] would define as a shared vision. To
articulate a shared vision in systems engineering, we use
diagrams to transform stakeholder perspectives into system
artifacts, which can represent the systems form, fit, function, component, or environment. These diagrams allow us
to make graphical formulations of elements and their linkages. Yet, the use of some diagrams in systems engineering
to capture multiple and divergent stakeholder perspectives
are limited in their ability to understand motivations, viewpoints, interactions, and addressing qualitative dimensions of
a problem situation. A systemic diagramming technique that
produces a diagram called a systemigram has been shown
to address these limitations. A systemigram is created as
designed from the structured text to capture and represent
the essence of the original conceptual thinking. Systemigrams
are used for understanding and identifying the significant
elements within a system of interest. The systemigram characterizes the problem along with the interrelationships and
diverse expressions of stakeholder concerns and needs. A systemigram structures interrelationships into a graphical presentation and encapsulates the problem into a coherent problem
description [1], [2].
In previous research and practice with systemigrams, the
creation and refinement of systemigrams ended once the problem situation is structured. There has not been a method
to bridge the systemigram problem representation to more
structured system models that are common in the practice of
systems engineering.
The term model is often overloaded in the engineering
community. It might suggest a mathematical representation,
a simulation, or simply a block diagram. For this paper,
the authors do not restrict the use to any single definition, but instead consider a model to be a facsimile of
reality, abstracting out information, or data that does not
contribute to that which is being considered. Therefore, modeling helps to reason about the problem, understand the
complexities, and to communicate with others [11], [12].
System-level models can assist in identifying alternate concepts to address the problem under consideration and further
advance the efforts toward a solution. Initially, the models are
an informal capturing of the perspective from the end-users
viewpoint. The models are hand crafted and the modeler is
responsible for the consistency of the diagrams [13]. Later,
these informal models transition to a more formal approach
and take on the viewpoint of the designers and engineers
with traceability to the original system or problem of interest. The models can lead to high-level requirements that
define what the system must do in the standard nounverb
format, each stating that the system shall perform some
function.

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

Fig. 2.

BSSM [1].

III. U NDERSTANDING THE P ROBLEM : BSSM

Checkland [14] and Checkland and Scholes [15] was one of
the forefathers for understanding and defining a combination
of systems thinking with real-world practice in order to build
a bridge between what he would define as hard (i.e., systems with well-structured problems, such as engineered) and
soft (i.e., systems with ill-defined problems, such as management) systems. Checkland would define this bridge as the
soft systems methodology (SSM). SSM is a problem structuring method (PSM) [16]. Checkland [17] intended SSM to
turn the tension between diverse stakeholder perspectives into
an opportunity in terms of both problem definition and synthesizing feasible changes that address the defined problem.
Munro and Mingers [18] showed SSM to be the prevalent
approach used with a combination of other methods in multimethodological practice for addressing problems. SSM has
been shown to be an effective tool for well over 30 years
at identifying solutions to systemic problems [14]. One of
Checklands notable contributions from SSM is that the first
step is to understand the problem or situation unstructured.
It is unstructured because the problem or situation has not
been clearly defined or bounded. In systems engineering, too
often a solution is started without defining what is the actual
problem.
Another form of PSM, and a variation of SSM is the
BSSM [19], which introduced systemigrams (systemic diagrams) as a tool to approach PSM. While Checkland describes
the concept of rich pictures to model systems thinking,
systemigrams presented a well-defined method for building
rich pictures in a SSM or BSSM approach (see [1], [2]).
Systemigrams were first presented by Boardman [20] to
describe a method for better implementing project management control and for analysis of large-scale project planning
problems [21]. Since their inception, they have evolved into
a tool to explore diversity in perspectives while maintaining a single objective. Some examples of how systemigrams
have been used in various applications of systems engineering are: reinforcement of a program of cultural change in
a medium-sized systems engineering business [22]; creation
of an organization learning platform through organizational

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CLOUTIER et al.: TRANSITIONING SYSTEMS THINKING TO MODEL-BASED SYSTEMS ENGINEERING

knowledge creation and effective distribution [23], process

integration and improvement [24]; modeling of U.K. Ministry
of Defense network enabled capability concept for communication with stakeholders [25]; writing effective CONOPS [26];
obsolescence management for system baseline evolution [27];
defining a body of knowledge for advanced systems engineering [28]; architectural systems engineering methodology
for cyber security [29]; and principles and rules for complex
adaptive systems [30].
The creation of systemigrams follows the seven steps of
BSSM that can be viewed as an iterative process for defining an ill-defined problem (or system of interest). The seven
steps of BSSM are depicted in Fig. 2. We will describe these
steps in further detail in Section IV, but they are explained at
length in [2].
IV. M ODELING THE P ROBLEM : MBSE AND S YS ML
MBSE is the use of a more formalized approach to reason
about a problem under consideration. Wymore [31] published
a seminal work which proposed a fundamental, formal theory
for MBSE. It was a rigorous mathematical modeling language
to understand discrete systems and their components. A generally accepted definition of a model in the systems and software
community was put forth in IEEE 1471-2000 Recommended
Practice for Architectural Description for Software-Intensive
Systems [32]. This definition, which defined a software
architecture model as offering different views in order to
serve different purposes, has been updated and extended to
include systems models [33]. In 2001, the object management group (OMG) and the International Council on Systems
Engineering (INCOSE) began collaborating on a modeling language that would be useful in creating system-level models.
The OMG is the governing body for the unified modeling
language (UML), which is already used to model software.
The intent of the collaboration was to extend UML to address
the unique issues posed by systems that are not found in
software only. This profile, named SysML for systems modeling language, was first adopted by the OMG in July 2006
as OMG SysML and released as a formal specification
in 2007 [34], [35].
In 2007, INCOSE also put forth their definition of MBSE:
MBSE is the formalized application of modeling to support
system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase
and continuing throughout development and later life cycle
phases [36]. An often cited document produced by the
INCOSE MBSE focus group, authored by Estefan [37], surveyed the prevailing MBSE methodologies at that time. While
consolidation in the industry has changed the names of some
of the actors, the methodologies have survived the mergers and
acquisitions. More recently, Ramos et al. [38] provided a snapshot of the current directions and possible futures for MBSE.
Ramos et al. [38] concluded that there remains an ongoing
need for the effective use of graphical modeling languages
able to support collaborative development environments and
successful stakeholders communication/interactions thus successful systems.

Fig. 3.

SysML diagram structure.

SysML contains a number of diagrams that are used to

capture system attributes, operations, tasks, and participants.
Fig. 3 represents the diagram organization.
Each diagram can be used to capture information about the
system of interest at any level or multiple levels of abstraction.
These groups of diagrams are defined as below.
1) Structure diagrams identify the physical and logical
organization of a system. Diagrams of this type are as
follows.
a) Block definition diagrams describe the system hierarchy and system/system element classifications.
Blocks are generally described using nouns.
b) Internal block diagrams describe how the blocks
defined in block definition diagrams are interconnected. These connections are modeled using ports
and connectors.
c) Package diagrams are used to organize the model
into packages that contain other model elements.
They are analogous to folders in a file cabinet.
2) Requirement diagrams capture requirements and requirement hierarchies, as well as the derivation, satisfaction,
and verification relationships. Requirement diagram captures the interrelationship of requirements.
3) Parametric diagrams are used to represent system parameter values, such as performance, reliability, and mass
properties to support engineering analysis.
4) Behavior diagrams capture how the system operates.
Behavior diagrams include the following.
a) Use case diagrams provide a high-level description
of the system functionality in terms of how external systems use the system under consideration to
achieve their goals. The use cases generally represent things to be done by the operator, the system,
or the system parts. Actors represent nouns in the
form of stakeholders, other systems, or system parts.
b) Activity diagrams represent the flow of data (artifacts, which are nouns) and control between
activities.
c) Sequence diagrams represent the exchange of data
between collaborating parts of a system (which are
nouns).
d) State diagrams describe the states of a system or
its parts (nouns), and the transitions between the
states in response to triggering events, along with
the actions that occur upon transition, entry, exit
of while in the state.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
4

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

During the systems architecting process, we use SysML to

reason about the problem, understand the complexities, and
communicate with others [12]. The SysML, as specified by
the OMG, provides a language but no process or methodology
for using the language. While there are available methodologies for using SysML, there is no methodology for moving
from unstructured diagrams such as the BSSM. This is the
problem we are working to address. Can the systemigram
generated collaboratively with the end-users provide sufficient
knowledge to inform the initial creation of a SysML model
toward an MBSE approach? A SysML model is an organized
collection of SysML diagrams for the purpose of describing a
system or enterprise. The next section will look at the opportunity presented to the researchers to investigate this problem.
V. S YSTEMIGRAM TO S YS ML M ETHOD
We have presented two approaches in this paper to model
different perspectives of a systemBSSM and SysML. To
transition from a systems thinking methodology to MBSE, we
present the following steps for a combined method. In the next
section, we will articulate this method using a case example.
The steps we followed are summarized as below.
1.0 Systemigram creation.
1.1 Capture problem from stakeholders perspective
using words, pictures, stories, etc.
1.2 Describe problem situation.
1.3 Express the text as structured text.
1.4 Draw the systemigram from the structured text.
1.5 Partition the systemigram into individual story
scenes.
1.6 Determine if the scenes of the story are feasible.
1.7 Update systemigram as necessary based on findings of 1.6.
2.0 Transition systemigram to SysML.
2.1 Identify nouns, verbs, and action words and phrases
in systemigram.
2.2 Create a domain diagram from the nouns.
2.3 Identify actors and use cases using systemigram.
2.4 Create activity diagrams to represent the action
flows in the systemigram.
Each step will now be discussed in detail.
Step 1: Creation of a systemigram using the BSSM.
Step 1.1: The Problem Situation: Unstructuredthe
problem situation is first expressed textually (e.g., presentations, reports, meeting
notes, publications), verbally (e.g., interviews,
observations of oral discussions), graphically
(e.g., presentations, pictures), as it is by the
stakeholders. This step can be based on many
presumptions and often is the perceived problem by the stakeholders. Thus, every attempt
should be made not to extrapolate about the
nature of the situation but only use this step
to collect perspectives of the problem.
Step 1.2: The Problem Situation: Expresseda
description of the situation within which the
problem occurs is formulated. Both the logic
and the environment of the situation are

taken into account at this point. It is best that

methods in triangulation are used to assure
validity in expressions [39]. Triangulation
uses different sources of information in
order to increase the validity of a study.
Using multiple sources, the observer seeks
correlating information in at least three
independent sources.
Step 1.3: Structured Text: The problem situation is conceptualized in structured text. The structured
text identifies the key elements with attention
to systems thinking modeling and analysis
requirements. An example of such structure
text from [40].
The FAA WJHTC is developing a strategy to
achieve world class system integration and test
capability that supports effective management of
T&E programs to meet sponsors expectations and
achieve customer satisfaction. The strategy must
address the unification of T&E technical and program management processes to facilitate effective
T&E management required to achieve program
integrity, accountability, and the deployment of
quality air traffic control systems that make up
the National Airspace System (NAS). The NAS is
used to provide safe and efficient air transportation services to the aviation industry and the flying
public. Test program sponsors expectations are
characterized by performance metrics, such as ontime systems delivery, on budget, and meeting the
operational requirements (quality). The T&E strategy must address budget overruns and late systems
deployments by programs that do not meet customer satisfaction. It must minimize critical defects
found in deployed systems that cause rework leading to cost and schedule variances. Critical defects
are caused by inadequate test and evaluation of
systems as a consequence of the overall program
management constraints.
The strategy must address the need for a unified supportive infrastructure, which comprises a
Transportation Safety Board (TSB) and a Program
Management Excellence Center (PMEC). To be
credible, the supportive infrastructure must, at a
minimum, be staffed with qualified test engineers
and program management experts. The TSB will
develop and institutionalize technical T&E processes, while the PMEC will coordinate, develop,
and institutionalize program management processes
(foundational) to facilitate the technical processes.
The PMEC must address training, quality management, configuration management, and project
management support services that are essential
for consistent and predictable program performance metrics to achieve customer satisfaction.
The FAA system integration and test organization must ensure that the supportive infrastructure
collaboratively provides the necessary services to

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CLOUTIER et al.: TRANSITIONING SYSTEMS THINKING TO MODEL-BASED SYSTEMS ENGINEERING

Fig. 4.

Federal aviation administration system integration and test organization.

accomplish the strategic objective of achieving

customer satisfaction.
Step 1.4: Systemigram Design: A systemigram is created by reading through the structured text
and capturing the essence of the original
conceptual thinking. A systemigram is a network, having nodes and links, flow, inputs
and outputs, beginning and end (for a detailed
description of systemigrams see [1]). Key
concepts, noun phrases specifying people,
organizations, groups, artifacts, and conditions are nodes. The relationships between
these nodes are verb phrases (occasionally
prepositional phrases) indicating transformation, belonging, and being. Some nodes can
contain other nodes, for example to indicate
break out of a document or an organizational,
product, process, or structure. The network
must be legible so this limits the number of
nodes and links. There should be no crossover of links, improving clarity. The primary
sentence (mainstay), which supports the purpose of the system, will read from top left
to bottom right of the systemigram. The final
node of the mainstay, in the bottom right,
should be the systems goal or objective. The
other segments of the systemigram flow out
of and back into this mainstay, connecting as
needed with its landmark noun phrase nodes.

As the systemigram is developed it should

capture the system transformations that have a
structure and a process. For a detailed description of systemigram design and application,
see [2]. An example of a systemigram based
on the structured text presented in [40] is
shown in Fig. 4.
Step 1.5: Dramatization and Dialog: For this step, the
systemigram model is dramatized via storyboarding to the stakeholders. This is done so
the systemigram and reality can be compared
and contrasted. The differences become the
basis for discussion: how things work, might
work, and what are the implication? The story
can be told in a variety of ways but all have
the same generic formatto create a storyboard using carefully selected scenes, which
are subnets of the systemigram. A subnet is
a child systemigram that further elaborates
some detail(s) of the parent systemigram. This
is a very important step for verifying the
systemigram with respects to its ability to capture the multiple views of the stakeholders.
The technique of storyboarding is described
in detail in [2].
Step 1.6: Feasible, Desirable Changes: At this step,
the identification of feasible and desirable
changes are deciphered from the previous
step, understanding that they are likely to

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
6

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

vary. Desirable asks if the change is technically an improvement to the system. Feasible
asks if the change fits the culture.
Step 1.7: Action to Improve the Problem Situation:
Every individual or collective input that is
deemed desirable or feasible is incorporated
into the model. Only changes that have an
answer of no to one or both of the two
questions presented in Step 6 are dismissed.
The BSSM is repeated until one or all of
the following are achieved: 1) the people
concerned, i.e., stakeholders, feel that the
problem has been defined; 2) the problem situation has been improved; or 3) insights have
been gained.
Step 2: Transition From Informal Systemigrams to SysML:
The overall goal of this step is to transfer the information presented in the systemigrams into SysML
diagrams. The authors have created guidelines to
follow when performing each step to assist in the
transferring of information from the systemigram
to a SysML diagram.
Step 2.1: The first step is to identify and mark the
unique nouns, verbs, and action words in
the entire systemigram. This is a logical step
since nounverb analysis is used in objectoriented design and has been identified to
use in development of SysML diagrams [34].
In the systemigrams, nouns are mostly categorized as systems or components and the
flow of the systemigram gives the relationship
from the top left of the systemigram being
the top-level system then moving across the
systemigram for related systems.
Step 2.2: Once the nouns are identified, a domain
diagram (using a block definition diagram)
for the main system of interest in the systemigram can be generated. The purpose
of a domain diagram is to identify all the
external actors (independent on whether they
are humans, other systems, or enterprises).
This information informs the systems engineer about external interfaces for the system
of interest. The main system of interest for
each systemigram is found at the top left
corner of the diagram. Note that this process should be done for each systemigram
created for a project/problem therefore there
may be multiple domain diagrams created.
Although it is also worth noting that even
when all available information from systemigrams is captured in the SysML model, some
systems required for complete systems engineering model may still be missing from the
overall SysML model and will have to be
manually added. In the domain diagram the
blocks containing the nouns from the systemigram are directly linked to the system of

interest (the one in the top left corner) using

the SysML composition association.
Step 2.3: The systems engineer now looks at the systemigram and identifies descriptors. These
may looks like modes, conditions, concepts,
etc. They should be put into verbnoun pairs
on a use case diagram. Any noun linking to
the descriptors should be considered an actor
participating in the use case. If the actor is a
human, the modeler can use a stick figure. If
the actor is another system, the modeler can
use either a stick figure or a block.
Step 2.4: Finally, the systemigram is used to develop
activity diagrams by considering the flow of
activities. The systemigram indirectly represents flow of events. The flow of events begin
in the upper left corner, and progress down
different threads, ending in the lower right
corner of the diagram. This flow of activity can be captured in one or more SysML
activity diagrams.
VI. C ASE : U.S. A RMY TACTICAL S MALL U NITS
A. Background
The Department of Defense is vigorously pursuing greater
efficiency and productivity in defense spending to provide
the armed forces with superior capabilities in an environment of flat defense budgets. Toward that end, the Office
of the Secretary of Defense (OSD) has issued new acquisition guidance that places increased emphasis on early
lifecycle system engineering to balance operational performance with affordability (Public Law 111-23). However, both
CB and soldier load, when realized as systems of systems
or enterprise, have extremely complex and uncertain missions with deployments into extremely hostile environments
ranging from combat zones to human relief efforts. The
technology mapping dynamic and number of requirement
constraints needed to capture prior uncertainties is unmanageably large. Modern design theory suggests systems design
is better served by methodologies that focus on constructing
objective functions with penalties that capture value and
uncertainty, as opposed to attempting to capture the unmanageable large number of requirement-constraints. Consistent
with the U.S. Army Research, Development, and Engineering
Commands (RDECOM) vision and mission to be the Armys
primary source for integrated research, development, and engineering capabilities to empower, unburden, and protect the
Warfighter, there is a need for the creation of an early collaborative and systems modeling methodology to express and
characterize soldier load and CB at the patrol base, combat
outpost, and SCU (company minus) level.
B. Problem Situation
SCU, consisting of a company (300 soldiers) and below,
currently establish nonstandardized base camps for contingency operations (CB), potentially limiting their ability to

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CLOUTIER et al.: TRANSITIONING SYSTEMS THINKING TO MODEL-BASED SYSTEMS ENGINEERING

Fig. 5.

Soldier SCU systemigram.

project and efficiently employ full spectrum1 operations. The

SCU may not be able to support the modern full spectrum battlefield demands unless CB capabilities specific to
the SCU are combined as a single, integrated, agile, force
projection platform. A contingency base should provide soldiers with an effective, logistically supportable, affordable,
and rapidly deployable environment to project force across
the full spectrum of operations. The establishment of a CB
capability which encompasses the entire lifecycle (planning
to disposal of the contingent base) is the responsibility of
the soldiers, trainers, RDECOM, various program executive
offices, logistics, and other stakeholders. The development
planning process should enable an army enterprise approach
to deliver to the tactical edge with total system integration aligned to army modernization strategies and army force
generation (ARFORGEN).
This case study focused on specific aspects of SCU-CB, as
a force projection platform and a potential means to address
the interrelated individual soldier and SCU load (cognitive and
physical). The problem is being able to develop a set of interrelated processes, mechanisms, and tools to capture, explain,
and manage the complex operational and system interaction
1 The army defines full spectrum operations as the combination of offensive, defensive, and either stability operations overseas or civil support
operations on U.S. soil (U.S. Army Training and Doctrine Command, The
Army Operating Concept 20162028, TRADOC Pamphlet 525-3-1, dated
19 Aug. 2010).

posed by the dynamic nature of the SCU operations, along

with a means to measure progress. The SCU exhibits a complex, pluralistic, set of requirements across a number of factors
ill-suited to standard system engineering practices (for the reasons cited in the previous section). Novel means to optimize
SCU-CB need to be considered.
C. Step 1: Creating the Systemigram
The top-level systemigram of Soldier/SCU (Fig. 5) and a
set of child systemigrams were constructed as the result of a
series of joint meetings over a period of three months between
the researchers and subject matter experts at the U.S. Army
RDECOMNSRDEC. There were 20 stakeholders involved
in the creation of the systemigrams used in this research.
They included the chief engineer, program manager, multiple engineers, and subject matter experts. This resulted in a
multiperspective representation of the problem. The rest of this
section will explain the BSSM steps followed in developing
the systemigrams with these stakeholders.
Step 1.1 (The Problem Situation): UnstructuredThe
research team investigated the situation without bias from
NSRDEC. To develop a perspective of the problem with our
own largely unbiased view, the research team was given access
to NSRDEC documentation and archival information. In addition, ten informal, open-ended interviews [39] were conducted
with NSRDEC stakeholders (five) and CB experts outside

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
8

Fig. 6.

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

Soldier/SCU systemigram with annotations.

of NSRDEC (five). Additionally, researchers were allowed to

observe NSRDEC strategic planning meetings.
Step 1.2 (The Problem Situation): ExpressedBased on
our interpretations from Step 1.1, we developed an expression
of the problem following basic methodologies in case study
triangulation [39] to validate our expression.
Step 1.3 (Structured Text): Using the expression from
Step 1.2, we were able to write a document that summarized
what we found and also indicating any similarities or differences in stakeholder viewpoints. We attempted to not change
the original words or thoughts of the authors/stakeholders, but
attempted to stay true to the essence of their views on the
problem. This became the source text of our systemigram.
Step 1.4 (Systemigram Design): We developed four systemigrams using the systemigram modeling tool SystemiTool
(see http://www.WorldsofSystems.com). These systemigrams
consisted of a top-level systemigram with three child systemigrams. The final version (there were many drafts created
during this process) top-level systemigram is depicted in
Fig. 5. Because of limitations in the size of this paper, only
the top-level systemigram is represented and will be used to
describe the proposed method.
Step 1.5 (Dramatization and Dialog): The dramatization and dialog was executed in a series of three one-day
meetings with stakeholders. At these meetings, the participants were presented with an overview and tutorial on the
use of systemigrams as an education or reminder of the

systemigram modeling constraints. Each systemigram was

storyboarded using SystemiTool to capture stakeholder perspectives (even if conflicting), which were used in executing
Steps 1.6 and 1.7.
Step 1.6 (Feasible, Desirable Changes): For this paper, we
were able to make changes to the systemigram in real-time as
the modeler and the stakeholders were in the room collectively
using SystemiTool.
Step 1.7 (Action to Improve the Problem Situation): This
step was also executed in real-time. Meetings were repeated
with the stakeholder (three meetings total) until a successful
outcome of a BSSM was achieved. Success was defined as:
1) the people concerned, i.e., stakeholders, feel that the problem has been defined and 2) insights have been gained. For
this situation the problem situation has been improved was
not applicable.
D. Step 2: Transitioning From Systemigrams to SysML
From this point forward, we will look at the process of
creating an initial SysML model (an organized collection of
individual SysML diagrams for the purpose of describing a
system of interest or enterprise) from a systemigram. It is
worth noting that during previous steps of developing the systemigrams there were no special steps or consideration taken
to prepare for translation into SysML. Currently, there is not
a method or process of how to translate systemigrams into

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CLOUTIER et al.: TRANSITIONING SYSTEMS THINKING TO MODEL-BASED SYSTEMS ENGINEERING

Fig. 7.

Identified systemigram nouns modeled in SysML.

SysML. While the long-term objective of this paper is to have

the following steps automated, or at least semi-automated, for
this initial research the whole process of transitioning from
informal systemigrams to SysML was performed manually and
the results was an initial SysML model. Therefore, this paper
is the first attempt at formalizing a method to do so. Since
the translation into SysML was not taken into consideration
while developing the systemigrams the researchers realized
that while the SysML diagrams would contain useful information, they would probably be incomplete, and missing key
elements (or even have elements that were of no use). The
goal of this paper was to capture as much information from
the systemigram into the SysML model as possible to provide the systems engineers a skeleton of the SysML model
from which to begin. Missing or extra elements in the SysML
model will have to be identified and removed or added for
a complete SysML model. Also of note is to understand that
with this method naming of elements are taken directly from
the systemigram, therefore, the system engineer may need to
clean up and correct any naming convention errors.
Step 2.1: The first step was to manually identify and
uniquely mark the nouns, verbs, and descriptors (action words
and phrases) in the entire systemigram (Fig. 6). The research
team actually used colored highlighters to do this step. Once
each of these were marked they were reviewed to identify how
and if they were directly related to a SysML diagram or element. It was observed that the nouns could be seen as the
systems or actors, and the flow of the systemigram provided
the relationship.
Step 2.2: Once the nouns were identified to be systems
(or actors), a domain diagram for the system (in this case

Soldier/SCU) (Fig. 7) was generated. A block was created for

each noun, and they were connected using composite associations (representing a part of relationship) where necessary.
The soldier/SCU became the top-level system since it was the
upper most left node on the systemigram making it the system of interest. At this point, the nodes containing the nouns in
the systemigram that were linked to the soldier/SCU system
became the related systems in the domain diagram accordingly and maintaining their relationship. This means that nouns
grouped in nodes were also grouped in the domain diagram by
creating a block named after the node, and the related nodes
were blocks connected to the main block with the composite association. At this point of the modeling effort, it was
decided that the completeness of the SysML diagram was
not as important as following a systematic process to capture
all the information from the systemigram into the SysML
diagram.
Step 2.3: Once the domain diagram was created the remaining information in the systemigram was analyzed to determine
if it contained information that could be translated into
other SysML diagrams. Nodes or connections which contained descriptors were modeled as use cases in a use case
diagram (see Figs. 8 and 9). The nouns were the actors,
the action words and phrases were used to name the use
cases.
Note that some liberty was taken to add manage and
greater before the node names of weight and volume and
operation area, respectively. The word greater was actually taken from the link in the systemigram and manage was
added as a manual liberty and to make the SysML diagram
more correct in naming conventions.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
10

Fig. 8.

Fig. 9.

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

Extended operations use case.

Fig. 10.

Activity diagram of encounter threat use case.

Fig. 11.

Activity diagram for the extended operations use case.

Mobility use case.

Step 2.4: The next step was to create an activity diagram.

The purpose of the activity diagram is to describe (elaborate)
the necessary actions required to perform a use case. As
explained in earlier sections, the systemigram indirectly represents flow of events (actions) in a system. Therefore, begin
in the upper left corner of the systemigram and follow the
flow of the main story threads. The results are one or more
activity diagrams which detail the flow of events, as described
in the systemigram (Figs. 10 and 11 are examples). While the
activity diagram(s) derived from the systemigram will most
likely not be considered fully correct it provides the systems
engineer a starting point populated with many of the necessary
tasks. The systems engineer will then want to update, review,
and check them for completeness and accuracy.
E. Decomposing the Problem
As mentioned earlier, the soldier/SCU systemigram represented the top-level system. However, it was decomposed
into lower level systemigrams to foster more understanding.
While not presented in this paper, those were: 1) sustain
small unit systemigram; 2) gunners systemigram; and 3) soldier systemigram. The process was replicated for each of
those systemigrams, as described in the Cloutier working
papers [41].

VII. C ONCLUSION
The output from this paper helped the customer focus on
what needed to be incorporated into a large army basing
technology capability demonstration. The SysML diagrams
themselves became a living document that was updated as
higher fidelity diagrams were required. Those diagrams were
also used to create narrative requirements and requirement
traceability. Additionally, the output of this paper was incorporated into the work presented at the OSD SoSCIE (Office
of the Secretary of Defense, System of Systems Engineering
Collaborators Information Exchange in April 2014).
During this research, the team had considerable success mining the systemigrams for objects (nouns) that were
useful in creating the initial top-level architecture using
SysML. Descriptors were a good indicator of use cases that
were further elaborated into activity diagrams. However, the
systemigram by its very nature is intended to enforce minimalistic formalisms, this lack of formalism made it difficult

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CLOUTIER et al.: TRANSITIONING SYSTEMS THINKING TO MODEL-BASED SYSTEMS ENGINEERING

sometimes to translate certain relationships, and links from

the systemigram into a SysML model. For instance resulting from and quantified in links are difficult to model. To
address this, it required communication with the stakeholders
during the systemigram to SysML steps. Other challenges to
consider when translating a systemigram to SysML include
the following.
1) The relationship within the overall domain can be hard to
translate. For example, in the set of systemigrams used
for this exercise a gunner and a soldier were identified
individually, but nowhere in any of the diagrams is that
relationship described. The assumption that a gunner is
a soldier is reasonable but it was not apparent in the
systemigram. A more difficult association was that for
the noun identified as leader. While a leader may be
a soldier, the leader can be external to the group under
consideration. In these situations, it is imperative that
the SysML modeler confer with systemigram owner for
clarification.
2) A related challenge was that systemigram nodes such
as leaders in the gunners systemigram appear in the
middle of the systemigram but have no input links into
those nodes (the nodes only have outputs). While those
nodes can be identified as objects (blocks), there is no
obvious placement of the newly created objects in the
SysML model. While this is not acceptable in a systemigram, there are no enforcing rules to ensure the modeler
does not create this form of ambiguity. Thus, in a formal descriptive method we would need to consider how
this special case would be addressed when moving from
systemigrams to SysML.
3) There are issues related to model semantics. While the
degree of semantic rigor in SysML is arguable, there is
no semantic rigor in systemigrams. Translating actions
found on a systemigram such as requires more survivability measures or consume weight and volume
might be captured in early SysML diagrams as a use
case, or an action on an activity diagram. These will
have to be resolved once the systems engineer believes
all the information from the systemigram has been
captured.
The lesson learned is that when decomposing systemigrams
it is important to not reuse nodes at the different levels of
systemigrams unless they are exact nodes. More importantly,
the systemigram modeler, SysML modeler, and stakeholders should communicate often through this process to ensure
consistent understanding across the team. However, this should
be the case in any system design process.
The research performed, in conjunction with the NSRDEC
researchers, was to create an abstraction of the CB and soldier
load scope that would be a guide to identify the critical components and aspects that will need priority of scrutiny in order
to create high-fidelity models. This was achieved by creating
high-level systemigrams and system models for soldier load
and CB. It was then demonstrated how systemigram models can be used to capture key dimensions for input into a
defined SysML tool for creating better systems engineering
artifacts.

11

It would also be desirable to develop a model-based

paradigm that enables a more expedient synthesis, analysis,
and evaluation of the problem and potential array of solutions. This would then allow expanded trade space exploration
and a better understanding of the resilience of the architecture and deployment. Accordingly, we are proposing a further
exploration of systems engineering modeling practices that
would formalize the characterization of testable properties as
a long-term improvement for what will appear as conventional
engineering and would be useful in the early days of the CB
initiative.
It has always been a difficult bridge to build between hard
and soft systems engineering. We believe our proposed method
is a valiant effort in starting a bridge, but not without challenges for further work. For instance, while there is a desire
to make the translation more automated, the authors have
not investigated existing or potential tools or algorithms for
noun/verb/adjective identification. And, in fact, due to challenges presented earlier in this section, automation may not be
possible without making changes to the soft systems methods
to enforce semantic discipline. It is unknown whether enforcing semantic discipline in a soft systems modeling approach
may become a disincentive to using the approach. As with any
theory, this method is a theoretical proposition, which needs
further verification and extensive validation (i.e., external,
internal, criterion, content, construct, convergent, discriminant,
and face validities) to move from research to practice. This
needs to be conducted in a mixed methodological approach of
both qualitative and quantitative methods. In the practice of
systems engineering, an approach that bridges systems thinking with the hard practice of systems engineering is a long
bridge to build and will take the effort of many.
ACKNOWLEDGMENT
Any opinions, findings, and the conclusions or recommendations expressed in this paper are those of the authors and do
not necessarily reflect the view of the SERC, Stevens Institute
of Technology, University of North Texas, NSRDEC and/or
any agency or entity of the U.S. Government.
R EFERENCES
[1] J. Boardman and B. Sauser, Systems Thinking: Coping With 21st Century
Problems. Boca Raton, FL, USA: CRC Press, 2008.
[2] J. Boardman and B. Sauser, Systemic Thinking: Building Maps for
Worlds of Systems. Hoboken, NJ, USA: Wiley, 2013.
[3] M. E. Derro and C. R. Williams, Behavioral competencies of highly
regarded systems engineers at NASA, in Proc. 2009 IEEE Aerosp.
Conf., Big Sky, MT, USA, pp. 117.
[4] P. A. Jansma and M. E. Derro, If you want good systems engineers,
sometimes you have to grow your own! in Proc. 2007 IEEE Aerosp.
Conf., Big Sky, MT, USA, pp. 115.
[5] A. T. Bahill and B. Gissing, Re-evaluating systems engineering concepts using systems thinking, IEEE Trans. Syst., Man, Cybern. C, Appl.
Rev., vol. 28, no. 4, pp. 516527, Nov. 1998.
[6] C. Haskins, K. Forsberg, and M. Krueger, INCOSE Systems Engineering
Handbook v3.1. Seattle, WA, USA: Int. Council Syst. Eng., 2008.
[7] M. Frank, Characteristics of engineering systems thinkingA 3D
approach for curriculum content, IEEE Trans. Syst., Man, Cybern. C,
Appl. Rev., vol. 32, no. 3, pp. 203214, Aug. 2002.
[8] G. M. Jenkins, The systems approach, in Systems Behaviour, 2nd ed.,
J. Beishon and G. Peters, Eds. London, U.K.: Harper, 1969, p. 82.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
12

[9] M. Ryschkewitsch, D. Schaible, and W. Larson, The art and science of

systems engineering, Syst. Res. Forum, vol. 3, no. 2, pp. 81100, 2009.
[10] P. Senge, The Fifth Discipline: The Art & Practice of the Learning
Organization. New York, NY, USA: Currency Doubleday, 1990.
[11] R. Cloutier, Advanced System and SoS Architecture Modeling &
Assessment, Lecture Notes SYS750, Stevens Inst. Technol., Hoboken,
NJ, USA, 2011.
[12] R. Cloutier, An introduction to the JET special issue of journal of
enterprise transformation: Enterprise modeling, J. Enterp. Transform.,
vol. 1, p. 4, Jul./Sep. 2011.
[13] P. Colombo, F. Khendek, and L. Lavazza, Bridging the gap between
requirements and design: An approach based on problem frames and
SysML, J. Syst. Softw., vol. 85, no. 3, pp. 717745, 2012.
[14] P. Checkland, Soft systems methodology: A thirty year retrospective,
Syst. Res. Behav. Sci., vol. 17, pp. 1158, Nov. 2000.
[15] P. Checkland and J. Scholes, Soft Systems Methodology in Action.
Hoboken, NJ, USA: Wiley, 1999.
[16] J. Rosenhead and J. Mingers, Rational Analysis for a Problematic World
Revisited: Problem Structuring Methods for Complexity, Uncertainty and
Conflict. Chichester, U.K.: Wiley, 2001.
[17] P. Checkland, Systems Thinking, Systems Practice. Hoboken, NJ, USA:
Wiley, 2000.
[18] I. Munro and J. Mingers, The use of multi-methodology in
practiceResults of a survey of practitioners, J. Oper. Res. Soc.,
vol. 53, no. 4, pp. 369378, 2002.
[19] J. T. Boardman, A process model for unifying systems engineering and
project management, Eng. Manage. J., vol. 4, no. 1, pp. 2535, 1994.
[20] J. Boardman, Control in project management, in Proc. IEE Colloq.
Generic Control Syst., London, U.K., Jun. 1990, pp. 1932.
[21] J. Boardman, A methodology for strategic plan modelling, in Proc. IEE
Colloq. Goal-Driven Plan. Compl. Environ., London, U.K., Oct. 1990,
pp. 1114.
[22] A. J. Cole, S. J. Wolak, and J. T. Boardman, Computer-based process handbook for a systems engineering business, in Proc. 7th Int.
Workshop Comput.-Aided Softw. Eng., Toronto, ON, Canada, 1995,
pp. 172181.
[23] D. A. Ramsay, J. T. Boardman, and A. J. Cole, Reinforcing learning,
using soft systemic frameworks, Int. J. Proj. Manage., vol. 14, no. 1,
pp. 3136, 1996.
[24] B. T. Clegg and J. T. Boardman, Process integration and improvement
using systemic diagrams and a human-centred approach, Concurr. Eng.
Res. Appl., vol. 4, no. 2, pp. 119136, 1996.
[25] C. D. Blair, J. T. Boardman, and B. J. Sauser, Communicating
strategic intent with systemigrams: Application to the network-enabled
challenge, Syst. Eng., vol. 10, no. 4, pp. 309322, 2007.
[26] J. Frittman and R. Edson, Systems thinking based approach to writing
effective concepts of operations (CONOPs), in Proc. Conf. Syst. Eng.
Res., Hoboken, NJ, USA, 2009, pp. 1719.
[27] T. Herald, D. Verma, C. Lubert, and R. Cloutier, An obsolescence management framework for system baseline evolutionPerspectives through
the system life cycle, Syst. Eng., vol. 12, no. 1, pp. 120, 2009.
[28] A. Squires et al., Applying systems thinking via systemigrams for
defining the body of knowledge and curriculum to advance systems engineering (BKCASE) project, in Proc. Conf. Syst. Eng. Res., Hoboken,
NJ, USA, 2010, pp. 739753.
[29] J. L. Bayuk and B. M. Horowitz, An architectural systems engineering
methodology for addressing cyber security, Syst. Eng., vol. 14, no. 3,
pp. 294304, 2011.
[30] G. A. Polacek, D. A. Gianetto, K. Khashanah, and D. Verma, On principles and rules in complex adaptive systems: A financial system case
study, Syst. Eng., vol. 15, no. 4, pp. 433447, 2012.
[31] W. Wymore, Model-Based Systems Engineering. Boca Raton, FL, USA:
CRC Press, 1993.
[32] Recommended Practice for Architectural Description for SoftwareIntensive Systems, IEEE Standard 1471-2000, 2000.
[33] ISO/IEC/IEEE Systems and Software EngineeringArchitecture
Description, ISO/IEC/IEEE 42010-2011, 2011.
[34] S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to
SysML: The Systems Modeling Language, 2nd Ed. Waltham, MA, USA:
Morgan Kaufmann, 2011.
[35] OMG, OMG systems modeling language, in OMG Document
Formal/07-09-01, Needham, MA, USA: Object Manage. Group,
Sep. 2007.
[36] INCOSE, Systems Engineering Vision 2020. Seattle, WA, USA:
Int. Council Syst. Eng., 2004.

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS

[37] J. Estefan, Survey of model-based systems engineering (MBSE)

methodologies, Int. Council Syst. Eng., San Diego, CA, USA,
Tech. Rep. INCOSE-TD-2007-003-01, 2008.
[38] A. L. Ramos, J. V. Ferreira, and J. Barcelo, Model-based systems engineering: An emerging approach for modern systems, IEEE Trans. Syst.,
Man, Cybern. C, Appl. Rev., vol. 42, no. 1, pp. 101111, Mar. 2012.
[39] R. K. Yin, Case Study Research: Design and Methods, 4th ed.
Thousand Oaks, CA, USA: Sage, 2008.
[40] A. P. Eigbe, B. J. Sauser, and J. Boardman, Soft systems analysis of
the unification of test and evaluation and program management: A study
of a federal aviation administrations strategy, Syst. Eng., vol. 13, no. 3,
pp. 298310, 2010.
[41] R. Cloutier. (2011). Mining Systemigram Content to Create
a SysML Model. [Online]. Available: http://www.calimar.com/
Mining%Systemigrams%06-14-2011.pdf

Robert Cloutier (M07) received the B.S. degree

from the U.S. Naval Academy, Annapolis, MD,
USA, the MBA degree from Eastern University,
St. Davids, PA, USA, and the Ph.D. degree in
systems engineering from the Stevens Institute of
Technology, Hoboken, NJ, USA.
He is an Associate Professor of Systems
Engineering with the School of System and
Enterprises, Stevens Institute of Technology, where
he leads the systems engineering program. He serves
on the Scientific Advisory Board of the National
Science Foundation Engineering Research Center for Compact and Efficient
Fluid Power. He is currently the President of the Delaware Valley Chapter of
INCOSE. His current research interests include improving concept engineering and the way CONOPS are created, applying patterns while architecting
complex systems, and model-based systems engineering. He has over 20 years
of industry experience and his industry roles include principle systems engineer, system architect, lead systems engineer, and engineering project manager
for major defense contractors.

Brian Sauser (M03SM11) received the B.S.

degree from Texas A&M University, College
Station, TX, USA, the M.S. degree from Rutgers,
The State University of New Jersey, New Brunswick,
NJ, USA, and the Ph.D. degree from the Stevens
Institute of Technology, Hoboken, NJ, USA.
He is an Associate Professor of Complex
Logistics Systems with the College of Business,
University of North Texas (UNT), Denton, TX,
USA, where he currently serves as the Director of
the Complex Logistics Systems Laboratory and as
an Associate Director of Research for the Center for Logistics Education and
Research. He teaches courses in logistics and business analysis, advanced
supply chain management, theory of logistics systems, and systems thinking.
He has held positions as an Assistant Professor with the School of Systems
and Enterprises at Stevens Institute of Technology, a Project Specialist with
ASRC Aerospace at NASA Kennedy Space Center, Cocoa Beach, FL, USA,
a Program Administrator with the New JerseyNASA Specialized Center of
Research and Training, Rutgers, The State University of New Jersey, and as
the Laboratory Director with G.B. Tech Engineering, NASA Johnson Space
Center, Houston, TX, USA. His current research interests include management of system evolution and lifecycles for complex systems.
Dr. Sauser was the recipient of the 2010 Davis Memorial Award for his
work in system development planning. He is an Associate Editor of the IEEE
S YSTEMS J OURNAL. He is a Faculty Fellow of the National Aeronautics and
Space Administration.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
CLOUTIER et al.: TRANSITIONING SYSTEMS THINKING TO MODEL-BASED SYSTEMS ENGINEERING

Mary Bone received the B.S. degree in aerospace

engineering from the Missouri University of Science
and Technology, Rolla, MO, USA, and the M.Eng.
degree in systems engineering from Iowa State
University, Ames, IA, USA, in 2001 and 2007,
respectively. She is currently pursuing the Ph.D.
degree from the Stevens Institute of Technology,
Hoboken, NJ, USA.
From 2001 to 2003, she was a Systems Engineer
at Rockwell Collins, Cedar Rapids, IA, USA, where
she was with the Common Avionics Architecture
System. In 2004, she joined Dell, Austin, TX, USA, as a Laptop Test Engineer.
Later, in 2004, she joined BAE Systems Information and Electronic Systems
Integration, Austin, as a System Engineer on a variety of military projects.
In 2005, she joined GE Transportation Systems Global Signaling, Grain
Valley, MO, USA, as a Systems Engineer, where she developed signaling and
train control systems. Within these companies, she has held roles in system
design, requirements, verification, validation, and system engineering steering teams. She is currently a Research Assistant with the Stevens Institute
of Technology, researching on variety of system engineering-related research
projects including reference architectures, model-based systems engineering,
system engineering process, and concept of operation development. Her current research interests include system architecture structural complexity and
entropy. She has coauthored the book entitled Systems Engineering Simplified,
CRC Press/Taylor & Francis Group, and has also published conference and
journal papers in the above areas.

13

Andrew Taylor received the B.S. degree in electrical and electronics engineering and the M.S. degree
in industrial engineering, both from Texas A&M
University, College Station, TX, USA.
He is the Chief Engineer, Technical Plans
and Programs at the U.S. Army Natick Soldier
Research, Development, and Engineering Center,
Natick, MA, USA, where he is responsible for
systems engineering, technical supervisor, strategic
planning, program creation, organizational management/development, requirements generation, metrics, multidecision theory, building customer relationships, and systems
safety.

All in-text references underlined in blue are linked to publications on ResearchGate, letting you access and read them immediately.