A Proposed Framework for a Systems Engineering Discipline

A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                                 Page 1

      A Proposed Framework for a Systems Engineering
                                        Joseph E. Kasser
                Centre of Excellence in Defence and Industrial Systems Capability
                                  University of South Australia
                                       Adelaide, Australia
                                Email: Joseph.kasser@incose.org

                                                       early stages of a discipline. The paper then
Abstract                                               discusses the elements of a discipline and hy-
    The paper discusses the rationale for, and         pothesizes that a framework for systems engi-
describes a proposed framework for systems             neering exists. Using the scientific method to
engineering in the context of a discipline. This       build on an earlier two-dimensional frame-
framework,       the   Hitchins-Kasser-Massie          work, the paper then presents a candidate
(HKM) framework has already facilitated                three-dimensional-framework based on the
postgraduate teaching of systems engineering           problem solving perspective. The paper then
and has provided reasons why systems engi-             discusses some insights that the framework
neers have a plurality of views concerning the         has already provided.
scope and nature of systems engineering. The
contribution of this paper is to place the HKM         The need for a framework
framework in the context of Kline‟s definition             We need a framework because systems
of a discipline.                                       engineering has failed to fulfill 50 years of
                                                       promises of providing solutions to the com-
Introduction                                           plex problems facing society. (Wymore, 1994)
    George Friedman called for the develop-            pointed out that it was necessary for systems
ment of a grand unified theory of systems en-          engineering to become an engineering discip-
gineering (GUTSE) (Friedman, 2006) echoing             line if it was to fulfill its promises and thereby
the earlier lament by (Hill and Warfield, 1972)        survive. Nothing has changed in that respect
who wrote                                              since then. (Wymore, 1994) also stated that
    “development of a theory of systems                      “Systems engineering is the intellec-
    engineering that will be broadly ac-                     tual, academic, and professional disci-
    cepted is much to be desired.”                           pline, the principal concern of which is
                                                             to ensure that all requirements for
    Taking up the spirit of those challenges,
                                                             bioware/hardware/software       systems
this paper proposes a framework for systems
                                                             are satisfied throughout the lifecycles
engineering that can serve as a vital element in
                                                             of the systems. This statement defines
formalizing the discipline of systems engi-
                                                             systems engineering as a discipline,
neering and potentially as a platform for de-
                                                             not as a process. The currently ac-
veloping such a theory.
                                                             cepted processes of systems engineer-
    The paper begins with a discussion of the
                                                             ing are only implementations of sys-
need for the framework, as a fundamental part
                                                             tems engineering.
of a discipline, observes that systems engi-
neering shows the symptoms of being in the                   Out of more than 50 definitions discovered
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                              Page 2

in the literature (Kasser and Massie, 2001;            Moving towards a discipline
Kasser and Palmer, 2005), Wymore provided                  As today‟s systems engineering is in a
the only definition of systems engineering as a        similar state to chemistry and electrical engi-
discipline.                                            neering in their formative years, then a major
                                                       step forward in the development of the discip-
The elements of a discipline                           line would be to apply the scientific method to
    Consider the elements that make up a dis-          postulate a hypothesis (namely a framework
cipline. One view was provided by (Kline,              for systems engineering exists); identify and
1995) page 3) who states                               prototype a candidate framework, test it; mod-
    “a discipline possesses a specific area            ify it and eventually evolve a working frame-
    of study, a literature, and a working              work for systems engineering. This frame-
    community of paid scholars and/or                  work would pull together systems engineering
    paid practitioners”.                               in an analogous manner to the application of
                                                       the periodic table of elements in chemistry.
    Systems engineering has a working com-                 The hypothesis behind this research is that
munity of paid scholars and paid practitioners.        if the activities performed by systems engi-
However, the area of study seems to be differ-         neers can be plotted in a framework it may be
ent in each academic institution but with vari-        able to bring about a revision of the a priori
ous degrees of commonality. This situation             understanding of systems engineering. This
can be explained by the recognition that               means a change in the understanding of its
(1)      systems engineering has only been in          current paradigm (Churchman, 1979) page
         existence since the middle of the 20 th       105) or Weltanschauung (Checkland and
         century (Johnson, 1997; Jackson and           Scholes, 1990), and its emergence as a true
         Keys, 1984; Hall, 1962), and                  engineering discipline. (Kasser, 2006) dis-
(2)      as an emerging discipline, systems            cussed the evolution of a proposed framework
         engineering is displaying the same            for systems engineering. This paper places
         characteristics as did other now estab-       that framework in the context of Kline‟s defi-
         lished disciplines in their formative         nition of a discipline.
    Thus, systems engineering may be consi-            Elements relevant to research in
dered as being in a similar situation to the
                                                       a discipline
state of chemistry before the development of
the periodic table of the elements, or similar to         According to (Checkland and Holwell,
the state of electrical engineering before the         1998) research into a discipline needs the fol-
development of Ohm‟s Law. This is why vari-            lowing three items:
ous academic institutions focus on different              An Area of Concern (A), which might be
areas of study but with some degree of com-               a particular problem in a discipline (area
monality in the systems development life                  of study), a real-world problem situation,
cycle. Nevertheless, to be recognized as a dis-           or a system of interest.
cipline, the degree of overlap of the various             A particular linked Framework of Ideas
areas of study in the different institutions              (F) in which the knowledge about the area
needs to be much, much greater.                           of concern is expressed. It includes current
                                                          theories, bodies of knowledge, heuristics,
                                                          etc as documented in the literature as well
                                                          as tacit knowledge.
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                                  Page 3

       Figure 1 Elements relevant to any piece of research (Checkland and Hol-
                               well, 1998) page 23)

    The Methodology (M) in which the                         the systems engineer is the man who is
    framework is embodied that incorporates                  generally responsible for the over-all
    methods, tools, and techniques in a man-                 planning, design, testing, and produc-
    ner appropriate to the discipline that uses              tion of today’s automatic and semi-
    them to investigate the area of concern.                 automatic systems” (Chapanis, 1960)
                                                             page 357).
    Figure 1 extracted from (Checkland and
Holwell, 1998) page 23) illustrates the rela-                The principal functions of systems en-
tionship between these elements. Given that                  gineering are “to develop statements
there is a working community of paid scholars                of system problems comprehensively,
and/or practitioners (Kline, 1995) page 3),                  without disastrous oversimplification,
these same three elements can also be used to                precisely without confusing ambigui-
characterise a discipline because they expand                ties, without confusing ends and
(Kline, 1995)‟s specification and encompass                  means, without eliminating the ideal in
the key aspects of a discipline (Cook, Kasser                favour of the merely practical, without
and Ferris, 2003). Consider each of these ele-               confounding the abstract and the con-
ments in turn, as they apply to systems engi-                crete, without reference to any particu-
neering.                                                     lar solutions or methods, to resolve
    An Area of Concern (A). Pragmatically,                   top-level system problems into simpler
the Area of Concern (A) should be both what                  problems that are solvable by technol-
systems engineers do and where they do it.                   ogy: hardware, software, and bioware,
There have been many diverse opinions on                     to integrate the solutions to the simpler
these topics over the years, typical examples                problems into systems to solve the top-
are (Allison and Cook, 1998; Hitchins, 2000;                 level problem” (Wymore, 1993) page
Sage, 1995; Badaway, 1995; Kasser, 1995;                     2).
Chapanis, 1960; Shenhar and Bonen, 1997;
Wymore, 1993) hence the difficulty in defin-                 Systems engineering is a wide-range
ing systems engineering. Three sample opi-                   activity, and it should not be handled
nions are:                                                   in the same form for all kinds of sys-
                                                             tems (Shenhar and Bonen, 1997).
    “Despite the difficulties of finding a
    universally accepted definition of sys-
    tems engineering, it is fair to say that                 In addition, the latest systems engineering
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                                   Page 4

standard ISO 1528 provides a list of the orga-               cal breadth and technical depth. Roe adds
nizational processes or activities in which sys-             that the difference in application is that the
tems engineers are involved as shown in Fig-                 system engineer has more technical
ure 2 extracted from the standard (Arnold,                   breadth, while the project manager has
2002) page 61). Note the use of the word                     more management expertise.
“management” in eight of the process boxes.                  (Bottomly, Brook, Morris and Stevens,
                                                             1998) studied the roles of the systems en-
                                                             gineer and the project manager and identi-
                                                             fied 185 activities and their competencies
                                                             (experience and knowledge). Their find-
                                                             ings included:
                                                                 o No competency was assessed as
                                                                     being purely the province of sys-
                                                                     tems engineering.
                                                                 o There is no sharp division between
                                                                     the two disciplines (systems engi-
                                                                     neer and the project manager) even
                                                                     at the level of individuals.
                                                          Further research into the reason for the
     Figure 2 ISO 52888 Systems Engi-                  overlapping of the disciplines turned up in-
           neering Processes                           formation as to how the overlap originated.
                                                       The following statement:
    There have also been many discussions in                 “Driven by cold war pressures to de-
the literature about the overlapping of, and                 velop new military systems rapidly,
differences in, the roles of systems engineer-               operations research, systems engineer-
ing, systems architecting, and project man-                  ing, and project management resulted
agement, e.g. (Brekka, Picardal and Vlay,                    from a growing recognition by scien-
1994; Roe, 1995; Sheard, 1996; Kasser, 1996;                 tists, engineers and managers that
Mooz and Forsberg, 1997; Kasser, 2002;                       technological systems had grown too
Eisner, 2002; Kasser and Palmer, 2005; Kass-                 complex for traditional methods of
er, 2005; Faulconbridge and Ryan, 2003; Mai-                 management and development” (John-
er and Rechtin, 2000) and (Alleman, 2005)                    son, 1997)
who recasts project management as systems
management using systems engineering. In                   and the argument in the rest of the paper
addition, there have also been many discus-            seem to provide a definitive answer. (Kasser,
sions in the literature about the depth of spe-        2005) showed how the roles evolved into
cialty knowledge required for each of the roles        overlapping functions due to the differences in
in the development of systems, typical exam-           the activities assigned to the roles in different
ples are (Kasser and Schermerhorn, 1994;               organisations. The (A) of systems engineering
Roe, 1995; Bottomly, Brook, Morris and Ste-            thus needs to span the activities performed by
vens, 1998; Maier and Rechtin, 2000; Kasser,           the roles of the systems engineer, operations
2000; Kasser, 2002). For example:                      researcher and project manager.
    according to (Roe, 1995) the knowledge                 The framework of ideas (F). (Checkland
    and skills of systems engineers are the            and Holwell, 1998) pages 23-25) discuss the
    same as those of project management in             importance of a “declared-in-advance” epis-
    the areas of management expertise, techni-         temological framework (F) when undertaking
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                               Page 5

interpretive research. Thus establishing an (F)              and Fabrycky, 1981; Buede, 2000) and
is fundamental to the definition of a research               other treatments of the systems engineer-
topic or a discipline. As systems engineering                ing process.
focuses on problems (Wymore, 1994), the (F)
for systems engineering can be considered as                 The Hitchins-Kasser-Massie
being documented in the literature on systems                        Framework
thinking, problem solving and the activities                The vertical and horizontal dimensions of
that take place in the (A).                            the framework are based on the work of
    The methodology (M). Since the activity            (Kasser and Massie, 2001) who, in conceptua-
known as systems engineering overlaps other            lising a framework for a systems engineering
organisational activities, systems engineering         body of knowledge based on the roles of sys-
may be considered as a meta-methodology                tems engineers, created the following two-
incorporating the methodologies, tools and             dimensional framework.
techniques used in the (A) by both systems
                                                            The vertical dimension of the frame-
engineers and practitioners of the other orga-         work is based on the work of (Hitchins, 2000)
nisational activities. This puts a considerable        who proposed the following five-layer model
number of tools into the toolbox of the sys-           for systems engineering:
tems engineer. These tools include:
                                                            Layer 5 - Socioeconomic, the stuff of
    Total Systems Intervention (Flood and                   regulation and government control.
    Jackson, 1991);
                                                            Layer 4 - Industrial Systems Engineering
    Soft Systems Methodology (Checkland
                                                            or engineering of complete supply
    and Holwell, 1998);                                     chains/circles. Many industries make a
    the process-oriented, blended, object-                  socio-economic system. A global wealth
    oriented, rapid development, people ori-                creation philosophy. Japan seems to oper-
    ented, and organisational-oriented meth-                ate most effectively at this level.
    odologies discussed in (Avison and Fitz-                Layer 3 - Business Systems Engineering -
    gerald, 2003);                                          many businesses make an industry. At this
    a whole suite of problem solving tools for              level, systems engineering seeks to opti-
    requirements elicitation and elucidation                mize performance somewhat independent
    discussed in (Hari, Kasser and Weiss,                   of other businesses
    2007); these include interviews (Alexan-                Layer 2- Project or System Level. Many
    der and Stevens, 2002), Joint Applications              projects make a Business. Western engi-
    Development (JAD) (Wood and Silver,                     neer-managers operate at this level, prin-
    1995), Analytical Hierarchical Process
                                                            cipally making complex artefacts.
    (AHP) (Saaty, 1990), Nominal Group
                                                            Layer 1- Product Level. Many products
    Technique (NGT) (Memory Jogger, 1985)
                                                            make a system. The tangible artefact level.
    scenario building, user/customer inter-
                                                            Many [systems] engineers and their insti-
    views, questionnaires, customer visits, ob-
                                                            tutions consider this to be the only "real"
    servation, customer value analysis, use
                                                            systems engineering.
    cases, contextual inquiry, focus groups,
    viewpoint modelling (Darke and Shanks,                 Hitchins states that the five layers form a
    1997), and Quality Function Deployment             "nesting" model, i.e. many products make a
    (QFD) (Hauser and Clausing, 1988; Claus-           project, many projects make a business, many
    ing and Cohen, 1994);                              businesses make an industry and many indus-
    the more commonly used hard systems                tries make a socio-economic system. Hitchins
    methodologies discussed in (Blanchard              also states that these statements are only ap-
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                              Page 6

proximate since-                                       working in Area „2F.‟ Note, while the axes of
   A socioeconomic system has more in it               the framework are shown in a linear manner,
   than just industries.                               this is just for the convenience of drawing.
   A business has more in it than just pro-            The operations and maintenance phase of the
   jects, and so on.                                   system life cycle generally lasts much longer
   Actual organizations may divide the work            than the initial acquisition phases, hence col-
   in different ways resulting in either sub-          umn G is drawn wider than the other columns.
   layers, or different logical break points.
    The horizontal dimension of the frame-
work covers the phases of the systems engi-
neering life cycle. (Kasser and Massie, 2001)
did not define explicit phases. The phases
have been stated in various ways in various
standards, conference papers and books, but
for this framework, they are now defined in
generic terms as:
A. Identifying the need.
B. Requirements analysis.
C. Design of the system.
D. Construction of the system.                               Figure 3 The HKM Framework for
E. Testing of the system components.                             Systems Engineering
F. Integration and testing of the system.
G. Operations, maintenance and upgrading                     Adding the third dimension
    the system.                                            (Kasser and Massie, 2001)‟s vertical and
H. Disposal of the system.                             horizontal dimensions provide a map for the
                                                       location of the activities performed by systems
    The horizontal dimension is also nested            engineers. This paper now goes beyond
but in time. For example, the initial acquisi-         (Kasser and Massie, 2001) and discusses the
tion of a system might flow linearly through           development of the candidate for the third di-
the system development life cycle from Area            mension. The third dimension of the HKM
2B through Areas 2C, 2D, 2E, 2F to delivery            Framework is the difficult one since there are
and operations and maintenance in Area 2G.             many ways to classify the types of problems
However, the activities that take place during         posed in each area of the network. One imme-
the operations and maintenance phase (Area             diately obvious approach is by the domain
2G) are the same as those that take place in           (aerospace, military, commercial etc.) how-
requirements analysis (of change requests)             ever, it was felt that
(2B), design (2C), construction (2D) testing           1. this situation was analogous to the devel-
(2E) and integration (2F) of the configurations            opment of theories of motivation in Psy-
of the various system upgrades.                            chology, and
    The vertical and horizontal axes produce a         2. if the analogy holds true then applying les-
two-dimensional map containing 40 areas as                 sons learned from Psychology to systems
shown in Figure 3. Thus, a systems engineer                engineering, should provide a workable
performing requirements analysis for a new                 framework.
system is working in Area „2B‟. Another sys-
tems engineer performing integration and test-             At one point of time in the development of
ing on the same or a different new system is           theories of motivation, Henry A. Murray iden-
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                                 Page 7

tified separate kinds of behaviour and devel-          views the coin. For example, a set of require-
oped an exhaustive list of psychogenic or so-          ments may be considered as:
cial needs (Murray, 1938). However, the list is           a solution – the specification of a system
so long that there is almost a separate need for          that will meet a need.
each kind of behaviour that people demon-                 A problem – a description of something
strate (Hall and Lindzey, 1957). While this list          that needs to be designed.
has been very influential in the field of Psy-
chology, it has not been applied directly to the           Consequently, the first attempt to formu-
study of motivation in organizations. This is          late a framework for systems engineering in
probably because the length of the list makes          this research (Kasser, 2006) based the third
it impractical to use. On the other hand, Mas-         dimension of the framework on problem solv-
low's hierarchical classification of needs             ing (risk mitigation). One context of catego-
(Maslow, 1954; Maslow, 1968; Maslow,                   ries for risk mitigation was found in the litera-
1970) has been by far the most widely used             ture in (Shenhar and Bonen, 1997) who pre-
classification system in the study of motiva-          sented a taxonomy in which systems were
tion in organizations. Maslow differs from             classified according to three levels of system
Murray in two important ways; his list is              scope and four levels of technological uncer-
     Arranged in a hierarchy -commonly                 tainty (risk). Their three levels of system
     drawn as a pyramid, and contains a set of         scope correspond roughly to the three lower
     hypotheses about the satisfaction of these        layers of the Hitchins five layer model (Hit-
     needs.                                            chins, 2000) and their four levels of technolo-
     Short -- Only five categories.                    gical uncertainty (risk) are:
                                                           Type a — Low-Technology Projects
     Clayton P. Alderfer subsequently proposed             which rely on existing and well-
modifying Maslow's theory by reducing the                  established technologies to which all in-
number of categories to three (Alderfer,                   dustry players have equal access. The sys-
1972). Murray's and early theories defined                 tem requirements of Low-Tech Projects
needs or instincts, Maslow's shows interde-                are usually set by the customer prior to
pendencies and relationships between those                 signing the contract and before the formal
needs and Alderfer proposed further reduc-                 initiation of the project execution phase.
tions in the number of categories. Applying
                                                             Type b — Medium-Technology Projects
this situation to systems engineering, it was
                                                             which rest mainly on existing technolo-
felt that using system domains as the third di-
                                                             gies; however, such systems incorporate a
mension would be analogous to using Mur-
                                                             new technology or a new feature of limited
ray‟s list of needs and a Maslow/Alderfer
                                                             scale. Their requirements are mainly set in
more generic-type classification was needed.
                                                             advance; however, some changes may be
Consider Maslow as having identified com-
                                                             introduced during the product develop-
mon categories and then grouped Murray‟s
                                                             ment phase. This process often involves a
needs into those categories as well as adding
                                                             joint effort of the contractor and customer.
the interdependencies and relationships be-
                                                             It may also require the involvement of po-
tween those needs. In any domain of systems
                                                             tential customers in the process.
engineering systems engineers deal with prob-
lems (Wymore, 1994).                                         Type c — High-Technology Projects
     Problem stating and problem solving may                 which are defined as projects in which
be considered as two sides of the same coin                  most of the technologies employed are
depending on the perspective from which one                  new, but existent — having been devel-
A Proposed Framework for a Systems Engineering Discipline
Conference on Systems Engineering Research 2007, Paper 057                               Page 8

    oped prior to the project’s initiation. Sys-       work. The following are some of the insights
    tem requirements are derived interactively         already afforded by the framework.
    with a strong involvement by customers or          1. Reasons why systems engineers do not
    potential users, and many changes are in-              agree on the roles of systems engineers
    troduced during the development phase.                 and the different definitions of systems
    Type d — Super-High-Technology Pro-
                                                       2. A roadmap for a more complete set of sys-
    jects which are based primarily on new,
                                                           tem requirements.
    not entirely existent, technologies. Some
                                                       3. The place of operations research in the
    of these technologies are emerging; others
    are even unknown at the time of the pro-
                                                       4. The similarity between new product de-
    ject’s initiation. System requirements are
                                                           velopment and systems engineering.
    hard to determine; they undergo enormous
                                                       5. An explanation of the iterative nature of
    changes and involve extensive interaction
                                                           systems engineering.
    with the customer.
    Thus, Shenhar and Bonen‟s work forms                   1. Reasons why systems engineers do
the basis for the risk dimension of the HKM            not agree on the roles of systems engineers
Framework at least in the lower layers of tra-         and the different definitions of systems en-
ditional systems engineering.                          gineering. The HKM Framework illustrates
    As the development of a system pro-                one reason why systems engineers have not
gresses through the system development life-           been able to agree on roles and activities is
cycle the work takes place in different areas of       that systems engineers work in different layers
the HKM Framework. The nature of the prob-             and in different phases of each layer (Areas of
lems faced by systems engineers in each area           the framework). (Cook, 2003) demonstrates
of the framework will be different because the         this in the classroom by positioning a number
problems will depend on the level of techno-           of areas in which systems engineers work as
logical uncertainty of the specific system             summarized below.
(Shenhar and Bonen, 1997). Shenhar and                          ―Traditional systems engineering cov-
Bonen also support (Martin, 1994)‟s claim                       ers Layer 2 as shown in Figure 9.
that adopting the wrong system and manage-                      Contemporary test and evaluation is
ment style may cause major difficulties during                  shown in Figure 9. The ―V‖ model can
the process of system creation. Namely, what                    be seen in the figure.
works in Area „2Ba‟ may not work in Area                        Military platforms lie mostly in Layer
„2Bd‟.Thus, a systems engineer working in                       2 with some activities in Layers 1 and
Area „2B‟ should be using methodologies ap-                     3 as shown in Figure 9
propriate to Area „2Ba‟ if it is a low technical                Information systems overlap several
risk system or Area „2Bd‟ if it is a Super-                     layers as shown in Figure 9. They
High-Technology Project.                                        comprise traditional systems integrated
                                                                out of [commercial] products interact-
  Insights from the HKM Frame-                                  ing with the business and supply chain
               work                                             layers.
    The effort spent to provide the first at-                   Capability Development lies as shown
tempt at a map of the (A) of the discipline of                  in Figure 9. This roughly corresponds
systems engineering by applying lessons                         to the investment management and re-
learned from Psychology to systems engineer-                    source management processes shown
ing, seems to be providing a useable frame-                     in Figure 2 (Arnold, 2002). The posi-
Conference on Systems Engineering Research 2007, Paper 057                                    Page 9

       Figure 4 Traditional Systems Engi-                    Figure 5 Contemporary Test and Eval-
                   neering                                                 uation

            Figure 6 Military Platforms                           Figure 7 Information Systems

        Figure 8 Capability Development                              Figure 9 Overlay of areas

        tioning of Capability Development in              If the positions of activities in the frame-
        the figure indicates that this activity is     work are overlapped, the result is as shown in
        focused in the front of the business-          Figure 9. It shows that systems engineers
        layer lifecycle. Capability Develop-           working in the different parts of the frame-
        ment also interacts with the supply            work do different tasks. Figure 9 does not
        chain level because there is a need to
        ensure enduring support to future De-          Evaluation Centre, University of South Australia,
        fence capabilities. Lastly, it interfaces      Adelaide, 2003., such a representation is, of course,
        to Layer 2 through the acquisition pro-        overly simplistic because aspects of the capability
                                                       development processes also occur further down the life-
        jects it generates1.‖                          cycle, thus a more accurate representation would be an
                                                       overlay whose colour saturation represents the degree
1                                                      of effort applied at each point in the two-dimensional
  According to Cook, S. C., Principles of Systems
Engineering - Course Notes, Systems Engineering and
Conference on Systems Engineering Research 2007, Paper 057                             Page 10

show, but anecdotal evidence indicates that            noted by Roy as “Operations research is more
systems engineers working in the different             likely to be concerned with systems in being
areas of the framework use the same words              than with operations in prospect” (Roy, 1960)
but with different meanings. For example, the          Page 22). Thus, operations research seems to
word “Capability” has different meanings in            focus on the areas in column G of the frame-
Areas „3A‟ and „2C‟. Consequently, it is no            work.
wonder they cannot agree on what systems                   4. The similarity between new product
engineering is and on what systems engineers           development and systems engineering.
do.                                                    (Priest and Sánchez, 2001) provide a descrip-
    2. A roadmap for a more complete set of            tion of the product development process as
system requirements. The traditional re-               follows:
quirements definition process focuses on the           1. Requirements definition.
functional and performance of the system in            2. Conceptual design.
its operations and maintenance phase. Treat            3. Detailed design.
the HKM framework as a road map, where the             4. Test and evaluation.
road begins in columns A or B, and ends in             5. Manufacturing.
columns G or H. This gives an explicit as-             6. Logistics, supply chain, and environment.
sumption that the system will pass though oth-         The description of each step in the product
er areas during its development lifecycle. Dur-
                                                       development process maps into the HKM
ing the requirements definition phase (Area
                                                       framework Layer 2 systems engineering life
2B) determine if any of these areas lay re-            cycle yet the words systems engineering do
quirements on the system (e.g. supply chain
                                                       not appear in the book. For example, the U-
requirements such as installation, storage, and
                                                       diagram on (Priest and Sánchez, 2001) page
transport), and if so include them in the sys-         64) shown in Figure 10 is equivalent to sys-
tem requirements.
                                                       tems engineering’s V-diagram. This is hardly
    3. The place of operations research in             surprising as the product development process
the framework. Operations research was de-             takes place in Layer 1 while traditional sys-
fined as “how to make sure that the whole sys-
                                                       tems engineering takes place in Layer 2 of the
tem works with maximum effectiveness and               framework as shown in Figure 9.
least cost” (Johnson, 1954) page xix) a goal
that many modern systems engineers would                   5. An explanation of the iterative nature
apply to systems engineering. The overlap be-          of systems engineering. Students have had
tween operations research and systems engi-            trouble grasping the concept that systems en-
neering was noted as early as 1954 when                gineering is iterative. The Egg diagram (AN-
Johnson wrote “Operations research is con-             SI/EIA-632, 1999) shows iterative activities
cerned with the heart of this control problem –        but does not clearly show how the emphasis
how to make sure that the whole systems                changes over the life cycle. The FRAT cycle
works with maximum effectiveness and least             (Mar, 1994) on the other hand provides a
cost” (Johnson, 1954) page xi). According to           clearer perspective in the context of the HKM
(Goode and Machol, 1959) page 130) “the op-            Framework. For example, the answer to the
erations analyst is primarily interested in            question of “when do we do functional analy-
making procedural changes whilst the systems           sis?” is “several times”. We use it in the „F‟
engineer is primarily interested in making             step of the FRAT cycle in each Area of the
equipment changes.” A lasting difference was           framework
Conference on Systems Engineering Research 2007, Paper 057                                 Page 11

      Figure 10 U-Shape development: flow down of design requirements and flow
                      up of testing (Priest and Sánchez, 2001)

                                                             By virtue of the HKM Framework, sys-
Summary                                                      tems engineering can fulfil (Wymore,
     This paper takes up the spirit of the chal-             1994)‟s requirement to become a disci-
lenges for the development of a theory of sys-               pline since systems engineering now meets
tems engineering (Hill and Warfield, 1972;                   Kline‟s definition of a discipline, namely it
Friedman, 2006) and describes a candidate                    has “a specific area of study, a literature,
three-dimensional framework for systems en-                  and a working community of paid scholars
gineering viewed from problem-solving and                    and/or paid practitioners” (Kline, 1995)
decision-making perspective that provides                    page 3).
Kline‟s elements of a discipline namely an
(A), (F), and (M). The paper has shown that            References
the framework has already provided insight as          Alderfer, C. P., Existence, Relatedness and
to reasons why systems engineers have a plu-                  Growth: Human Needs in Organiza-
rality of views concerning the scope and na-                  tional Settings, The Free Press, 1972.
ture of systems engineering. Research into this        Alexander, I. F. and Stevens, S., Writing Bet-
framework continues.                                          ter Requirements, Addison-Wesley,
Conclusions                                            Alleman, G. B., Large Project Management
   The conclusions from the research dis-                     as a Systems Engineering Discipline,
cussed in this paper are:                                     2005,
   While the HKM Framework does not pro-                      http://www.niwotridge.com/PMasSE/i
   vide a theory of systems engineering, it                   ndex.html, last accessed 20 December
   does provide a platform for further re-                    2006
   search into the nature of systems engineer-         Allison, J. S. and Cook, S. C., "The New Era
   ing.                                                       in Military Systems Thinking and
   The HKM Framework embodies the (A),                        Practice", First Regional Symposium
   (F) and (M) of systems engineering and                     of the Systems Engineering Society of
   hence can be considered as a candidate for                 Australia INCOSE Region 6 (SETE
   the first formal representation of the disci-              98), Canberra, Australia, 1998.
   pline.                                              ANSI/EIA-632, Processes for Engineering a
                                                              System, American National Standards
Conference on Systems Engineering Research 2007, Paper 057                              Page 12

       Institute and Electronics Industries As-                Conference, Coventry, England, 1994.
       sociation, 1999.                                Cook, S. C., Principles of Systems Engineer-
Arnold, S. (Editor), ISO 15288 Systems engi-                   ing - Course Notes, Systems Engineer-
       neering — System life cycle processes,                  ing and Evaluation Centre, University
       International Standards Organisation,                   of South Australia, Adelaide, 2003.
       2002.                                           Cook, S. C., Kasser, J. E. and Ferris, T. L. J.,
Avison, D. and Fitzgerald, G., Information                     "Elements of a Framework for the En-
       Systems Development: Methodologies,                     gineering of Complex Systems", the
       Techniques and Tools, McGraw-Hill                       9th ANZSYS Conference, Melbourne,
       Education (UK), Maidenhead, 2003.                       2003.
Badaway, M., "Educating Technologists in               Darke, P. and Shanks, G. G., "User Viewpoint
       Management of Technology", EMR                          Modelling: understanding and
       Vol (1995), Number Fall.                                representing user viewpoints during
Blanchard, B. and Fabrycky, W., Systems En-                    requirements definition", Information
       gineering and Analysis, Prentice Hall,                  Systems Journal Vol 7 (1997), Number
       1981.                                                   3, Pp: 213-219.
Bottomly, P. C., Brook, P., Morris, P. W. and          Eisner, H., Project and systems engineering
       Stevens, R., "A Study of the Relation-                  management, Wiley, 2002.
       ship of Systems Engineering to Project          Faulconbridge, R. I. and Ryan, M. J., Manag-
       Management", Fourth Annual Sympo-                       ing Complex Technical Projects: A
       sium of the INCOSE-UK, 1998.                            Systems Engineering Approach, Ar-
Brekka, L. T., Picardal, C. and Vlay, G. J.,                   tech House, Boston, 2003.
       "Integrated Application of Risk Man-            Flood, R. L. and Jackson, M. C., Creative
       agement and Cost of Quality", The 4th                   Problem Solving, Wiley, 1991.
       Annual International Symposium of               Friedman, G., "On the Unification of Systems
       the NCOSE, 1994.                                        Engineering", INSIGHT Vol 8 (2006),
Buede, D. M., The Engineering Design of Sys-                   Number 2, Pp: 16-17.
       tems, John Wiley & Sons, Inc., 2000.            Goode, H. H. and Machol, R. E., Systems En-
Chapanis, A., "Human Engineering," Opera-                      gineering, McGraw-Hill, 1959.
       tions Research and Systems Engineer-            Hall, A. D., A Methodology for Systems Engi-
       ing, C. D. Flagle, W. H. Huggins and                    neering, D. Van Nostrand Company
       R. H. Roy (Editors), Johns Hopkins                      Inc., Princeton, NJ, 1962.
       Press, Baltimore, 1960.                         Hall, C. S. and Lindzey, G., Theories of Per-
Checkland, P. and Holwell, S., Information,                    sonality, John Wiley & Sons, 1957.
       Systems and Information Systems:                Hari, A., Kasser, J. E. and Weiss, M. P., "How
       making sense of the field, vol. Chiche-                 lessons learnt from creating require-
       ster, John Wiley & Sons, 1998.                          ments for complex systems using QFD
Checkland, P. and Scholes, J., Soft Sytems Me-                 led to the evolution of a process for
       thodology in Action, John Wiley &                       creating quality requirements for com-
       Sons, 1990.                                             plex systems", Systems Engineering:
Churchman, C. W., The Systems Approach                         The Journal of the International Coun-
       and its Enemies, Basic Books, Inc.,                     cil on Systems Engineering Vol 10
       New York, 1979.                                         (2007), Number 1, Pp: 45-63.
Clausing, D. and Cohen, L., "Recent Devel-             Hauser, J. R. and Clausing, D., "The House of
       opments in QFD in the United States",                   Quality", Harvard Business Review
       Institution of Mechanical Engineering                   Vol May-June (1988), Number, Pp:
Conference on Systems Engineering Research 2007, Paper 057                             Page 13

         63-65.                                                Rochester, New York, 2005.
Hill, J. D. and Warfield, J. N., "Unified Pro-         Kasser, J. E., "Reducing the cost of doing
         gram Planning", IEEE Transactions on                  work by an order of magnitude (by ap-
         Systems, Man, and Cybernetics Vol                     plying systems thinking to systems en-
         SMC-2 (1972), Number 5, Pp: 610-                      gineering)", 21st Centre of Excellence
         621.                                                  Workshop: Challenges for life-based
Hitchins, D. K., World Class Systems Engi-                     systems development, Tokyo, Japan,
         neering - the five layer Model, 2000,                 2006.
         http://www.hitchins.net/5layer.html,          Kasser, J. E. and Massie, A., "A Framework
         last accessed 3 November 2006                         for a Systems Engineering Body of
Jackson, M. C. and Keys, P., "Towards a Sys-                   Knowledge", 11th International Sym-
         tem of Systems Methodologies", Jour-                  posium of the INCOSE, INCOSE,
         nal of the Operations Research Society                Melbourne, Australia, 2001.
         Vol 35 (1984), Number 6, Pp: 473-             Kasser, J. E. and Palmer, K., "Reducing and
         486.                                                  Managing Complexity by Changing
Johnson, E. A., "The Executive, the Organisa-                  the Boundaries of the System", the
         tion and Operations Research," Opera-                 Conference on Systems Engineering
         tions Research for Management, Vo-                    Research, Hoboken NJ, 2005.
         lume 1., J. F. McCloskey and F. N.            Kasser, J. E. and Schermerhorn, R., "Gaining
         Trefethen (Editors), The Johns                        the Competitive Edge through Effec-
         Hopkins Press, Baltimore, 1954.                       tive Systems Engineering", The 4th
Johnson, S. B., "Three Approaches to Big                       Annual International Symposium of
         Technology: Operations Research,                      the NCOSE, San Jose, CA, 1994.
         Systems Engineering, and Project              Kline, S. J., Conceptual Foundations for Mul-
         Management", Technology and Cul-                      tidisciplinary Thinking, Stanford Uni-
         ture Vol (1997), Number, Pp: 891-919.                 versity Press, Stanford, 1995.
Kasser, J. E., Applying Total Quality Man-             Maier, M. K. and Rechtin, E., The Art of Sys-
         agement to Systems Engineering, Ar-                   tems Architecting, CRC Press, 2000.
         tech House, Boston, 1995.                     Mar, B. W., "Systems Engineering Basics",
Kasser, J. E., "Systems Engineering: Myth or                   Systems Engineering: The Journal of
         Reality", The 6th International Sympo-                INCOSE Vol 1 (1994), Number 1, Pp:
         sium of the INCOSE, Boston, MA.,                      7-15.
         1996.                                         Martin, J. N., "The PMTE Paradigm: Explor-
Kasser, J. E., "The Certified Systems Engineer                 ing the Relationship Between Systems
         - It's About Time!" The Systems Engi-                 Engineering Processes and Tools", 4th
         neering, Test and Evaluation (SETE)                   Annual International Symposium of
         Conference, Brisbane, Australia, 2000.                the National Council on Systems En-
Kasser, J. E., "Systems Engineering: An Alter-                 gineering, INCOSE, San Jose, CA,
         native Management Paradigm." The                      1994.
         Systems Engineering and Evaluation            Maslow, A. H., A Theory of Human Motiva-
         Conference (SETE 2002), Sydney                        tion, Harper & Row, 1954.
         Australia, 2002.                              Maslow, A. H., Toward a Psychology of Be-
Kasser, J. E., "Introducing the Role of Process                ing, Van Nostrand, 1968.
         Architecting", The 15th International         Maslow, A. H., Motivation and Personality,
         Symposium of the International Coun-                  Harper & Row, 1970.
         cil on Systems Engineering (INCOSE),          Memory Jogger, "Memory Jogger,"
Conference on Systems Engineering Research 2007, Paper 057                             Page 14

         GOAL/QPC, Mathuen, MA, 1985.                  Biography
Mooz, H. and Forsberg, K., "Visualizing Sys-
         tems Engineering and Project Man-             Dr. Joseph Kasser has been a practising sys-
         agement as an Integrated Success",            tems engineer for more than 35 years. He is an
         The 7th Annual International Sympo-           INCOSE Fellow and the author of "Applying
         sium of the INCOSE, 1997.                     Total Quality Management to Systems Engi-
Murray, H. A., Explorations in Personality,            neering" and many INCOSE symposia papers.
         Oxford University Press,, 1938.               He holds a Doctor of Science in Engineering
Priest, J. W. and Sánchez, J. M., Product De-          Management from The George Washington
         velopment and Design for Manufactur-          University, and is a Certified Manager. He is
         ing, Marcel Dekker, 2001.                     Deputy Director and an Associate Research
Roe, C. L., "The Role of the Project Manager           Professor at the Systems Engineering and
         in Systems Engineering", The 5th An-          Evaluation Centre at the University of South
         nual International Symposium of the           Australia. He teaches online and in the class-
         NCOSE, 1995.                                  room as well as performing research into the
Roy, R. H., "The Development and Future of             nature of systems engineering and the proper-
         Operations Research and Systems En-           ties of object-oriented requirements. He is a
         gineering," Operations Research and           recipient of NASA‟s Manned Space Flight
         Systems Engineering, C. D. Flagle, W.         Awareness Award (Silver Snoopy) for quality
         H. Huggins and R. H. Roy (Editors),           and technical excellence for performing and
         Johns Hopkins Press, Baltimore, 1960.         directing systems engineering and many other
Saaty, T., Decision Making for Leaders, RWS            awards and commendations.
         Publications, Pittsburgh, PA, 1990.
Sage, A., Systems Management for Informa-
         tion Technology and Software Engi-
         neering, Wiley, 1995.
Sheard, S. A., "Twelve Systems Engineering
         Roles", The 6th Annual International
         Symposium of the NCOSE, 1996.
Shenhar, A. J. and Bonen, Z., "The New Tax-
         onomy of Systems: Toward an Adap-
         tive Systems Engineering Framework",
         IEEE Transactions on Systems, Man,
         and Cybernetics - Part A: Systems and
         Humans Vol 27 (1997), Number 2, Pp:
         137 - 145.
Wood, J. and Silver, D., Joint Application De-
         velopment, John Wiley and Sons Inc.,
Wymore, A. W., Model-Based Systems Engi-
         neering, CRC Press, Boca Raton,
Wymore, A. W., "Model-Based Systems Engi-
         neering", Systems Engineering: The
         Journal of INCOSE Vol 1 (1994),
         Number 1, Pp: 83-92.
You can also read
NEXT SLIDES ... Cancel