Available online at www.sciencedirect.

com

Procedia Computer Science 16 (2013) 393 – 402

Conference on Syst
Eds.: C.J.J. Paredis, C. Bishop, D. Bodner, Georgia Institute of Technology, Atlanta, GA, March 19-22, 2013.

Applying epistemology to system engineering: an illustration

Reginald Ratcliff*
Georgia Tech Research Institute, 400 10th St. NW, Atlanta, GA 30332, U.S.A.

Abstract

Epistemology is a branch of Philosophy where the debates focus on the nature of knowledge and ways of knowing.
Epistemological questions and debates are often reflected in other disciplines having a strong relationship with knowledge, such
as the sciences. Furthermore, these debates may also be reflected in the practice of engineering due to its relationship with the
sciences. For example: one epistemological debate is concerned with whether different cultures know things in the same way.
The psychological sciences of Cultural Psychology and Cross-cultural Psychology reflect this debate by offering differing
answers to
observed in system engineering during requirements elicitation if the several clients of a system represent multiple cultures. Here,
fundament
the differences in knowing are unrecognized. This paper provides an illustration of how re-formulating a problem from one
discipline (system engineering) into a common root discipline (epistemology) and then to another derivative discipline
(psychology) may provide new beneficial insights.
© 2013
© 2013The
TheAuthors.
Authors. Published
Published by Elsevier
by Elsevier B.V.access under CC BY-NC-ND license.
B.V. Open
Selectionand/or
Selection and/or peer-review
peer-review under
under responsibility
responsibility of Georgia
of Georgia InstituteInstitute of Technology.
of Technology

System Engineering; Epistemology; Requirements; Cultural Understanding; Cross-Cultural Psychology; Sytem Architecture; Architecture
Framework; Viewpoints

1. Introduction and literature review

Epistemology is an area of philosophic

[1]

well as the layman or system engineer, epistemology may evoke an area of wide and lively but ethereal debate;
For
example, e ring (see for
example [2]). The contributions of epistemology to the practice of system engineering include many underlying
concepts; some with a more obvious connection, such as knowledge and requirements management practices, and
some with subtler connections such as the acceptability of test plans. (In the latter case the epistemologist may frame
) Furthermore, the path from engineering to
* Tel.: +1-404-407-7688; fax: +1-404-407-9688.
E-mail address: reggie.ratcliff@gtri.gatech.edu.

1877-0509 © 2013 The Authors. Published by Elsevier B.V. Open access under CC BY-NC-ND license.
Selection and/or peer-review under responsibility of Georgia Institute of Technology
doi:10.1016/j.procs.2013.01.041
394 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402

epistemology is not difficult to find from their definitions, definitions of engineering typically include science, and
definitions of science typically include knowledge [1]. Furthermore, the Guide to the Systems Engineering Book of
Knowledge (SEBoK) lists epistemology as one of the foundations of Integrative Systems Science and makes several
references to the epistemology-originated distinctions of tacit and explicit knowledge [3].
As the preceding illustrates, a case can be made that epistemological thought underpins core concepts of system
engineering. However, a case can also be made that epistemology is not widely recognized or utilized by the system
engineering community. For example, the SEBoK mention of epistemology cited above is also the only mention
within the document a document that intends to be comprehensive in terminology [3]. Also, while the SEBoK
does repeatedly mention tacit and explicit knowledge, no reference is made to the epistemological origins or any of
the primary promoters of these distinctions such as Polanyi and Nonaka [4], [5].
While system engineers have notably and successfully incorporated knowledge from non-e
disciplines (such as the use of biological examples in the design of robotic motion systems [6]), this paper asserts
that the potential for, and benefits of, expanding the domain of System Engineering have barely been tapped. The
possible new domain areas exist at multiple levels. Epistemologists could rather easily point out that system
engineers tend to ignore some of the tenets of epistemological discussion in, for example: the tendency to assume
there is one, or one best, solution to a problem, or even that there is only one context for a problem and solution [7].
universally
[3]. An epistemologist may well argue that even
solution space
On another level where problems and solutions are assumed to exist, system engineering appears to be both
perceived and practiced as limited in the scope of problems it can address. (An epistemologist may see this as an
artifact of the system engineering view of problem spaces.) No significant literature, either from inside or outside
the system engineering community, could be found regarding why system engineers should be tasked with, for
example, designing the U.S. health care system. Why not? It is already acknowledged by its name to be a system.
Addressing these domain questions are, however, far beyond the scope of this paper. Therefore this paper will, as an
illustration, consider a particular epistemological question as expressed in a non-engineering discipline and explore
how the subject can contribute to expanding the realm of system engineering, in terms of both the problem space
and the solution space.
The chosen epistemological debate regards whether different cultures have different ways of knowing. One
reflection of this debate can be observed in current practice of the science of psychology as the debate between
-
of psychology that exemplifies the connection with epistemology regards whether psychological measurements
(such as the incidence of depression) are valid across cultures. Berry, et al and Kim in their textbooks of Cross-
Cultural Psychology assert that such measurements can be valid if proper process and care is applied [8], [9].
However, adherents of Cultural Philosophy assert that concepts such as depression may not always be valid across
- concludes that
neither Cultural nor Cross Cultural Psychology has the final answer; in fact they may both be asking and answering
the wrong question [10]. One take-away from Boesch is clear however, cross-cultural translation of concepts can be
problematic and a translation error may even propagate unnoticed for a significant time.
Could similar translation errors occur or be unnoticed in the practice of system engineering? Epistemologists and
non-epistemologists alike may both answer that it is difficult to prove a negative, such as that such errors are not
occurring. So, how would such errors arise, and what are the risks? In system engineering, much of the current best
practices related to system architecture are embodied in the Department of Defense Architecture Framework
(DoDAF) [11]. This document was created as a requirement of the U.S. National Defense Authorization Act of 1996
(also known as the Clinger Cohen Act) [12], and is intended to serve the U.S. Department of Defense (DoD) in
acquisition of systems [11]. The financial and technical resources behind the development of the document indicates
that it includes input from many of the thought leaders of system architecture subjects as well as the considerable
knowledge gained and lessons learned by the DoD in specifying and acquiring new systems. DoDAF is, at its core,
an acquisition tool and strives to provide a framework for ensuring that complete and accurate system requirements
are developed and successfully communicated between all stakeholders of the target system [11]. One of the key
concepts of DoDAF, and of many of the alternative architecture frameworks [13], is the recognition that different
The recognition of views has been
expanded as the document develops. DoDAF version 1.5 recognized an overarching All View and three component
 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402 395

views; while DoDAF version 2.0 [11] the term viewpoint is introduced instead of view in order to be more
consistent with ISO standard 42010 and related standards, and the number of viewpoints was increased to eight.
[14] is often acknowledged
as the starting point for many of the currently promulgated architecture frameworks [13]. From the start Zachman
recognizes that different stakeholders of a system will state their requirements differently, even when describing

; who;
where; and why. The framework is evolved as a means of expressing the six questions for each of six perspectives.
DoDAF is also not the only effort currently undergoing continued development; a survey of several Information
Technology (IT) oriented architecture frameworks is presented in [15], while [13] attempts to collect a
comprehensive list of commercial and defense-sector system architecture frameworks. A leading framework in the
commercial arena is The Open Group Architecture Framework (TOGAF) [16]. All of these frameworks utilize
views or viewpoints, and the focus of these frameworks is upon developing the best set of requirements possible
within the practical constraints (e.g. time, budget) that system engineers must also consider as part of the
requirements (problem) space.
A primary reason for the focus on collecting requirements from multiple viewpoints is that requirements errors
are widely recognized as a major source of added cost in the development of systems. In a study of a U.S. Air Force
software development project, Sheldon, et al. [17], found that the greatest single source of defects was requirements
errors at 41% of all defects. Building on Sheldon and others, Leffingwell [18] in a white paper on requirements
management states that finding requirements errors in the requirements phase may provide as much as 200:1 cost
savings over finding the error in the maintenance phase. It seems fair to conclude that developing the requirements
is the first-order problem that the system engineer must solve.
In the reviewed literature on architecture frameworks there is significant discussion regarding the issue of
making sure that the requirements of all stakeholders are captured and documented. Viewpoints are a key concept in
this activity. But there was significantly less discussion regarding the issue of ensuring that requirements from
different viewpoints are consistent and produce significantly identical understanding among all stakeholders. It is
also not clear that viewpoints are intended to represent different cultures. Furthermore, the recommended activities
that use viewpoints primarily occur after an architecture has been selected [11], leading to the possibility that
incomplete or misunderstood requirements may have led to the choice of a sub-optimal architecture.
How do system requirements and viewpoints relate to our epistemological and Cultural Psychology issues? It
does not seem difficult to justify treating the various client communnities as different cultures. For many systems
there will be client communities widely recognized as different cultures. For other systems a more nuanced
definition of culture may be appropriate, such as distinction by engineering discipline. It is asserted that these can
also be considered
of a set of distinctions useful in their particular engineering practice. (In a paper that brings together epistemology,
systems, and taxonomy, Valdma [19] offers a taxonomy of information types. Valdma also points out that even
)
It can even be argued that DoDAF and other architecture frameworks recognize the significance of cultural
differences bet
does not make sense without an understanding of the cultural context.
The philosopher Heidegger also provides an argument supporting the risk of translating concepts between
cultures, especially when special-use language is involved. Although Heidegger is often condemning of many

world is wholly shaped by language [20].

component.
All of the preceding is provided to establish two points: there is a parallel between the cultural psychology
problem of cross-cultural translation and the system engineering problem of reconciling requirements across subject
domains/cultures; and modern system engineering recognizes that the reconciliation of requirements among user
cultures is important to the maximal success of a system engineering effort.
The parallel noted A rich set
of distinctions in a domain is seen as an antecedent to success in that domain. For example, Magga reports that 175 -
180 word stems for snow and ice have been identified among the North Saami people of northern Europe, and they
can combine these stems as necessary for use in description [21]. This set of distinctions provides an obvious
396 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402

advantage for survival in their environment. Sport skiers, on the other hand, will probably have a different set of
than that of the
Saami Engineers, as well as practitioners of other knowledge-based occupations, have often built up many
-
vocabulary forming a set of language tools that allow the practitioners to invoke particular distinctions (and
abstractions) relevant to their art. Such use of language is also emblematic of a culture, as is the use of idioms as
mentioned earlier. It is easy to see that in any set of system requirements originating from different client
communities there may be one or more terms that evoke different understanding between communities.
It is therefore submitted that it can be risky in the requirements development stage to not recognize the various
stakeholders of a system with their separate domain-based viewpoints as potentially different cultures. How can one
know, or even can one know, if the requirement statements purportedly regarding the same phenomena, as stated in
two separate viewpoints, actually refer to the same concept? This is where the system engineering problem, the
cultural psychology question, and the epistemological question meet.
Cultural differences among client communities have also long been recognized within the practice of
re [22]
he needs of

on a fusion of viewpoint- [23]. It is relevant to the current paper to note

that they describe the cultural differences between sociologists and software engineers (ethnography being based in
sociology) as one of the difficulties they are striving to overcome.
System engineers are also already looking outside of engineering in the use of sociology and linguistics in
developing requirements. Goguen and Linde, in one of the earlier papers to introduce ethnography and
sociolinguistics to requirements engineering, claim to be doing so as one of the first attempts to bring a scientific
basis to requirements engineering [24]
requirements elicitation> than in the pr
able to discern order within a society where the technologist may see only chaos. This ability to see order among the

Goguen and Linde also provide an interesting example of how the differences in distinctions available to
separate client communities can manifest themselves. It is reportedly common that when someone is asked to
describe how they tie their shoelaces, the results indicate linguistic incompetence. However, Goguen and Linde
point out that there is no reason to expect most people to be competent at this - tying shoelaces is an activity taught
by demonstration, not by the use of language. However, sailors, for example, perform much better at this task
because they have a rich set of distinctions and vocabulary regarding knots.
Bellman provides an additional view of how cultures in the stakeholder communities of a system evoke the use
of viewpoints [25]
paper and is recommended reading.) Bellman concludes that acknowledging cultural differences is important in the
with the following juxtaposition of ideas:
Culture emerges from localized interactions
EA [Enterprise Architecture] necessitates an enterprise-wide ethnography taking into account multiple
perspectives
Hanks et al., provide a formalized explanation using the terms of linguistics and computer science of the
potential difficulties in communicating requirements for a software system between domain experts and software
experts [26]. They include an explanation in the terms of cognitive linguistics of why domain knowledge can be so
difficult to communicate from the domain expert to the software analyst. The discussion parallels the present
discussion of distinctions, and adds a discipline-specific view of the power and nature of distinctions in dealing with
problems within a domain (culture).
An excellent example of the perils of cross-cultural communication is also provided by Hanks, et al. They report
that during the feasibility study for the application of their technique (using a navigational system) that the software
domain expert came away with a very different understanding of the meaning of bearing than the meaning intended
by the navigational domain expert. This early misunderstanding had cascading consequences, and they explain this
phenomenon in the terms of linguistics.
While there is significant recognition in the systems engineering community of the nature of the problem of
communicating requirements among different client communities, and disciplines outside of engineering have been
mined for solutions, there does not appear to be any significant work using epistemology or Culutral Psychology.
 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402 397

This paper intends to illustrate what system engineers may learn regarding this problem by borrowing from the work
of the peer body of knowledge and practice of cultural psychology.

2. The system e problem

To recap the preceding discussion as it applies to the system engineer:

Many systems have multiple client communities;
Each client community may represent both unique and overlapping subsets of the requirements for a system;
Each client community may possess an unique set of distinctions/concepts used within their community;
Architecture frameworks may represent these communities with separate viewpoints;
These communities/viewpoints may be usefully considered as different cultures;
Concept translation between cultures is problematic;
Errors in translation of concepts may result in requirements errors;
Rework required due to [27] [28]
It has now been established that requirements elicited from different cultures, or even different engineering
disciplines, may contain costly, hidden errors. If psychology [10] has shown that concepts cannot always be reliably
translated between cultures using currently popular techniques, then psychology may also offer guidance to a
solution. Howard may offer an effective approach to solving this problem [29]. Howard asserts that storytelling (or
narrative) can be useful in the practice of psychology across cultures. Howard starts with the proposal that all forms
of thought fit within his (admittedly very broad) definition of a story. For example, Howard defines science as
meaning construction through storytelling. Furthermore, the humanities, cultural knowledge, and other forms of
knowledge are also meaning construction through storytelling, although of a different type (for both the knowledge
fulfil different purposes, and therefore
they cannot be compared to determine which is better. Howard relates them to being of different species but the
same genus. Like squirrels and chipmunks they are related and coexist, but fill separate niches and one is not
inherently better than the other outside of their niche.
Here, in an epistemological sense, is the crux of the present problem: how can the requirements as knowledge
(story) of the user species type be translated to the knowledge (story) of the implementer species type? Howard also
points to a possible mitigation of this problem by weaving in ideas from epistemology, sociology, and psychology to
lay the foundation for his postulation that recognition of story as a common foundation can be exploited for difficult
tasks such as cross-cultural psychotherapy. (Howard also brings in from his references several very useful
definitions of culture. And, for the reader interested in an introduction to the interface of epistemology and science,
Howard also provides such an introduction.)
But Howard also gives a warning: many studies of the efficacy of psychotherapy have shown that it is influenced
by the cultural match between therapist and patient. However, the evidence regarding which factors are crucial to
the quality of the match is inconclusive at best. Howard speculates that the quality of the match can be better
understood by comparing the match in the context of story. The therapist that recognizes the difference or match at
the story level will be better equipped for success, even if success is achieved by referral to a therapist with a better
match.
The use of narrative will be familiar to readers practicing several requirements development disciplines for
example [30]. Use cases and multiple views are also part of a
best practice described by IEEE standard 1471 [31]. There is also significant literature, especially in software
engineering journals, regarding capturing requirements via use cases; for example, use cases are prominent in
TOGAF [16], where a use case is defined as a natural language narrative. Several publications provide methodology
for developing specifications from use cases, see [32], [33], [34]. Of special interest to the present discussion, two
articles, [35] and [36], describe how to use linguistic techniques in the analysis of use cases.

r from
the typical use in requirements engineering, it is to be noted that exact translation is not required here. Borrowing
the fundamental idea of using story or narrative as a sort of lingua franca is all that is proposed.
There is another paradigm tha

occurring during therapy: the broken narrative of the patient and the narrative as restated by the therapist [37].
398 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402

as their experience and therapeutic skills; i.e. their specialized set of distinctions, or their set of cognitive categories,
or however the observer prefers to describe what the therapist brings to the session. In the context of the system
engineer developing system requirements, this suggest the use of a canonical form for stating use cases, or the use of
linguistic tools in analysing
the actor roles in a system allows the
[38]. While this is not sufficient to guarantee an error-free set
of requirements, it is necessary. This implies that the use of some method or tool to ensure that all actor roles or
viewpoints are identified may be critical. To help address this problem, Dano, et al. [39] include an application of
Petri nets to assist in ensuring that a developed set of specifications are as complete and un-ambiguous as possible.
(For a thorough discussion of the use of Petri nets in system modelling, Peterson [40] is a valuable resource.)

propose two methods that can be used in tandem to address this problem: a table-based method for describing the
use case; and a Petri net-based method for formalizing the requirements. The former method is domain-expert
centric, and the latter is analyst centric.
Hanks, et al. [26] propose methods based upon cognitive linguistics for solving the problems of domain
knowledge translation. This paper will propose the use of a combination of the tools of Dano et al. and Hanks et al.
as a methodology for ensuring that translations are complete and consistent. However, they acknowledge that the
use of natural language in requirements elicitation is
From the preceding discussions it can be seen that both system engineers and cultural psychologists have begun
to address the problems of cross domain (cross-cultural) translation. A next step may be to determine what system
engineers can learn from cultural psychology in this area.

3. The roles of viewpoints, domains, and cultures

In considering the similar roles that viewpoints, domains, and cultures play in the various system engineering
and cultural psychology discussions reviewed, a realization arises that their distinctions may not be fully recognized,
and therefore not fully utilized. In particular the viewpoints embodied in the various architecture frameworks are not
defined according to the different domains or cultures of the users; rather they are defined from a system
architecture centric view of the problem. For example, DoDAF discusses viewpoints that are created by a system
architect, based upon a proposed architecture, and for the benefit of various client communities. DoDAF specifies a
set of viewpoints that are independent of the user communities (or cultures or domains). From what has been learned
regarding cross-cultural understanding, this may be a sub-optimal choice. The findings indicate that perhaps the
viewpoints should be created by or for the client community or domain they will serve. This leads to a very flexible
and system-specific set of viewpoints, in contrast to many of the architecture frameworks. Possible solutions include
the addition of a new type of client-specific viewpoints, or a new taxonomy of viewpoints that is designed according
to the cultures with requirements for the system. (Architecture frameworks developed for specific client
communities, such as DoDAF, may have already captured some sense of the several client communities likely to be
involved with a subject system, but the viewpoints specified still appear to be very architecture-centric. This is not
surprising given that these are architecture frameworks.)
DoDAF can be used for a more specific example to illustrate the differences between architecture framework
viewpoints and domains/cultures. DoDAF specifies the following viewpoints:
All Viewpoint
Capability Viewpoint
Data and Information Viewpoint
Operational Viewpoint
Project Viewpoint
Services Viewpoint
Standards Viewpoint
Systems Viewpoint
Human Viewpoint (NATO proposed addition)
These viewpoints represent as thei
 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402 399

attributes as viewed from differing cultures. In fact, the iterative requirements development process encouraged by
DoDAF and other frameworks could result in multiple sequential translations between subject domains and analyst-
centric viewpoints and vice-versa. So while system engineers studying requirements development have recognized
that translations between domains (cultures) is problematic, and architecture frameworks such as DoDAF and
TOGAF initially appeared to be addressing this problem with the utilization of multiple viewpoints, the problem
may have even been exacerbated.
It can be seen in the DoDAF list of viewpoints that more than one client community/domain/culture may have an
interest in expressing their own set of requirements in a particular viewpoint such as the capability viewpoint.
Therefore you could easily encounter very different cultures utilizing the same viewpoint during the requirements
development phase. But as we have learned from both cultural psychology and subject domain-oriented
requirements engineering, there can be significant pitfalls resulting from cross-cultural/cross-domain translation.
The Open Group may have provided an excellent example of the potential perils of not recognizing cultural
differences in the understanding of a concept. During research for this paper a definition of architecture in the
system engineering context was being sought. The Open Group, developers of TOGAF, provides the following:
-2000 is:
"The fundamental organization of a system, embodied in its components, their relationships to each
other and the environment, and the principles governing its design and evolution."
At the present time, TOGAF embraces but does not strictly adhere to ANSI/IEEE Std 1471-2000
terminology. In TOGAF, "architecture" has two meanings depending upon its contextual usage:
A formal description of a system, or a detailed plan of the system at component level to guide its
implementation
The structure of components, their inter-relationships, and the principles and guidelines governing
their design and evolution over time
In TOGAF we endeavor to strike a balance between promoting the concepts and terminology of
ANSI/IEEE Std 1471-2000 - ensuring that our usage of terms defined by ANSI/IEEE Std 1471-2000 is
consistent with the standard - and retaining other commonly accepted terminology that is familiar to the
majority of the TOGAF read [41]
This paper submits that the need for two or more definitions may arise due to the involvement of multiple cultures.
So far the foray into epistemology and cultural psychology has shed new light on a potential problem in common
system engineering practices regarding requirements development. In the least the discussion has helped expand the
problem and solution spaces encompassed by system engineering; at a more fundamental level it leads to a question
of whether a system architecture-centric approach such as those promoted by DoDAF, etc. serve as the best
approaches particularly in requirements elicitation and development.
From the discussion of cross-cultural translation pitfalls, one can see several potential problems in the creation of
viewpoints by the system architect, especially when based upon incomplete requirements. The potential problems
include:
There is no mechanism to ensure that all critical terms are understood the same by the architect and the viewpoint
users;
There is no mechanism to ensure that all relevant viewpoints are represented, and this is deeply related to
ensuring that all requirements are represented.

4. A proposal

While the preceding discussion has generally been high level, a proposal for developing requirements that
encompasses all of the points can be developed. The following model is one of probably many that can be proposed
to address the problems of cross-cultural translation errors:
1. A complete set of client communities is identified;
2. A viewpoint (or set of viewpoints) is created for each client community;
3. A complete set of verbs and nouns is collaboratively and explicitly defined by all client communities for use in
stating system requirements;
4. Each client community creates a set of narrative use cases as documentation of their requirements for the
system;
5. These narrative use cases are entered in a canonical form, using the developed explicitly-defined terms;
400 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402

6. A tool is used to convert the use cases to Petri nets, these Petri nets represent the system requirements;
7. All Petri nets are collected and analyzed for individual and collective consistency and completeness;
8. Any requirements errors identified are corrected;
9. The system architect proposes an architecture and rewrites the use cases for each viewpoint;
10. All parties continue to collaboratively refine the use cases, requirements, and architecture.
The first step (identifying a complete set of client communities) is critical [42], but also perhaps the most
problematic or least-well solved. Dano, et. al. [39] provide methods that can assist in verifying the completeness of
requirements.
[43] for
example, asserts that use cases cannot form a complete set of requirements, and likens use cases to Chapter Two
of a requirements document.

5. Conclusion

Having observed the potentially severe costs of misunderstood requirements, specifically those due to cross-
cultural misunderstanding, such as those encountered in the practice of system development, this paper has returned
to one of the philosophical roots of engineering (epistemology) and found another related area of practice
(psychology) that has faced a similar problem. From the observations and solutions developed for the psychology
problem a proposal for avoiding the problem in system engineering has been developed.
In the literature search it was also found that other system engineers have tackled various aspects of the problem,
sometimes in methods similar to those developed here, and their valuable work is also included in the proposal.
Possibly, however, the primary value of the work done in this paper is the path taken to seek out a new solution; that
of following a path through a taxonomy of knowledge-based practices in order to find and include lessons learned
elsewhere.

6. Further work

This study touched upon several system engineering problems associated with having multiple client
communities for the system of interest; one of these is the problem of identifying all of the relevant client
communities prior to or during requirements elicitation. For many system types a re-usable list of potential client
communities can be developed; however, with the expansive definitions of a system being used today there remain
many potential systems without well understood sets of client communities. This area appears ready for further
investigation.
As noted earlier in this paper use cases alone are not always seen as capable of fully representing a set of
requirements, the search through epistemology may be directed towards other methods of requirements elicitation
and definition.
The proposed requirements development model may be impractical or cost-prohibitive for some system
engineering projects. The development of scaling methods or alternative models may be fruitful areas of
investigation.

Acknowledgements

I would like to acknowledge Dr. Kamran Moghaddam of Southern Polytechnic State University for his guidance
and support in the preparation of this paper.

References

[1] Merriam-Webster. (2012, February) Merriam-Webster.com. [Online]. www.merriam-webster.com

[2] Dieter Fensel, Spinning The Semantic Web: Bringing The World Wide Web To Its Full Potential. Cambridge,
MA: MIT Press, 2004.
[3] A. Pyster et al., Eds., Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0.1. Hoboken,
 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402 401

NJ: The Trustees of the Stevens Institute of Technology, 2012, ©2012. Available at:
http://www.sebokwiki.org.
[4] Michael Polanyi, The Tacit Dimension. Chicago, IL: University of Chicago Press, 1966.
[5] Ikujiro Nonaka, The knowledge creating company: how Japanese companies create the dynamics of
innovation. New York, NY: Oxford University Press, 1995.
[6] National Science Foundation. National Science Foundation. [Online].
http://www.nsf.gov/news/special_reports/robotics/robots.jsp
[7] Andrew P. Sage and James E. Armstrong Jr., Introduction to Systems Engineering. Hoboken, NJ: John Wiley
& Sons, Inc., 2000.
[8] John W Berry, Ype H Poortinga, Marshall H Segall, and Pierre R Dasen, Cross-cultural psychology: Research
and applications (2nd ed.). Cambridge: Cambridge University Press, 2002.
[9] U. Kim, "Indigenous, cultural, and cross-cultural psychology: A theoretical, conceptual, and epistemological
analysis. Asian Journal of Social Psychology," Asian Journal of Social Psychology, vol. 3, pp. 265 287, 2000.
[10] Ernest E. Boesch, "The Seven Flaws of Cross-Cultural Psychology. The Story of a Conversion," Mind, Culture,
and Activity, vol. 3, no. 1, pp. 2-10, 1996.
[11] DoD. (2010, August) DoD Architecture Framework Version 2.02. [Online]. http://dodcio.defense.gov/sites/dodaf20/
[12] CIO. (2012) About CIO.gov. [Online]. http://www.cio.gov/module.cfm/node/about/
[13] ISO. (2012, January) Survey of Architecture Frameworks. [Online]. http://www.iso-
architecture.org/42010/afs/frameworks-table.html
[14] J. A. Zachman, "A Framework for Information Systems Architecture," IBM SYSTEMS JOURNAL, vol. 26, no.
3, pp. 276-292, 1987.
[15] Abdullah S Alghamdi, "A Review of Commercial Related Architecture Frameworks and their Feasibility to
C4I System," European Journal of Scientific Research, vol. 40, no. 1, pp. 43 -49, 2010.
[16] The Open Group. (2012) The Open Group Architecture Forum. [Online]. http://www.opengroup.org/togaf/
[17] Frederick T. Sheldon et al., "Reliability Measurement: From Theory to Practice," IEEE Software, pp. 13-20,
1992.
[18] Dean Leffingwell. (1997) IBM - Rational White Papers. [Online].
ftp://service.boulder.ibm.com/ps/software/rational/web/whitepapers/2003/roi1.pdf
[19] M. Valdma, "A General Classification of Information and Systems," Oil Shale, vol. 24, no. 2, pp. 265-276,
2007.
[20] Martin Heidegger, On the Way to Language. New York, NY: Harper and Row, 1971.
[21] O. H. Magga, "Diversity in Saami Terminology for Reindeer and Snow," International Social Science Journal,
vol. 58, no. 1, pp. 25-34, March 2006.
[22] Bashar Nuseibeh and Steve Easterbrook, "Requirements Engineering: A Roadmap," in Proceedings of the
Conference on The Future of Software Engineering, New York, NY, USA, 2000, pp. 35-46.
[23] S. Viller and I. Sommerville, "Social Analysis in the Requirements Engineering Process: from Ethnography to
Method," in Proceedings. IEEE International Symposium on Requirements Engineering, 1999., Limerick ,
Ireland, 1999, pp. 6-13.
[24] J.A. Goguen and C. Linde, "Techniques for Requirements Elicitation," in Proceedings of IEEE International
Symposium on Requirements Engineering, 1993, 1993, pp. 152 - 164.
[25] Beryl Bellman. (2009, Oct.) INCOSE. [Online]. http://www.incose.org/Chicagoland/docs/SanDiego/10-31-
09%20Managing%20Organizational%20Complexity%20-
%20Enterprise%20Architecture%20and%20Architecture%20Frameworks%20with%20an%20Overview%20of%20their%20Products,%20
Artifacts%20and%20Models.pdf
[26] Kimberly S. Hanks, John C. Knight, and Elisabeth A. Strunk, "A Linguistic Analysis of Requirements Errors
and its Application," Charlottesville, VA, Technical Report 2001.
[27] Raymond Dion, "Process Improvement and the Corporate Balance Sheet," IEEE Software, vol. 10, no. 4, pp.
28-35, 1993.
402 Reginald Ratcliff / Procedia Computer Science 16 (2013) 393 – 402

[28] B.W. Boehm and P.N. Papaccio, "Understanding and Controlling Software Costs," Software Engineering,
IEEE Transactions on, vol. 14, no. 10, pp. 1462-1477, 1988.
[29] George S. Howard, "Culture tales: A narrative approach to thinking, cross-cultural psychology, and
psychotherapy.," American Psychologist, pp. 187-197, 1991.
[30] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modelling Language User Guide. Reading, MA:
Addison-Wesley, 1999.
[31] Ralph R. Young, The Requirements Engineering Handbook. Norwood, MA: Artech House, Inc., 2004.
[32] Tao Yue, Lionel Briand, and Yvan Labiche, "A Use Case Modeling Approach to Facilitate the Transition
towards Analysis Models: Concepts and Empirical Evaluation," in Model Driven Engineering Languages and
Systems. Berlin: Springer, 2009, pp. 484-498.
[33] Narasimha Bolloju, Christoph Schneider, and Su Vijayan, "A Knowledge-Based System for Improving the
Consistency Between Object Models and Use Case Narratives," Expert Systems with Applications, pp. 9398-
9410, August 2012, Available online 22 Febraury 2012.
[34] Y. Al-Hroub, M. Kossmann, and M. Odeh, "Developing an Ontology-driven Requirements Analysis Tool
(OntoRAT): A Use-Case-Driven Approach," in Applications of Digital Information and Web Technologies
2009. ICADIWT '09. Second International Conference on the, London, 2009, pp. 130-138.
[35] A. Fantechi, S. Gnesi, G. Lami, and A. Maccari, "Application of Linguistic Techniques for Use Case
Analysis," in ,
Monterey Bay, CA, 2002.
[36] F. Fabbrini, M. Fusani, S. Gnesi, and G. Lami, "The Linguistic Approach to the Natural Language
Requirements Quality: Benefit of the Use of an Automatic Tool ," in Software Engineering Workshop, 2001.
Proceedings. 26th Annual NASA Goddard, 2001, pp. 97-105.
[37] John McLeod, "The Emerging Narrative Approach to Counselling and Psychotherapy," British Journal of
Guidance & Counselling, pp. 173, 12p, 1996.
[38] Timothy D. Korson, "Constructing Useful Use Cases," Component Strategies, pp. 27-28, March 1999.
[39] Benedicte Dano, Henri Briand, and Franck Barbier, "An approach based on the concept of use case to produce
dynamic object-oriented specifications," in Proceedings of ISRE '97: 3rd IEEE International Symposium on
Requirements Engineering, Annapolis, MD, 1997, pp. 54-64.
[40] J. L. Peterson, Petri Net Theory and the Modeling of Systems. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1981.
[41] The Open Group. (2006) The Open Group. [Online]. http://pubs.opengroup.org/architecture/togaf8-doc/arch/
[42] I. F. Hooks and K. A. Farry, Customer- Centered Products: Creating Successful Products through Smart
Requirements Management. New York: AMACOM, 2001.
[43] A. Cockburn, Writing Effective Use Cases, The Crystal Collection for Software Professionals. Boston:
Addison-Wesley, 2001.