A First Step in Improving the Requirements Engineering Process
by Using the Knowledge Management Perspective
Case Study from French Public Institute
Malika Grim-Yefsah
INSERM (Institut National de la Santé Et la Recherche Médicale) DSI – INSERM,
13 rue Watt – BIOPARK- Bat B, 1
er
étage, 75013 Paris, France
Keywords: Requirements Engineering, Knowledge Management, Knowledge Transfer, Information System
Development, Case Study.
Abstract: This paper argues that requirements engineering (RE) process is vital and key of success of an Information
Systems Development (ISD). In French public institute, ISD project is produced by service provider and
internal team. During this project, relevant context aspects are neglected. One aspect is incorrect and
incomplete requirements specification. So the challenge is how to effectively transfer knowledge-related
requirements from internal team to service provider. In this paper, first, we describe the state of practice of
RE in a French public institute. Second, we describe who we address the requirements engineering from the
perspective of knowledge management (KM). Finally, we discuss challenges knowledge transfer in RE
process.
1 INTRODUCTION
This study aims to enhance the understanding of
knowledge management in requirements engineering
in the context of information system development.
In a French public institute, an ISD project
implicates three participants. Two internal
participants: IT Department and the Business
Department, and an external participant which is
software and computing services Company also
called service provider. The ISD is a hard task for
which it is inevitable to define requirements clearly
and accurately at the outset. It has been recognized
for many years that poor requirements definition
remains a root cause of project failure and waste. As
in (Rodrigues, 2001) several problems that torpedo
the timely delivery of software projects: (1)
Unstable, constantly changing requirements (66%).
(2) Poor requirements specification (55%). (3) Client
behaviour, such as approval delays, requirements
changes and poor communication (42%).
In French Public Institute, existing processes for
establishing requirements are often ad-hoc and
inefficient, leading to miscommunication and
insufficiently defined requirements. Then, the
significant challenge of IT Department is how to
effectively transfer knowledge-related requirements
from internal to service provider. The IT
department’s aim is to become streamlined and
efficient: (a) ensure that information system
development projects break free from traditional
bottlenecks and delays, (b) meet the real needs of
their users, (c) have accurate requirements.
Improving the quality of IT department's
activities can be achieved in two ways:
• By improving ongoing management which
means that organizations save time and money in the
design phase, during development and throughout
the testing and quality assurance processes.
• By improving the requirements engineering
process so that errors are not introduced into the
specification.
The paper is structured as follows. Section 2
presents briefly the research method and captures the
state of the practice of requirements engineering in
our company. Section 3 summarizes the theoretical
foundation of this study. It’s on two areas:
Requirements Engineering (RE) and Knowledge
Management (KM). Section 4 presents how we
introduce the RE process combined with KM
activities in ISD project. In section 5, we discuss our
finding and our challenges. The section 6 highlights
280
Grim-Yefsah M..
A First Step in Improving the Requirements Engineering Process by Using the Knowledge Management Perspective - Case Study from French Public
Institute.
DOI: 10.5220/0005133602800288
In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2014), pages 280-288
ISBN: 978-989-758-050-5
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
works done by others that somehow ties in with our
own work. The section 7 draws conclusions.
2 RESEARCH METHOD
The research was carried out as a case study, a
method of studying contemporary phenomenon in a
real life context (Yin 2009). We collect data by
interviewing two projects teams conducted by
Information Technology Department (ITD) of a
French Public Institute. Less than 1% of staff works
in this ITD. The interviews were semi-structured.
The questions’ themes were: RE concepts, RE
process, documentation, and practices. We have
noted all answers and summarized them. Finally, we
sent them to interviewees for review and correction.
We have also collected data by interviewing
stakeholders about three domains (biomedical
research, financial and human resource) involved in
these projects. In summary, the RE’s state is
drawing in Figure n°1.
Internal’ FPI Service Provider
Figure 1: Representation of ISD in FPI.
The IT Department produces a statement of the
scope of the system which was envisaged by
stakeholders, and summaries those needs. It puts out
an invitation to tender. Contractors submit proposals
that set out their experience in building such
systems. The ITD’s committee draws up detailed
comparison of the bids. It selects a company which
appears to have the post experience in developing
similar systems, and the cheapest. The selected
company meets with the ITD to initiate the contract.
Company developers meet with the project manager,
who was chosen by ITD, throughout the
development to review any changes, and to discuss
how those would impact the cost and schedule. The
selected company delivers the system; it is tested by
users selected by ITD. Throughout tests, users ask
for additional functions to be added to the delivered
system
:
each function must be paid.
The stakeholders’ representative shows that the
system is significantly different from the target users
identified; however, they want to start using them
immediately and he asked for additional functions.
The system proved to be rather inflexible. First, the
project manager explains that specification turns out
to be poorly written by the service provider.
The selected company (service provider) assured
that customer requirements were pretty incomplete,
ambiguous or even contradictory sometimes. Their
engineers, analysts and developers have built what
they think is request and they have written test cases
using the same assumptions.
Finally, the project manager concludes that
requirements were inadequate and that no
requirements engineering process was identified
before.
Throughout this study, we explain that:
“Requirements or knowledge to be communicated
and transferred are difficult to express explicitly to
others because they are mostly tacit and intangible”
(Medeni et al. 2011).
The summary of the results was presented in a
workshop and report was send from CIO.
3 THEORETICAL
FOUNDATIONS
This study bases its theoretical foundation on two
areas: knowledge Management (KM) and
requirements engineering (RE).
3.1 Requirements Engineering Process
Requirements engineering (RE) is a systematic and
iterative process to understand, capture and
document what require from a product or a system
into written form requirements and specifications
(Asghar and Umar 2010; Kauppinen et al. 2004;
Kotonya and Sommerville 1998; Wiegers 2003).
The purpose of RE is to serve all stakeholders’ needs
in a product or a system and create understandable,
complete, and consistent requirements and
specifications that can be accepted by all
stakeholders in order to use those as an input in
Project
Manager
(ITD)
Stakeholders’
representative
Needs
AFirstStepinImprovingtheRequirementsEngineeringProcessbyUsingtheKnowledgeManagementPerspective-Case
StudyfromFrenchPublicInstitute
281
producing a product or a system (Asghar and Umar
2010; Pohl 2010).
Pohl K. describes the requirements engineering
framework by three dimensions: specification,
agreement, representation and by four core
activities: documentation, elicitation, negotiation,
validation (Pohl, 1994). These three dimensions of
RE can be characterized as follows:
-Specification dimension deals with the
understanding of the system requirements attained.
-Agreement dimension deals with the level of
agreement achieved between the relevant
stakeholders about the known requirements.
-Representation dimension deals with
documenting and specifying the system
requirements using different documentation formats.
From the three dimensions of RE, the four core
activities of RE can be derived as follows:
(1)Elicitation activity makes knowledge
(requirements) about the system explicit and thus
leads to a better understanding of the problem
(system).
(2)Negotiation makes existing conflicts,
argumentations and rationales explicit and assures
that the "right" decisions are made; establishes an
agreement between the various stakeholders.
(3)Documentation activity deals with the
representation of the existing viewpoints in different
representation formats; assures consistency and
cross-references between the various representation;
establishes a (partially) formal requirements
specification.
(4)Validation assures that the right problem is
being tackled at any time in the process; checks the
internal consistency of the specification; controls if
the specified requirement are consistent with the
user/customer intentions.
The RE process is a communication activity not
technical activity (Wiegers 2003). During this
process, stakeholders need to express and to transfer
their needs, wants, information or knowledge for
creating complete and accurate requirements.
3.2 Knowledge Management
Knowledge Management (KM) is all practices of an
organization to create, store, transfer, use and share
knowledge. A comprehensive survey does by
(Kalpic and Bernus 2006; Anand and Singh 2011) of
the KM literature shows the various KM frameworks
and KM activities. Those activities are: (1)
Knowledge Acquisition, (2) Knowledge retention,
(3) Knowledge Transfer and (4) Knowledge
Utilization. Knowledge acquisition includes those
activities associated with the entry (creation) of new
knowledge into the system. A system can be human
or tool. Knowledge retention includes the activities
that preserve knowledge and allow it to remain in
the system once introduced. Knowledge transfer
refers to the activities with the flow of knowledge
from one party to another. Knowledge utilization
includes the activities connected with the application
of knowledge to business process.
3.2.1 Knowledge
Knowledge is defined as being justified true belief
(Nonaka, and Takeuchi, 1995). Knowledge is often
distinguished between tacit (or implicit) knowledge
and explicit one (Polanyi, 1967). Explicit knowledge
can be codified (e.g. writing or drawing) and
articulated since it can be expressed formally and
systematically. Tacit knowledge corresponds to
skills, senses, intuition, physical experiences, “job
secrets”, environmental knowledge concerning
clients or technologies. We can differentiate two
kinds of tacit knowledge: the individual and the
collective one (Nonaka, 1994). The collective
knowledge is created and possessed collectively by a
group composed of more than one individual. Note
that group tacit knowledge is more than the
aggregation of each member’s individual tacit
knowledge (see (Erden, et al. 2008) for details).
3.2.2 Knowledge Creation
(Nonaka and Takeuchi, 1995) developed the model
of knowledge creation, which consists of four
phases, as illustrated by Figure n°2: Socialization
(tacit to tacit knowledge), Externalization (tacit to
explicit knowledge), Combination (explicit to
explicit knowledge) and Internalization
(explicit to
tacit knowledge). This model was called SECI.
Figure 2: SECI Model.
KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing
282
With this model, knowledge has to flow by being
acquired, shared, or exchanged to generate new
knowledge. The idea behind this being that the
process is dynamic, and should not be thought of
necessarily in discrete stages, but as a spiral of
information transfer.
Knowledge can be acquired not only through
structured media, such as documents, but also
through informal and/or formal interpersonal
interactions
(Davenport and Prusak, 1998).
(Nonaka and Konno 1998; Nonaka and Von
Krogh, 2009) indicated that Physical, face-to-face
experiences are the key to creation, conversion and
transfer of tacit knowledge.
3.2.3 Knowledge Transfer
Knowledge transfer is an important part of
knowledge Management (Davenport and Prusak,
2000). It refers to ensuring that knowledge is
transferred throughout the company or between
organisations from the sender to the receiver who
needs that knowledge. (Davenport and Prusak, 1998)
proposed this definition:
Transfer= Transmission + Absorption (and Use)
Please, note here the important distinction
between Transmission and Transfer. This equation
indicates that transmitting knowledge by sending or
presenting explicit knowledge is not sufficient for
transferring it.
The term ‘transfer’ seems to imply
that all the knowledge is passed from one person to
another. Knowledge transfer must take place
between (at least) two parties. It implies the giving
and taking of knowledge within a context by the
participants.
There are many mechanisms that exist
for transferring knowledge from one firm to another
for example, documents, project reports, face-to-face
meetings, telephone calls, e-mails, video
conferences or personal transfer. The important
aspect for transferring knowledge is to choose a
suitable method of knowledge transfer for the
different types of knowledge being transferred
(Martin and Antonio 2010). Explicit knowledge can
be transferred through, for example books,
documents, databases and meetings. On the other
hand, tacit knowledge can be transferred through
personal interactions, meetings, training and learning
by doing. Social interaction ties have positive
effects for resource exchanges between
organisations (Mirani 2006; Grim-Yefsah 2012).
4 OUR EXPERIMENTATION:
APPROACH BASED KM-RE
ACTIVITIES
This section describes practices of requirements
engineering process which we introduce in the IT
department of French Public Institute.
The IT department’s problem is: Requirements
which to be communicated and transferred from
internal to service provider are difficult to express
explicitly, because they are mostly tacit and
intangible. (Rolland, 2006) argues that “a number of
studies show that systems fail due to inadequate or
insufficient understanding of the requirements they
seek to address…”. When knowledge transfer is not
effective between internal and service provider, all
relevant information and knowledge of the product
requirements are sent to the service provider
incompletely (Grim-Yefsah et al 2011; Grim-Yefsah
2012). Therefore, transferring information,
knowledge between the stakeholders and developers
is crucial. Our research question is: How can
knowledge transfer improve the requirements
engineering process, during an Information System
Development project?
In our case study, we consider
- Internal: Businesses process representative,
customers, engineers, project manager and users are
stakeholders. They participate in requirements and
they should cooperate with each other.
- Service provider: requirements analysts,
designers, developers. They participate in
requirements and they should cooperate with the
internal team. (Fox, 1982) argues that “The
designers know how to design a product but do not
know the tools and techniques required to create
and maintain a product or system. The developers
understand how to create a product or system and
know the technologies or tools for using in
producing. The requirements analyst is the person
who documents the requirements. The requirements
analyst needs to write a requirement that is
understandable, unambiguous, consistent, and
complete to the developer.”
- The requirements are created mainly based on
needs and wants of customers and Businesses
process representative.
- Based on the results of our doctoral research
(Grim-Yefsah 2012): Knowledge Management is a
discipline we use in our organization to identify,
create, represent, distribute and enable the adoption
and leveraging of good practices embedded in
collaborative settings of work of employees.
AFirstStepinImprovingtheRequirementsEngineeringProcessbyUsingtheKnowledgeManagementPerspective-Case
StudyfromFrenchPublicInstitute
283
Effective knowledge management boost the
collective expertise of employees in organisation
and partners (e.g. the service provider). Then we
propose some good practices for this study:
(1) Throughout the project, the information is
transferred and shared through many channels, such
as meetings, teleconferences, documents and face-
to-face discussions with trust and openness;
(2) Be careful to nature of knowledge to be
transferred. We could think that explicit knowledge
is more easily transferable as it is teachable and
articulate. However, we have observed in reality,
that even explicit knowledge is hard to learn and
transfer due to limitations of explanation capacity
(documents) and codification ability (Grim-Yefsah
2012);
(3) Managing communication between partners
(internal and service provider);
(4) Articulating the needs and requirements of
potential stakeholders.
We propose an approach where RE’s activities
and KM's activities are combined and those good
practices are used. Our approach consists of three
steps (Figure n°3).
Step1- at this first step, it is important to provide
interaction between the internal and service
provider. We propose the use brainstorming,
meeting to align the perspectives of a wide variety of
stakeholders: it is consists of sharing knowledge in
face-to-face, natural, and typically social
interactions. Stakeholders are the initial holder of
some requirements knowledge.
There is tacit knowledge about requirements in
stakeholder’s mind within a specific context and
explicit knowledge. Then, we help stakeholders to
communicate their requirements knowledge to
analysts. As indicated above, this can be viewed as a
knowledge transfer via communicative.
The requirements are elicited from stakeholders
by analysts (Figure n°3). Analysts belong to
supplier's team (service provider).
On the first hand, stakeholders describe their
requirements and business process in natural
language, ‘French’. A major set of requirements
arises from the legislation, decrees, regulations and
notes of French Public Institute.
We observe that this description is very sound in
natural language but it is very hard to give:
Businesses process representative, customers and
users have poor understanding of computer
capabilities and limitations; analysts have poor
knowledge of problem domain and business process.
We observe also that users know how to do
something but are unable to articulate how they do
it. Then requirements workshop, face-to-face and
uses cases overcome those problems.
On the second hand, requirements and business
processes are collaboratively drawn between internal
and service provider by using a BPM Tool (evolve
of Casewise). This tool is not dedicated for
requirement elicitation but it allowed us to manage
relationships, hierarchies, and traceability which are
hard to manage by hand and in natural language.
Thus, stakeholders and analysts work
collaboratively to "effectively" exchange potential
information and knowledge for the requirement and
business process. We make six workshops. This step
is expensive
although the transfer of requirements
knowledge have be improved and requirements
description have be furthered effectively.
Step2- the previous step focuses on the eliciting
users’ needs and collecting all requirements. The
opinions of the stakeholders are conflict with one
another. Internal project manager and supplier's
project manager detect those conflicts and they try to
make them unambiguous and prioritize them.
Therefore, they propose some technical methods;
Decision trees, activity diagrams and they used the
prioritization technique that gives stakeholders the
confidence level and give the necessary information
to the development team; “
MoSCoW” (Must, Should,
Could, and Won’t Have). The peculiarity is that
stakeholders accustom to being asked "what they
want" but not "what they do not want"; find some
answers to this question gives them a different
perspective of their problems and helps them to
define requirements much more targeted list. They
apply this technique for all requirements on
KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing
284
whatever level of detail, but without any reference to
a time scale. The finality of this step is to bring the
stakeholders’ groups to meet together, to discuss the
requirements and to agree on priorities. Therefore,
the process of establishing a final set of requirement
involves stakeholders negotiating compromises
between conflicting requirements is occurred. Thus,
the business process and the requirements will be
formulated clearly and accurately.
Step3- At this step, all information and
knowledge explicated and collected during the
previous two steps are formalized in specification
document. A synthesis is done in the form of review
report, a trend analysis also. Thus, to drive a shared
understanding among business managers and others
stakeholders, then this documentation is presented to
them. Hence, the shared understanding provides
better decisions and new requirements have
recombined into a form that better lends itself to
transmission to designers, business analysts, and the
stakeholders. We make available a wiki for
stakeholders to enable them to submit their ideas and
comments about specification document. Thus, we
ensure traceability of business requirements to
solution requirements. In this step, the stakeholders
detect defects in the requirements and these have
been corrected: we have iterated the framework
again.
Table 1: Relevant characteristics of our approach.
Approach’ properties
Individual
characteristics
Interaction
characteristics
Success
Individual
feedback
acquiring
knowledge
create a
common
understanding
In space for
sharing,
individuals share
ideas, questions,
answers, wishes,
emotions, etc.
socializing
with others
seeking for
Knowledge
capture
decisions
made in a
project
implement
the basic
functionality
to fulfill the
requirements
Individuals elicit,
communicate,
document his or
her expertise
collaborative
level
correlation
between RE
and KM
Individuals
articulate tacit
knowledge into
explicit concepts
expertise level
/ reliability
changes in
organisations
Based on our doctoral results (Grim-Yefsah 2012)
we noted that documents are a poor substitute for
interpersonal communication. This we attribute to
the inherent restrictions of the available notations
and tacit knowledge about requirements in the
stakeholder’s mind. So we have appreciated the role
of meetings such as design reviews in clarifying
ambiguities and resolving conflicts in the
specification documents. At the end of this step, the
requirements have validated (content,
documentation, agreement with stakeholders).
This approach has allowed the project team
(Internal and Service Provider) to carry out the
requirements engineering process. All relevant
requirements are explicitly known and understood
by stakeholders involved. All requirements are
documented and specified.
We summarize particular findings of the case
study in table1.
5 DISCUSSION
The results obtained contribute to a better
understanding and greater efficiency of the process
of knowledge transfer during an Information System
Development project, especially in the RE phase,
taking into consideration the particular
characteristics of the IT Department of French
Public Institute. The results show that the transferred
knowledge must be directed at the operational needs
felt in ISD project. It must be avoided that the
service provider's team believes the transferred
knowledge is imposed by stakeholders, in order for
it to be used as an asset in the production of new
products, and consider also requirements of the
legislative, decrees, regulations and notes of French
Public Institute.
Actually, we note that:
(1) The service provider's team cannot
understand the knowledge transferred due to a lack
of sufficient prior related knowledge to assess the
value of stakeholder's knowledge, the transfer fails
as well;
(2) The internal team cannot assess the
knowledge transfer gain and it fears the loss of their
knowledge.
Based on the literature analysis in § 3.2 about
knowledge transfer and our results of illustrated’s
approach in §4, there are three basic elements of a
transfer (Figure n°4): Resource, Process and
Context.
AFirstStepinImprovingtheRequirementsEngineeringProcessbyUsingtheKnowledgeManagementPerspective-Case
StudyfromFrenchPublicInstitute
285
Figure 3: Basic elements in Knowledge Transfer during
RE Process.
The element 'resource' consists of:
- Transmitters and receivers (people: internal and
service provider in our case);
- The media and channel use in knowledge transfer
process (brainstorming, workshop, Visio conference,
wiki, email in our case);
- Types of knowledge, regarding tacit knowledge,
direct communication between transmitters and
receivers ensure that the transfer is conducted
effectively.
The element ‘context’ is about the environment
which has an impact on the transfer.
The process considered in our case study is
requirement engineering process. Knowledge
transfer in the requirement engineering process is
studied in a French Public Institute. Our company
offers good telecommunication solutions, including
tools (BPM) and others services. This process is
produced in cooperation with internal team and the
service provider. The common understanding
between people is the critical challenge in the
requirements engineering process. This challenge
may cause from, for example the ability/ skill of
people and trust between people.
The case study method does not allow the results
to be generalized, but it permits the investigation of
a combination of problems of the phenomenon thus
contributing to its better understanding.
6 RELATED WORK
In this section, we highlight works done by others
that somehow ties in with our own work. The
challenges of knowledge transfer in the requirements
engineering process are summarised from various
previous studies (Distanont, 2012; Kotonya and
Sommerville 1998; Wiegers 2003). The most
important work is the doctoral dissertation of Dr.
Distanont. The purpose of her research is to enhance
understanding of Knowledge transfer in
requirements engineering in the context of
collaborative product development. The major
domain is industrial engineering. The results of this
work indicate that collaboration in product
development is very important and acts as a means
of obtaining external resources, especially
knowledge. In order to increase the effectiveness of
knowledge transfer over enterprise interfaces, each
knowledge type needs to be transferred through the
suitable transfer channel at the right time. The
results also indicate that the individual relationships
among buyers and suppliers are an essential element
for long-term collaboration and common platforms
or tools need to be developed to support
collaborative product development over enterprise
interfaces. We believe that our approach brings a
complementary vision by focusing only on an
outsourced information system project.
7 CONCLUSIONS
In order to meet the objective of this paper, the
following research question is formed: How can
knowledge transfer improve the requirements
engineering process?
We focus on requirements engineering process
due to its significance for ISD success and its
complexity. We investigated what is the impact of
knowledge management (specifically Knowledge
Transfer), on this requirements engineering process
and, in turn, on ISD performance.
Our empirical study tests hypotheses by utilizing
data from projects of Information System
Development, especially in the RE phase, taking into
consideration the particular characteristics of the IT
Department of French Public Institute, that enables
us to estimate the influence of the knowledge
transfer on the requirements engineering process.
In this paper we showed how the requirements
engineering process can be approached in an
organisation through the knowledge management
perspective. This is an initial step towards
understanding the problem of requirements
engineering process in practice.
Different elements directly impact transfer
performance during requirements to be created:
people, types of knowledge, transfer channels, and
context or environment. To overcome the challenge
of knowledge transfer, it is necessarily to use a
potential solution to manage people, the process and
the context as a key challenge of transferring
knowledge in the requirement engineering process.
So we find that the proposed approach has an
influence on the knowledge transfer during the
KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing
286
requirements engineering process performance,
thereby, further improving our understanding of RE
process.
We contribute to a better understanding of the
importance of knowledge management related to
managing explicit and tacit dimensions on the
requirements engineering process.
The results of this research have direct
applications and utility in our company. However
generalizability to other domains remains to be
assessed.
Moreover, means knowledge transfer
practices and others solutions for improve
requirement engineering process and for overcoming
problems, should be studied.
REFERENCES
Anand, A., and Singh, M.D. (2011). Understanding
Knowledge Management: a literature review.
International Journal of Engineering Science and
Technology (IJEST 2011) vol3 (2), pp926-939.
Asghar, S., and Umar, M. (2010) Requirement
Engineering Challenges in Development of Software
Applications and Selection of Customer-off-the-Shelf
(COTS) Components. International Journal of
Software Engineering 1(1), pp32–50.
Blumenberg, S., Wagner, H.T., and Beimborn, D. (2009).
Knowledge transfer processes in IT outsourcing
relationships and their impact on shared knowledge
and outsourcing performance. International Journal of
Information Management 29(5), pp342–352.
Davenport, T.H., and Prusak, L. (1998), Working
knowledge: How organizations manage what they
know. Boston, MA, Harvard Business School Press.
Davenport, T.H., and Prusak, L. (2000). Working
Knowledge – How Organizations Manage What They
Know. Boston, Massachusetts, Harvard Business
School Press.
Distanont, A. (2012). Knowledge Transfer in requirements
engineering in collaborative product development.
Copyright © 2012. University of Oulu, Finland.
Erden, Z., von Krogh, G., and Nonaka, I. (2008). The
quality of group tacit knowledge. J. Strateg. Inf. Syst.
17, vol. 1, pp.4-18.
Fox, JM. (1982). Software and its development.
Englewood Cliffs, NJ, Prentice-Hall.
Grim-Yefsah, M. (2012). Knowledge Management and
Outsourcing. Doctoral thesis, Computer science,
University of Paris-Dauphine, France.
Grim-Yefsah, M., Rosenthal-Sabroux, C., and Thion-
Goasdoué, V., (2011). Changing Provider in an
Outsourced Information System Project: Good
Practices for Knowledge Transfer Proceedings of the
IC3K - KMIS 2011.
Kalpic, B., and Bernus, P. (2006). Business process
modeling through the knowledge management
perspective. Journal of Knowledge Management,
10(3), pp40–56.
Kauppinen, M., Vartiainen, M., Kontio, J., Kujala, S., and
Sulonen, R. (2004). Implementing requirements
engineering processes throughout organization:
success factors and challenges. Information and
Software Technology 46(14), pp937–953.
Kotonya, G., and Sommerville, I. (1998). Requirements
Engineering: Processes and Techniques. Chichester,
England, John Wiley & Sons.
Martin, J., and Antonio, N. (2010) Knowledge transfer to
the subsidiaries operating in overseas. Industrial
Management and Data Systems 110(4), pp516–531.
Mirani, R. (2006) Client-vendor relationships in offshore
applications development: An evolutionary
framework. Information Resources Management
Journal 19(4), pp72–86.
Medeni, T., Ünsal, S., Ayas, M., and Medeni, I.T. (2011).
Tacit knowledge extraction for software requirement
specification (SRS): a proposal of research
methodology design and execution for knowledge
visualization. Proceedings of the 55th Annual Meeting
of the ISSS-2011, Hull, UK - journals.isss.org.
Nonaka, I. (1994). A dynamic theory of organizational
knowledge creation. Organization Science, 5(1),
pp14–37.
Nonaka, I. and Takeuchi H. (1995). The Knowledge-
Creating Company: How Japanese Companies Create
the Dynamics of Innovation. Oxford University Press.
Nonaka, I. and Konno N. (1998). The concept of "Ba’:
Building foundation for Knowledge Creation.
California Management Review Vol 40, No.3 Spring.
Nonaka, I., and Von Krogh G. 2009. Tacit Knowledge and
Knowledge Conversion: controversy and advancement
in organizational knowledge creation theory.
Organization science 20(3), pp635-652.
Pohl, K. (2010). Requirements Engineering -
Fundamentals, Principles, and Techniques. New York,
Springer.
Pohl, K., (1994). The Three Dimensions of Requirements
Engineering: A Framework and its Applications,
Information Systems, Vol. 19, No. 3, pp.243-258.
Polanyi, M. (1967). The tacit dimension. Garden City,
NY: Doubleday & Co.
Rodrigues, A. (2001), “Project Goals, Business
Performance, and Risk.” Cutter Consortium Project
Management Advisory Service Executive Update 2(7).
Rolland, C. 2006. From Conceptual Modelling to
Requirements Engineering”. D.W. Embley, A. Olivé,
and S. Ram (Eds.). ER2006, LNCS 4215, pp5-11.
Sommerville, I. (2006). Software Engineering. 8th ed.
Harlow, UK. Addison Wesley.
Watanuki, K., and Kojima, K. (2007). Knowledge
acquisition and job training for advanced technical
skills using immersive virtual environment. Journal of
Advanced Medical Design, Systems and
Manufacturing 1(1), 48–57.
Wiegers, K. (2003). Software Requirements. 2nd ed.
Redmond, Microsoft Press.
Yin, R.K. (2009). Case Study Research, 4rd ed. Sage.
AFirstStepinImprovingtheRequirementsEngineeringProcessbyUsingtheKnowledgeManagementPerspective-Case
StudyfromFrenchPublicInstitute
287
Yu, E. 1995. Modeling Strategic Relationships for Process
Reengineering. A thesis submitted in conformity with
the requirements for the degree of Doctor of
Philosophy Graduate Department of Computer
Science University of Toronto.
Yu, Y., Sampaio do Prado Leiteet, J.C., Lapouchnian, A.,
and Mylopoulos, J. (2008). Configuring Features with
Stakeholder Goals. SAC’2008 Proceeding, pp. 16-20.
KMIS2014-InternationalConferenceonKnowledgeManagementandInformationSharing
288
