- Email: [email protected]
Applying Epistemology to System Engineering: An Illustration
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 by Elsevier © Published by Elsevier B.V. B.V. Selectionand/or and/or peer-review under responsibility of Georgia of Technology. Selection peer-review under responsibility of Georgia InstituteInstitute 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: [email protected].
1877-0509 © 2013 The Authors. Published by Elsevier B.V. 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 CrossCultural 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 analystcentric 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. 7. 8. 9. 10.
A tool is used to convert the use cases to Petri nets, these Petri nets represent the system requirements; All Petri nets are collected and analyzed for individual and collective consistency and completeness; Any requirements errors identified are corrected; The system architect proposes an architecture and rewrites the use cases for each viewpoint; 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 crosscultural 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.isoarchitecture.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-3109%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. 93989410, 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.
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 by Elsevier © Published by Elsevier B.V. B.V. Selectionand/or and/or peer-review under responsibility of Georgia of Technology. Selection peer-review under responsibility of Georgia InstituteInstitute 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: [email protected].
1877-0509 © 2013 The Authors. Published by Elsevier B.V. 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 CrossCultural 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 analystcentric 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. 7. 8. 9. 10.
A tool is used to convert the use cases to Petri nets, these Petri nets represent the system requirements; All Petri nets are collected and analyzed for individual and collective consistency and completeness; Any requirements errors identified are corrected; The system architect proposes an architecture and rewrites the use cases for each viewpoint; 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 crosscultural 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.isoarchitecture.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-3109%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. 93989410, 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.