Paper Menu >>
Journal Menu >>
J. Software Engineering & Applications, 2010, 3: 487-494 doi:10.4236/jsea.2010.35055 Published Online May 2010 (http://www.SciRP.org/journal/jsea) Copyright © 2010 SciRes. JSEA Research on Knowledge Creation in Software Requirement Development* Jiangping Wan1,2, Hui Zhang1, Dan Wan1, Deyi Huang3 1School of Business Administration, South China University of Technology, Guangzhou, China; 2Institute of Emerging Industrializa- tion Development South China University of Technology, Guangzhou, China; 3E-jing Technologies, Hong Kong Science Park Shatin, Hong Kong SAR. Email: {scutwjp, dandanwan42}@126.com, shidelan@163.com, huangdy3816@tom.com Received February 3rd, 2010; revised March 15th, 2010; accepted March 17th, 2010. ABSTRACT After field survey and literature review, we found that software requirement development (SRD) is a knowledge creation process, and knowledge creation theory of Nonaka is appropriate for analyzing knowledge creating of SRD. The characteristics of knowledge in requirement elicitation process are analyzed, and dissymmetric knowledge of SRD is discussed. Experts on requirement are introduced into SRD process as a third knowledge entity. In addition, a knowledge creation model of SRD is put forward and the knowledge flow and the relationship of entities of this model are illustrated. Case study findings are illustrated in the following: 1) The necessary diversity of the project team can facilitate the implementation of the SRD. 2) The introduction of experts on requirement can achieve the transformation of knowledge effectively, thus helping to carry out the SRD. 3) Methodology and related technologies are important for carrying out the SRD. Keywords: Requirement Engineering, Knowledge Creation, Dissymmetric Knowledge, Knowledge Conversion, Experts on Requirement, Methodology 1. Introduction Michael Polanyi divided knowledge into tacit knowledge and explicit knowledge [1]. Tacit knowledge exists in human brains, which is the knowledge that people don’t know, in other words people don’t know what they know. Verna Allee thought that tacit knowledge which exists in individuals is private and has its own special background, and it also depends on experience, intuition and discern- ment [2]. Nonaka figured that organizations create and make use of knowledge via the interaction of tacit knowledge and explicit knowledge, which is called knowledge conversion process [3]. Li Xiao-Ming et al. analyzed the requirement elicitation process (REP) in the view of knowledge management and put forward the countermeasures. In our understanding, it is necessary to discuss how knowledge is converted during REP in details, and present an embodying knowledge conversion pattern [4].Wan Jiangping researched on the knowledge integra- tion support structure of quality software production [5], and established knowledge transfer model of software process improvement (SPI) and the conceptual framework of influencing factors [6]. This paper is organization as following: we firstly analyze the characteristics of knowledge during REP; then based on characteristics of SECI (socialization, exter- nalization, combination, and internalization) knowledge spiral model, dissymmetric knowledge flow theory and knowledge communication, a knowledge conversion mo- del is put forward, which is used to analyze the require- ments development process of the NY Company’s cost accounting system. 2. Literature Review 2.1 Tacit Knowledge and Knowledge Conversion Organizational knowledge creation is the process of making available and amplifying knowledge created by individuals as well as crystallizing and connecting it to an organization’s knowledge system. The concept of “tacit knowledge” is a cornerstone in organizational knowledge creation theory and covers knowledge that is unarticulated and tied to the senses, movement skills, physical experi- ences, intuition, or implicit rules of thumb. Knowledge of wine tasting, crafting a violin, or interpreting a complex *This research was supported by Key Project of Guangdong Province Education Office (06JDXM63002), NSF of China (70471091), and Q ualiPSo ( IST- FP6-IP-034763 ) Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 488 seismic printout of an oil reservoir are well-known ex- amples of tacit knowledge. The concept of “knowledge conversion” explains how tacit and explicit knowledge interact along a continuum. Nonaka argued that knowl- edge is created and used in organization through knowl- edge is transformed process, including four patterns: so- cialization, externalization, combination, and internaliza- tion. All four of these patterns exist in dynamic interaction. Knowledge is really and truly created and used effectively and effectively depending on dynamic business system is established [3,7]. There nine questions are put forward in the following [8]: 1) What is the status of “truth” in the definition of knowledge? 2) Do tacit and explicit knowledge fall along a continuum? 3) Is the tacit/explicit knowledge distinction along the continuum valuable for organization science? 4) What is the conceptual basis of knowledge conversion? 5) Given the relationship between tacit knowledge and social practices, how can the concept of knowledge conversion be upheld? 6) What is the outcome of knowledge con- version? 7) What is the relationship between organiza- tional knowledge creation and social practices in organi- zations? 8) When and why do social practices contribute to the conservation of existing tacit knowledge and ex- isting routine rather than organizational knowledge crea- tion and innovation? 9) How can leadership motivate and enable individuals to contribute to organizational know- ledge creation by transcending social practices? 2.2 Enabling Knowledge Creation There five knowledge enablers in the following: 1) Instill a knowledge vision, 2) Manage conversations, 3) Mobi- lize knowledge activists, 4) Create the right context, and 5) Globalize local knowledge. The effective knowledge creation depends on an enable context. What we mean by enabling context is shared space that fosters emerging relationships. This definition of context is connected to our first two points: knowledge is dynamic, relational, and rather than on absolute truth or hard facts. The essential thing for managers to remember is that all knowledge, as opposed to information or data, depends on its context. There are the five knowledge-creation steps in the fol- lowing: 1) Sharing tacit knowledge, 2) Creating concepts, 3) Justifying concepts, 4) Building a prototype, and 5) Cross leveling knowledge [9]. 2.3 Software Requirements Engineering Requirements engineering (RE) is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families [10]. There are five core RE activities in the following: 1) Eliciting requirements, 2) Modeling and analyzing re- quirements, 3) Communicating requirements, 4) Agree- ing requirements, and 5) Evolving requirements. This paper analyzes the eliciting requirements. 2.4 Characteristics of Knowledge in Software REP REP is actually a process of developing conditions that satisfied people in the following: 1) Understanding re- quirements; 2) Participating in this project (in most cases); 3) Understanding how to work effectively as a team [11].The generic process of requirement elicitation is illustrated in Figure 1. First, we work with our customers to elicit the requirement, by asking questions, demon- strating similar systems, or even developing prototypes of all or part of the proposed system. Next, we capture those requirements in a document or database. Then, the re- quirements are often rewritten, usually in a more mathe- matical representation, so that the designers can transform the requirements into a good system design. A verification and validation step makes sure that the requirements are complete, correct, consistent, and the requirements are what the customer intends to [12]. In software REP, besides the requirements that clients or users are able to bring forward, they also have re- quirements that could not be clearly expressed. The characteristics of software tacit requirements are summed up in the following: 1) Tacit requirements are hard to express, convert, communicate and share; 2) Tacit re- quirements are often related to application domain; 3) Tacit requirements are often users’ tacit knowledge; 4) Tacit requirements are experiential knowledge which developing team accumulates step by step in practice during a long period of time; 5) Tacit requirements are hard to encode and articulate; 6) Tacit requirements can be expressed hazily and crudely. 3. Establishment Knowledge Creation in Software REP 3.1 Software REP in the View of SECI Knowledge Spiral Model SECI Knowledge Spiral Model illustrates the relationship between tacit knowledge and explicit knowledge and how they convert into each other, and it also illustrates the way tacit knowledge and explicit knowledge convert and share. Finally new knowledge is created in this conversion process. 1) Socialization: It is tacit knowledge from individual to individual, and in the process people actualizes the expression and conversion of knowledge by means of observation, imitation, etc. In software REP, knowledge socialization includes the internal conversion between users’ knowledge, which is the principal part and the external conversion of tacit knowledge among users, Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 489 Problem analysis Problem description Prototyping and testing Documentation and validation Requirement elicitation and analysis Have we captured all the user need? Are we using the right techniques or views? Is this function feasible? How we captured what the user expects? Requirement definition and specification Figure 1. Software REP experts on requirement, and developers. Finally they all reach consensus. 2) Externalization: It is the conversion from tacit knowledge to explicit knowledge, expressing tacit know- ledge written down or stored in computer, etc. In software REP, mainly with the help of experts on requirement or consultants, knowledge externalization is the process in which users’ tacit knowledge is converted into explicit knowledge, which could be directly accepted by devel- opers. 3) Combination: It is the process from separate ex- plicit knowledge to systematic explicit knowledge in which explicit knowledge is further systematized and complicated. It involves different kinds of external ex- plicit knowledge system. In software REP, with knowl- edge of experts on requirement further systematized, developers integrate their own knowledge to make the requirements specification. 4) Internalization: It is the process from explicit knowledge to tacit knowledge; in the process individuals digest and adsorb the knowledge from different mediums, and make it into their own abilities. In software REP, experts on requirement pass the combined explicit knowledge (requirements specification or prototype) to users who may consequently have a further understanding of the system. 3.2 Analysis of Dissymmetric Knowledge Flow Because of dissymmetric knowledge, knowledge flows from high knowledge level to low knowledge level (Figure 2). There are two main knowledge flows: the one from users to developers is mainly knowledge in business domain and other users’ tacit knowledge, while the other one from developers to users is knowledge in software domain and system performance requirements, etc. The flow of dissymmetric knowledge makes the con- version of knowledge type, namely integrating the knowledge of developers and users and making users’ tacit knowledge articulate to form their very requirements, which are the critical parts of REP. After feeding back, the integrated knowledge flows to users, and then when it is confirmed, REP is initially finished. But this does not imply that the REP is ended; on the contrary, during the whole process, software requirements are gradually up- dated along with feedbacks of information from different stages [13]. Software REP is the process in which users, experts on requirement, developers and other demand sources communicate their information and knowledge, and it is also the process in which the knowledge of users, experts on requirement and software developers are integrated. Because of users’ participation, experts on requirement and developers may absorb users’ information to make it into knowledge, and update their knowledge with their experience, cooperation value, project goals and business principles, which may reach the goal of requirement elicitation. Therefore, REP is the process of knowledge flow, integration and innovation. Meanwhile, users im- prove themselves continuously in the process of knowl- edge flow. 3.3 Conditions for Knowledge Conversion In software REP, the face-to-face communication which is aimed at knowledge conversion is different from generic communication [14], firstly, the two parties are quite dissymmetric in knowledge; then the communication is to elicit users’ tacit knowledge and show developers’ soft- ware knowledge; finally, the process of communication is an iterative negotiation process. In the communication for requirement elicitation, users, experts on requirement, developers and relevant personnel should clearly understand each element in successful knowledge conversion, and only the honest speakers who own knowledge and listeners who trust and understand speakers may interact to reach the goal of knowledge conversion and tacit knowledge elicitation[15]. 3.4 Model of Knowledge Conversion in REP Based on SECI The model of knowledge conversion in REP based on SECI is illustrated in Figure 3. In software REP, the externalization process of tacit requirements is the process in which users and developers communicate via experts on requirement. As the central part in REP, experts on requirement not only listen atten- tively to users’ requirements and developers’ description of technologies and computer, but also win the trust of users and developers as authorities and able persons, Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 490 Developers’ tacit knowledge Developers Expression of knowledge in software domain Integrated requirements accumulating, tacit knowledge articulating Users’ tacit knowledge Expression of knowledge in business domain Users Feedbacks from developers Feedbacks from users Themselves Improvement Figure 2. Flows of dissymmetric knowledge Externalization Socialization Combination Internalization Experts on requirement and system analysts Developers Requirements specification or prototype and develo p s’ knowled g e Experts on requirement and system analysts Users Feedback Explicit requirements and users’ knowledge Requirements specification and developers’ knowledge Users’ requirements and knowledge Figure 3. Model of knowledge conversion in REP based on which they put forward users’ tacit requirements in a way that developers can easily understand and accept, and present developers’ solution in a way that users can easily understand and accept. REP is a multi-stage process of knowledge conversion and implementation. In this iterative conversion process, experts on requirement who master “logic” domain knowledge face users and developers. They may perform concept design, decomposition and requirement integra- tion for users, while performing consistency analysis, knowledge optimization and flexibility processing for developers. Owning to the dissymmetry of knowledge level, high-level knowledge flows to low-level knowledge, users’ business domain knowledge and other tacit knowledge to developers, and developers’ software do- main knowledge to users. Experts on requirement bring users’ knowledge to developers. Developers analyze re- quirements, feed back to users and experts on requirement, accept their feedbacks, and finally produce requirements specification, making the process of combination. After requirements specification is formed, experts on re- quirement make explanation to users and provide relevant training, making the process of knowledge internalization. In each step of SECI, participations should apply other four steps to creative thinking in the following: prepara- tion, incubation, illumination, and verification [16]. 3.5 Keys to Model of knowledge Conversion in REP Based on SECI When using the model of knowledge conversion in REP based on SECI to guide requirement elicitation, there is something should be paid attention to in the following: 1) Choose the experts on requirement who are familiar with users’ business domain and are trusted by both developers and users. 2) Users should take part in the REP actively, at least appointing customer representatives, including user mouthpieces and system users, etc. 3) Experts on re- quirement should make an observation and have a dis- cussion with both users and developers on the spot. 4) The requirements specifications made by experts on require- ment should be the negotiation by the three parties and be validated by users and developers. 5) Experts on re- Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 491 quirement should participate in the whole process of re- quirement elicitation, and harmonize all kinds of conflicts between users and developers. 6) All activities require a right context, called “Ba” in Japanese [9], such as creative workshops [16], meeting, and so on. 4. Case Study 4.1 Overview The NY Company was founded in 1986 and has two branches now. In November 2006, NY Company’s top executives contacted managers of JZ Company and ini- tially established the project through the communication of the two sides. JZ Company was committed to achieve the initial system within 3 months and chose the branch as a pilot test run. 4.2 Asymmetry of the Project Knowledge The NY Company is not satisfied with the system vision and planning established by the software providers. This issue is largely from software provider’s deficient under- standing of the business processes of the catering industry, particularly in its cost accounting processes. On the other hand, NY Company has deficient or inaccurate under- standing of the software (Table 1). 4.3 The Requiring Expert of the Project The project was officially approved by the project team in November 2006, including the NY Company as the cus- tomer, the JZ Company as the experts on requirement, and the SY Company as the developer. The knowledge traits of the three parties in the project team are illustrated in Table 2. Firstly, JZ Company determines what system that NY Company needs and what system SY company should provide. JZ Company further deepens the requirements NY Company proposed. They analyze the project in the view of the entire company and identify the cost ac- counting containing operating costs, inventory costs, purchasing costs, as well as costs monitoring and budg- eting, not just a simple ordering system or accounting analysis. Secondly, JZ Company also needs to analyze clearly what software system is compatible with the NY Company, transforming the enterprise business processes into a computer system processing and the computer’s function modules into enterprise business functions. 4.4 Knowledge Creation Process in the Project 4.4.1 Situation of the Project Team JZ organizes formal meetings within the project team actively, such as project-startup meeting, various seminars, weekly meetings, periodic meetings, etc. And the experts on requirements will keep a record for each meeting and store them into the project database as backup. 4.4.2 Project Process NY Company introduced their initial requirements to JZ Company, including cost management businessprocess diagrams and related reporting requirements, and clarified them in depth and carried out business training. JZ Company investigated respectively inspecting de- partment, financial department, administrant department and had in-depth interviews with relevant personnel. JZ Company’s staff has a good knowledge of accounting, business management knowledge, and system planning knowledge, so during the interview process they could soon be able to reach a consensus with the NY company personnel to develop the “Investigation and Analysis Specification of NY Company’s Cost Accounting Sys- tem.” The specification clearly identified the main objec- tive of the system, outlined the NY Company’s organiza- tional structure, identified the enterprise’s overall opera- tional processes, analyzed carefully the management of the catering industry and established the internal proc- esses of the cost-accounting system (Figure 4), which divided the system into six modules, i.e. namely data collection, cost data, report output, initialization, query, system management and also encoded the information in the processes. After communication with the general manager of NY Company, it was clarified that the system would be used by the inspecting department, while the financial department would only use it for data queryand the administrant department would collect data. System requirements would be mainly determined by the in- specting department. JZ Company exchanged ideas with NY Company and illustrated the figure so that both the two parties could understand and accept it. At the same time, the “NY Table 1. Asymmetry of the project knowledge Customer Developer Asymmetry of direction 1. A system contributing to control the cost. 1. It is not started from the information systems of the entire enterprise. 2. The goal of the system is not defined correctly, thinking it is just an ordering system. Asymmetry of distance 1. What the software system can do for cost control is not clearly learnt. 2. Lack the computer system knowledge. 3. Clear about the daily operating processes of the ca- tering industry. 1. Deficient understanding of the cost management in catering industry; Unclear about how to control the cost and which part to control. 2. Lack the cost management business processes knowledge. 3. Well-informed of the software development Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 492 Educed receipts Educed stocktaking bill Educed material Requisition form Treat leading material requisition form as warehouse-moving bill Collect and dispose materials counted by type, e.g. vegetable, meat Keep accounts Calculate warehouse's cost of goods sold Calculate each stall's revenue and cost Calculate each stall's material using amount Calculating form of converting primary material to the secondary mat erial Sales data of menu Primary material consuming dosage of menu Record sum of primary material converted to secondary material Subsection cost adjustment Calculate each stall's actual cost of goods sold Subsection cost consuming table Calculate each stall's cost of menu Calculate the disparity between planned cost and actual cost Figure 4. Internal processes of cost accounting system Table 2. Knowledge traits of the three parties in the project team Knowledge traits Customer()NY Operating and cost management knowledge of catering industry Developer()SY Software and system developing knowledge Requirements ex- perts()JZ Organization management knowledge, cost-control knowledge, system design and developing knowledge , project management knowledge and ability, requirements acquiring knowledge and ability Company’s Cost Accounting System Design Specifica- tion V1.0” and simple system prototype, which included the interface, the core module and so on, were completed. JZ company and SY company further refined the re- quirements, forming the “NY Company’s Cost Account- ing System Design Specification V2.0” and the improved system prototype, and trained the customers. The three parties signed on the “NY Company’s Cost Accounting System Requirements Specification” and “NY Com- pany’s Cost Accounting System Design Specification”, confirming the system entering into construction phase. The key to effectively realizing requirements’ trans- formation and requirements’ knowledge creation are il- lustrated in Table 3(a) & Table 3(b). 1) The three parties of the project should have mutual trust and actively par- ticipate in the project process, and basing on a clear pro- ject objective carry out the project with a detailed project plan. The appropriate methodology and technology should be adopted rather than merely seeking advancing. Face to face communication is mainly used while thoughts can be expressed in the form of prototype, en- suring effective communication and avoiding unnecessary confusion. 2) JZ Company needs to construct a platform for requirements’ transformation and lead the entire pro- ject process. JZ Company conducts a comprehensive and in-depth analysis to NY company, including organiza- tional structure, status of existing enterprises’ information technology and so on, understands the cost accounting systems in the view of the whole organization and pro- poses extensible project blue print. Meanwhile, it should integrate professional knowledge of cost accounting, business operating knowledge and computer knowledge Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 493 Table 3(a). Requirements creation process Project phase Project proposing Project preparation Project initiation Relevant data collection Requirements educing Requirements classification Participators Customer Customer, other software providers Customer, experts on requirements, developers Experts on requirements, customer Experts on requirements, customer Experts on requirements , developer Requirements statement Meeting consensus Relevant document Project objectives, initial cost management business process Organizational structure, “NY company’s proposal of informationization” “Survey and analysis of NY company’s cost accounting system”, “ General plan of NY company’s cost accounting system project” “Resolution to NY company’s cost accounting system”, “ Interface specification of NY company’s cost accounting system” Knowledge phase Customer internalization and socialization Project socialization Internalization and socialization Externalization Key problems Enterprise development needs, executives strongly demand In-depth learning about system through several contacts with software providers Guidance for experts on requirement, acquiring customer’s trust Comprehensive investigation on company’s struc- ture, culture, exist- ing systems, busi- ness processes, etc. Adopt some requirements educing technology, e.g. Old system analysis, seminar, questionnaire survey, interview, etc. Identify functional requirements and nonfunctional requirements, such as restriction, performance, revisability and so on Table 3(b). Requirements creation process Project phase Initial modeling Requirements discussion Model refinement Requirements validation System realization System test-run Requirements alteration Participators Customer, requirements experts Experts on requirements, developer, customer Experts on requirements, developer Experts on requirements, developer, customer Developer Experts on requirements, developer, customer Experts on requirements, developer, customer Requirements statement “NY company’s cost accounting system design specification V1.0”, simple system proto-type, including the inter-face, the core module, etc. “Summary specification of NY company’s cost accounting system discus- sion” “NY company’s cost accounting system design specification V2.0”, the improved system prototype “NY company’s cost accounting system requirements specification”, “NY company’s cost accounting system design specification” NY company’s cost accountting management system, “test report”, “specifiction of system installation, setting, uninstall or upgrading” and relevant document “NY company’s cost accounting system’s user manual”, “NY company’s cost accounting system’s test-run report” “NY company’s cost accounting system requirements alteration specification” Knowledge trans- forming phase Combination Combination, externalization, internalization Combination Internalization Combination (realization) Internaliza- tion Requirements’ transformation Key problems Use dynamic displaying document Arrange special seminars to discuss the topics Develop workable prototype, perfect system design specification Take the requirements specification and system design as the original source to validate the project Experts on requirements monitor the system realization as customer representa- tives Research on Knowledge Creation in Software Requirement Development Copyright © 2010 SciRes. JSEA 494 and ability, and reduce the knowledge asymmetry be- tween NY Company and SY Company. 4.5 Summary The conclusions are in the following: 1) Friendly project environment. The three parties were very friendly, and in the course of the project gradually established a mutual trust relationship. 2) Executives’ high consideration and the relevant members’ active participation in the project. As customer exactly knew the project objectives and was very concerned about this project, so they actively par- ticipated in the project and cooperated with other mem- bers well. 3) Clear project objectives and plan. Face to face communication was mainly used to communicate the project so as to avoid unnecessary chaos and individual blind autonomy. The project team also encouraged in- formal communication, and the communication process should be recorded and summarized. 4) Introduction of requiring expert reduces knowledge asymmetry. Special- ists are knowledgeable, well-informed of accounting knowledge, business management knowledge and soft- ware knowledge, so they play a role of knowledge com- munication platform. 5) Appropriate project management methodology and technology. If the team is wild about advanced methodology in the really critical project, the project will often end up with failure. That is because introduction of advanced methods and concepts is often a gradual process that requires adaptation. Furthermore, experts on requirement are good at project management, helping to carry out the project orderly. 5. Conclusions In software REP, the knowledge of both the users and developers can be divided into explicit knowledge and tacit knowledge, and REP is an iterative process of knowledge socialization, externalization, combination and internalization. Knowledge dissymmetry is one of the forces that drive knowledge conversion. The model of knowledge conversion in REP based on SECI is put for- ward. Depending on experts on requirement, this model can reduce knowledge dissymmetry, and realize knowl- edge conversion and share more effectively and effi- ciently. This model is used to analyze the requirements development project of the NY Company’s cost ac- counting system. Case study findings are in the following: 1) It can facilitate the implementation of the project to have the necessary diversity of the project team. 2) The introduction of requiring expert can achieve the trans- formation of knowledge effectively, thus helping to carry out the SRD. 3) Methodology and related technologies are important for carrying out the SRD. 6. Acknowledgements Thank for helpful discussion with Mr. Li Jiangzhang, Mr. Chen Zhening, Mr. Wang Shuwen, Mr. Liu Bing, Brenda Huang etc. REFERENCES [1] M. Polanyi, “Personal knowledge,” University of Chicago Press, Chicago, 1958. [2] V. Allee, “The Knowledge Evolution: Expanding Organi- zational Intelligence,” Butterworth Heinemann, Boston, 1997. [3] I. Nonaka, “The Knowledge Creating Company,” Harvard Business Review, Vol. 69, No. 6, 1991, pp. 96-104. [4] X. M. Li, et al. “Research on Software Requirement Management based on Knowledge Management,” R&D Management, Vol. 2, 2005, pp. 28-39. [5] J. P. Wan, “Research on Software Product Support Structure,” Journal of Software Engineering and Appli- cations, Vol. 2, No. 3, 2009, pp. 174-194. [6] J. P. Wan et al., “Research on Knowledge Transfer Influencing Factors in Software Process Improvement,” Journal of Software Engineering and Applications, 2010, Vol. 3, No. 2, 2010, pp. 134-140. [7] I. Nonaka, “A Dynamic Theory of Organizational Kno- wledge Creation,” Organization Science, Vol. 5, No. 1, 1994, pp.14-37. [8] I. Nonaka and V. K. Georg, “Perspective—Tacit Knowledge and Knowledge Conversion: Controversy and Advancement in Organizational Knowledge Creation Theory,” Organization Science, Vol. 20, No. 3, 2009, pp. 635-652. [9] V. K. Georg, et al. “Enabling Knowledge Creation: How to Unlock the Mystery of Tacit Knowledge and Release the Power of Innovation,” Oxford University Press, New York, 2000. [10] P. Zave, “Classification of Research Efforts in Requi- rements Engineering,” ACM Computing Surveys, Vol. 29, No. 4, 1997, pp. 315-321. [11] D. C. Gause and G. M. Weinberg, “Exploring Requi- rements: Quality before Design,” Dorset House Publishing Co., Inc, Vancouver, 1989. [12] S. L. Pfleeger, “Software Engineering: Theory and Practice,” 2nd Edition, Higher Education Press, Beijing, 2002. [13] S. Alshawi and W. A. Karaghouli, “Managing Know- ledge in Business Requirements Identification,” Logistics Information Management, Vol. 16, No. 3, 2003, pp. 341- 349. [14] Q. F. Shi, et al. “Characteristics and Modal Analysis of Implicit Knowledge Transfer,” Studies in Dialectics of Nature, Vol. 20, No. 2, 2004, pp. 62-68. [15] X. J. Xv, “On the Transmission of Knowledge,” Studies in Science of Science, Vol. 23, No. 3, 2005, pp. 298-303. [16] N. Maiden, et al. “Provoking Creativity: Imagine What Your Requirements Could be Like,” IEEE Software, Vol. 21, No. 5, 2004, pp. 68-75. |