J. Software Engineering & Applications, 2010, 3: 487-494
doi:10.4236/jsea.2010.35055 Published Online May 2010 (http://www.SciRP.org/journal/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.
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 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 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 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 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 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 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 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.