Journal of Software Engineering and Applications, 2011, 4, 718-728
doi:10.4 23 6/jse a .20 11 .4 12 08 4 Pu blishe d Onli ne December 2011 (
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in
Software Requirements Engineering Based on
the SECI Model
Azeddine Chikh
Information Systems Department, College of Computer & Information Sciences, King Saud University, Riyadh, Saudi Arabia.
Received October 7th, 2011; revised November 14th, 2011; accept ed November 27th, 2011.
Software requirements engineering deals with: elicitation, specification, and validation of software requirements. Fur-
thermore there is a need to facilitate collaboration amongst stakeholders and analysts. Fewer efforts were deployed to
support them in performing their job on a day to day basis. To solve this problem we use knowledge management for
software requirements engineering. This paper proposes a knowledge management framework, based on the SECI
model of knowledge creation, aimed at exploiting tacit and explicit knowledge related to software requirements within a
given software project. The core part of the proposed framework is a set of four sub systems Socializer”; “External-
izer”; “Combiner”; and Internalizer”, attached to a couple of domain ontologies and a set of knowledge assets. In-
deed we aim to facilitate a semantic based interpretation of knowledge assets related to software requirements by re-
stricting their interpretation through the application domain and software requirements ontologies. We anticipate that
this framework would be very helpful for stakeholders as well as analysts to exchange and manage their knowledge
within a given software project. We show in the case study, through a virtual payroll project using the two-step ap-
proach: domain level requirements plus design level requirements, how the key elicitation SRE techniques are used
during the first phase of domain requirements elicitation through the four subsystems of our framework.
Keywords: Software Requirements Engineering, Knowledge Management, Domain Ontologies, SECI Model
1. Introduction
The communities of software engineering and knowledge
engineering share a number of common topics. Whereas
software engineering re search has been continuously stru-
ggling towards a higher abstract software modeling dur i n g
the last decade, the knowledge engineering community
has been enthusiastic to promote numerous modeling ap-
proaches to conceptualize a domain of knowledge. In the
literature, several research works have been directed to-
wards knowledge management in software requirements
engineering (SRE) [1-4]. New era of SRE management
starts focusing on knowledge management of software
requirements within a given project. Such a knowledge
must include not only the generic knowledge of individ-
ual specialty fields of the domain of SRE and the project
application domain (payroll, finances, sales, etc.) but
knowledge of the best practices captured from the previ-
ous and similar projects.
Ac tivities in the domain of SRE typically involve people
from at least two fields: 1) the business field (customers
/users and other stakeholders) and 2) the IT field (ana-
lysts, requirements engineers and software project man-
agers). This diversity of actors often produces important
information flows and knowledge exchange that are dif-
ficult to manage. A broad variety of requirements engi-
neering models, techniques, and technological environ-
ments such as Computer-Aided Analysis/Engineering tools
have been designed and implemented by researche rs. T he y
are used to help gathering, analyzing, and documenting
software requirements. However, a lack of efforts was
observed in the way requirements engineering practi-
tioners are being supported in their daily activeties. There
is a need to help those actors managing collaboratively
and exchanging their knowledge building shared prac-
tices (best practices).
After this introduction, Section 2 recalls the SRE do-
main. Section 3 introduces the use of ontologies in this
domain. Section 4 explores the SECI model of knowl-
edge creation and shows how it is applied to this domain.
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model719
In Section 5, we present a knowledge management fra-
mework in SRE based on the SECI model of knowledge
creation. Then we integrate two domain ontologies to an-
notate the knowledge assets related to software require-
ments. Section 6 illustrates the use of the proposed frame-
work through a case study related to a virtual software
project in the domain of payroll. Finally the last section
concludes the paper and points out directions for future
2. Software Requirements Engineering
The requirements for a system are the descriptions of
what the system should do, the services that it provides
and the constraints on its operation. The process of find-
ing out, analyzing, documenting and checking these ser-
vices and constraints is called requirements engineering
(RE) [5]. SRE is a sub-category of (RE) that deals with
the elicitation, specification, and validation of require-
ments for software [6] and it is critical for successful
software develop ment.
Domain analysis is the process through which an ana-
lyst learns background information. Some domains might
be very broad, such as human resources. Others are nar-
rower such as “Payroll”. People who have a deep know-
ledge of a domain are called domain experts. Since the
involved analysts are often not domain experts, they must
learn about the problem domain from whatever sources
of information. These include domain experts, books
about the domain and existing software. The interview-
ing, observation, brainstorming and prototyping techni-
ques can help with domain analysis [7].
The software requirements specification (SRS) is an
official statement of what the system developers should
implement. It should include a detailed specification of
the system requirements [5]. It helps to understand what
the system is supposed to do and how its use can support
users and satisfy stakeholders. It is critical to the success
of a development project. Accordingly it should be based
on a model in which the result is an unambiguous and
complete specification document. The generic IEEE stan-
dard 830-1998 [8] describes recommended approaches for
the SRS. It describes the content and qualities of a good
SRS. It can be adapted to the considered project.
Joint Application Design (JAD) and Participatory De-
sign (PD) methodologies emphasize and promote coop-
erative work, among the various SRE’ actors, in devel-
oping the SRS [9].
3. Using Ontologies in Software
Requirements Engineering
The requirements on particular software are typically a
complex combination of requirements from different stake-
holders at different levels of an organization and from the
environment in which the software will operate. Accord-
ingly, the resulting SRS document should be clear, un-
ambiguous, easy to understand, complete and consistent.
In practice, this is difficult to achieve as stakeholders i nte r-
pret the requirements in different ways and there are of-
ten inherent conflicts and inconsistencies in the require-
ments [5].
A different understanding of the concepts involved
may lead to an ambiguous, incomplete specification and
major rework after system implementation [10]. In ad-
dition, it is important to assure that all analysts and
stakeholders in the analysis phase have a shared under-
standing of the concepts related to the application do-
main. Furthermore, even when users can express their needs,
analysts find it difficult to write them accurately. The re-
sult is that the real needs, such as expressed by users, and
the requirements, such as written in SRS, don’t match.
SRE is concerned with interpreting and understanding
stakeholders’ terminology, concepts, viewpoints and goals.
It aims to integrate these diverse views into a shared,
correct and complete SRS. Therefore, it must concern it-
self with an understanding of beliefs of stakeholders (epis-
temology), the question of what is observable in the
world (phenomenology), and the question of what can be
agreed on as objectively true (ontology). Such issues
become important whenever one wishes to talk about va-
lidating requirements, especially where stakeholders may
have divergent goals and incompatible belief systems
Gruber [12] defines ontology as a formal specification
of a conceptualization. A conceptualization is an abstract
simplified view of a domain that describes the objects,
concepts and relationships between them that hold in that
domain. Ontology can be used for both, to describe re-
quirements specification [5,13] and formally to represent
requirements content [1]. Further, the “domain model”
can be described using an ontology language, with vary-
ing de grees of for malizat ion and expr essivene ss. Ontolo-
gies seem to be well suited for an evolutionary approach
to the specification of requirements and domain knowl-
edge [1]. In addition, ontologies can be used to support
requirements management and traceability [2].
Moreover semantic wikis are used in SRE process, as
semantic and social-web based collaboration platforms by
the diverse stakeholders participating in this process [14].
4. The SECI Model of Knowledge Creation
In the past, there have been a number of too ls facilitating
knowledge management (KM) activities, but they were
not intended to explicitly integrate knowledge sharing
and exchange. Most of the past KM research works used
a typical top-down approach considering knowledge as a
separate entity and focusing on the creation of central
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model 720
knowledge repositories that foster knowledge reuse and
collaboration. Organizations have recognized that know-
ledge constitutes a valuable intangible asset for creating
and sustaining competitive advantages. Knowledge shar-
ing is an activity through which knowledge is exchanged
among members of a community or an organization. Re-
cent research on KM clearly recognizes the importance
of sharing knowledge within organizations [15-17] to
name but a few.
Researchers divide knowledge into two distinct forms:
tacit and explicit. Polanyi [18] considers knowledge as
either tacit or rooted in tacit knowledge. The type of
knowledge that we have learned so well, and embedded
in the unconscious mind, that we use them without thinking.
Nonaka [19] argues that we can know more t han we can
tell. Indeed not all our knowledge can be expressed into
objects, documents or artifacts. In 1991, Nonaka [16]
adapted the definition of tacit knowledge of Polanyi and
defined the explicit and tacit forms of knowledge.
Explicit knowledge (EK) is easily expressed, cap-
tured, stored and reused. It can be conveyed as data and
is accessible from databases, books, manuals and mail.
Tacit knowledge (TK) is difficult to express and
transfer to another person by means of writing it down or
verbalizing it. It is deeply rooted in action and consists
partly of technical skills and partly of mental models that
we do not recognize in ourselves and cannot easily spec-
ify them.
Nonaka & Ta keuc hi [1 6] pro pose t he SECI knowle dge
creation model as a key for KM in organizations. They
view knowledge as an activity rather than an object and
they focus on kno wledge creation, collab oration and pra-
ctices rather than knowledge transmission as stated in [20,
The SECI model consists of three main elements: 1)
four modes of knowledge conversion between the EK
and TK; 2) a shared context called “Ba”; and 3) knowl-
edge assets.
The creation of knowledge is a continuous process of
dynamic interactio ns between EK and TK. T he four mode s
of knowledge conversion interact in the spiral of knowl-
edge, Socialization; Externalization; Combination; and
Internalization as following:
Socialization: sharing experience to create new TK;
Externalization: articulating and converting TK to
EK. TK becomes EK through metaphors, analogies, con-
cepts, hypothesis, and models;
Combination: restructuring and aggregating EK
into new EK;
Internalization: reflecting on EK and internalizing
it into TK.
The “Ba” can be defined as the shared context where
the four modes of knowledge conversion happen [22].
Naeve et al. [23] consider the Ba as “a place for inter-
active knowledge creation” (this space can be physical,
virtual or mental). This Ba is divided into four contexts
corresponding respectively to each knowledge mode: 1)
Originating Ba: a space for social interaction; 2) Dia-
loguing Ba: a place where participants share and articu-
late their mental models and skills; 3) Syste mizing B a: a
context where EK can be combined such as a collabo-
rative environment; and 4) Exercising Ba: an internali-
zation context where knowledge is exercised through
action and practice.
The third element in the SECI model is the knowledge
assets. They are defined by Nonaka [22] as a set of en-
terprise-specific resources, that are considered as inputs,
outputs as well as moderating factors of the knowledge
creation process and that are necessary to create values
for the company. Four groups of knowledge assets are
identified in [16] by Nonaka et al.:
Experiential knowledge assets can be seen as hands-
on experiences; skills acquired through dialogue, discus-
sion and shared practice.
Conceptual knowledge assets consist of EK arti-
culated through images, symbols and language. These as-
sets are based on the concepts held by members and stake-
holders of the community.
Systemic knowledge assets consist of systematized
and packaged EK, such as explicitly stated technologies,
product specifications, manuals, and documents.
Routine knowledge assets consist of the TK that is
customized and embedded in the actions and practices of
the organization.
Based on SECI knowledge spiral model, Wan et al.
[24] have put forward a knowledge creation model for
software requirement development. Authors co nsider that
knowledge dissymmetry is one of the forces that drive
knowledge conversion. Therefore they argue that depen-
ding on experts on requirement, this model can reduce
knowledge dissymmetry, and realize knowledge con-
version and share more effectively and efficiently. More-
over Kamata [25] proposes the combination approach of
KM and chance discovery in order to do better require-
ments definition. KM might be effective for shallow
level. The author shows how the knowledge may flow
through SECI proc ess more sufficie ntly be tween t he cus-
tomer and the supplier, being respectively considered by
the author as an application domain expert and an IT ex-
5. A Knowledge Management Framework in
SRE Based on the SECI Model
The domain of SRE deals with a set of processes: elicita-
tion; specification; and validation of software require-
ments. In software projects with high uncertainty, a better
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model721
actors’ participation increases the quality of SRS [26].
Therefore, SRE actors should collaboratively work to im-
prove the quality of the SRS. We assume that this col-
laboration can be improved by using a knowledge man-
agement framework dedicated to SRE and based on SECI
model of knowledge creation.
The remainder of this section describes the structure of
the framework and is organized into three sub sections.
The first two subsections describe how the domain on-
tologies and the SECI model are applied to SRE. Then
the framework’s architecture is proposed in the third sub-
5.1. Applying Domain Ontologies to SRE
Our proposed framework aims to facilitate a semantic-
based interpretation of software requirements and the re-
lated knowledge assets, within each SRE process, by res-
tricting their interpretation through domain ontologies.
Indeed, we advocate the idea that these domain ontolo-
gies can be used to describe software requirements re-
lated knowledge assets that flow through t he SECI cycle
of knowledge creation occurring during the SRE proc-
esses, thus providing them with a new dimension of con-
tent reusability.
Happel and Seedorf [10] differentiate between the use
of ontologies in software engineering: 1) at development,
such as using conceptual models of the problem domain
and 2) at run-time, such as adaptations. According to this
classification, our approach belongs to the second ca-
Two domain ontologies are used by our framework to
represent the domain knowledge: Application Domain
Ontology (ADO) and Software Requirements Ontology
ADO involves understanding the application do-
main (e.g. payroll; finance; sales; library; etc.). In order
to enable effective knowledge assets understanding, we
have to further enhance semantics of their content. There-
fore, we recommend that they should be further enhanced
by providing application domain ontology based annota-
tions of their content. Many specific application domain
ontologies exist on the Web that can be found using Swoo-
gle1—a semanti c web search engine.
SRO encompasses many SRE concepts. It covers
many possibilities: requirements on various levels from
goal-level to design-level, different requirements styles
from plain text to diagramming, and from data require-
ments to quality requirements, many techniques and me-
thods from elicitation to validation [27]. For SRO, we
have selected SWORE2 o ntology (SoftWiki Ontology for
Requirements Engineering) proposed by [28]. Despite
the SWORE ontology describes only a small subset of
the domain of SRE, our choice is motivated by its modu-
lar structure as well as its clear conceptual separation.
However we have proposed an extension of SWORE by
integrating further SRE concepts such as requirements
styles and levels.
Figure 3 visualizes an extract from the core of the
SWORE ontology, which was developed in accordance
with standards of the requirements engineering commu-
nity [29]. Central to this ontology are the classes—Stake-
holder and Abstract Requirement along with property de-
ta ils. A bstr act re qu ir emen ts have th e su bc lass es —G oal , Sc e-
nario, and Requirement each of which are defined by
stakeholders and can be detailed by other abstract re-
quirements. This enables the specification of abstract re-
quirements at different levels of granularity. The colla-
borative aspects of requirements engineering are empha-
sized b y integra ti ng di sc us sio ns a mong st the sta ke hol de rs
and voting in the model. In order to interlink requirements
with existing documents or resources, SWORE contains the
classes Ra w Infor mation and Refere nce Point together with
suitable properties [28].
Style a nd Le ve l, wh ich a re d ra wn u si ng shad i ng st yle s ,
are the main classes of the extended part. A software re-
quir ement might be specified in many styles (in plain text,
as a diagram, as a table, screen, etc.). The goal design
scale is composed of 4 software requirements levels: goal
level; domain level; product level; and design level [27].
The goal-level requirement aims to justify why the cus-
tomer wants to spend money on the product. It can be
verified, although only after some period of operation.
The domain-level requirement outlines the user tasks in-
volved and requires support for these tasks. The prod-
uct-level requirement specifies what comes in and goes
out of the product (software). It identifies only the func-
tions and features. The design-level requirement specifies
one of the product interfaces in detail.
5.2. Applying the SECI Model to SRE
In our approach we consider the four SECI model modes
as they occur in each SRE process, where the main actors
are the analysts, users, managers, domain experts and other
stakeholders. In Figure 1 we adapt the SECI framework
described in [23] to the context of SRE. Actors’ individ-
ual knowledge will flow through the SECI cycle of know-
ledge creation. The knowledge tacit or explicit that is “in-
put” t o a given mode get s thr ough a t ransfo rmatio n pro c-
ess of dialogue, negotiation, conceptualization and agree-
ment. Each SECI mode, as shown in Figure 1, occurs in
a corresponding Ba.
Domain-related concepts and relationships of the do-
main ontologies, located at the center of the Figure 1, are
used to annotate knowledge assets.
2SWORE i s available for download at: S WOR E.
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model
Cop yright © 2011 Sci Res. JSEA
Figure 1 . SECI Model adapted from Naeve et al . [23].
Socialization mode occurs in the originating Ba. It
is based on exciting experiences to learn from each other.
TK is shared between SRE actors to have a better indi-
vidual understanding of the software requirements, for
instance: 1) Users might share their domain expertise,
activities, preferences, problems and opinions; 2) Man-
agers might share their challenges, strategies, constraints
and objectives; 3) Analysts might share their background,
technical points of view and solutions. One typical tech-
nique of socialization is JAD (Joint Application Design),
a structured process in which users, managers and ana-
lysts work together for several days in a series of inten-
sive meetings to specify or review system requirements.
As an added plus, group members are more likely to de-
velop a shared understanding of what the software is
supposed to do, reaching consensus. The socialization
process is controlled, among others, by the objectives, the
moral values, the common background, and the readiness
for collaboration of SRE actors; the balance of forces
between these actors; and the means and rules of social-
lization. At this point, we are in the stage of negotiation
of meaning.
Externalization mode happens in the dialoguing
Ba. The preferences and wishes of users (TK) are arti-
culated and conceptualized by analysts to produce for
instance new (EK) such as notes or some specification
using different styles (data dictionaries, entity-relation-
ship diagrams, virtual windows for data requirements) or
a prototype. Possible techniques of externalization are
taking notes (during interviews or observation), brain-
storming (during a close meeting) and prototyping. A
software requirement specification such as a data re-
quirement represented using a data d ictionary style is one
example of output of this mode. T he externalization pro-
cess is controlled, among others, b y the objectives of ana-
lysts; the expression power of users in expressing their
needs; and the means and rules of externalization. At this
point we are in the stage of representation (reification) of
Combination mode occurs in the systemizing Ba.
Separate and simple software requirements specification
(EK) is further arranged into systematic and complex
specification (EK). For example, user requirements and
system requirements could be assembled to build an SRS.
Possible techniques of combination are based on docu-
ment reuse, building complex document from smaller ones
by using transformation of structure. The combination
process is controlled, among others, by the objectives of
analysts and the means and rules of co mbination.
Internalization mode occurs in the exercising Ba.
Software requirements specification and other software
requirements related knowledge assets (EK) are trans-
formed into increased individual users and analysts un-
derstanding (TK). Moreover users can deduce new re-
quirements (TK) through running a prototype (EK). Pos-
sible techniques of internalization are observation, active
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model723
reading (books about the domain, user documents, SRS,
etc.) and using prototype or existing similar software. The
internalization process is controlled, among others, by
the objectives and the previous knowledge (background)
of users and analysts and the means and rules of inter-
The overall outcome from applying SECI model of
knowledge creation to SRE is an increased and better EK
and/or TK on software requirements among all the pro-
ject actors: (analysts, users, managers, domain experts
and other stakeholders). Table 1 gives some examples of
EK (pieces of knowledge that can be written down, trans-
mitted, and understood by a beneficiary actor) and TK
(chunks of knowledge that the users are not aware of or
cannot express) in the domain of SRE. In practice most
requirements are tacit. Analysts should specify only re-
quirements which are not obvious. To do so, they must
know what designers are likely to use these requirements
for [27]. Table 2 gives some examples of knowledge
assets according to the four categories of SECI model of
knowled ge creation.
5.3. Frame wor k’s Ar ch i t ecture
The proposed framework is based on SECI model of
knowle d ge cr eati on. M ore over it uses onto logie s to ma ke
semantic the different processes of this model. The sys-
tem’s architecture in Figure 2 is drawn around four sub-
systems matching the four modes of SECI model and con-
sidered as their corresponding virtual “Ba”. These sub-
systems are: “Socializer”, “External izer”, “Combiner”, and
“Internalizer”. Furthermore, knowledge assets, contained
within a knowledge repository, are annotated using con-
cepts and relationships in domain ontologies. The func-
tional details of the major components of the framework
are explained as following:
1) The domain ontologies contain domain-related con-
cepts and relationships in a structured and machine-in-
terpretable format, and are used to annotate knowledge
assets related to software requirements. We have consid-
ered two different ontologies (Section 5.1)—Application
Domain Ontology (ADO) and Software Requirements
Ontology (SRO). Semantic relations can model conflicts
or dependencies between the requirements.
2) The knowledge repository is composed of knowl-
edge assets either as instantiations (Is-a relationship) of
ADO and SRO concepts or as related knowledge re-
sources (Refers-to relationship). Indeed a knowledge
asset might be a theoretical knowledge in the domain of
SRE as well as a practical knowledge such as a best
practice in the domain. Examples of knowledge assets
are given in Table 2. Using a semantic representation,
opposing to the traditional approach, aims to foster the
understanding between SRE actors helping them to ma-
nage their knowledge assets related to software require-
ments. The framework allows indexing, using and reus-
ing of these knowledge assets, based on concepts and
relationships from ADO and SRO. Otherwise said, the
knowledge assets related to software requirements be-
come more definite, complete, consistent and suitable to
share and reuse.
3) The four virtual “Ba”s, being virtual places for in-
teractive knowledge creation, offers a set of complement-
tary tools and has as input and output either TK or EK
Table 1. Examples of EK and TK in SRE.
Category Examples
knowledge A list or a textual description of fu nctions to be provided by the s oftware, a data dictionary, a prototype of the software screens
The ability to condu ct a risk analysis is to identify risky areas of the software project and to decr ease the risk. The hard part is to
imagine the future work situations. This technique requires all sorts of knowledge and best practices that are not always known
explicitly, even by expert analysts, and which are difficult to explicitly transfer to other analysts. As novice analysts (apprentices)
learn how to conduct a risk analysis through simulation, observation, imitation and practice, they will learn new skills through
on-the-job training. After a period of imitation and practice, a new analyst will not only deduce risks from procedures but also
working with stakeholders and asking them which potential conflicts do they expect with other stakeholders? This turned out to be
the secret for successf ul risk analysis.
Table 2. Examples of knowle dge assets in S R E.
SECI knowledge assets categories Examples of SRE knowledge assets
Experiential knowledge asset s Shared minutes during a JAD sessi on
Conceptual knowled ge assets Separate requirements represented with different styles such as data dictionaries, entity relationship or data
flow diagrams
Systemic knowledg e assets SRS or parts of it; Prot otypes
Routine knowledge assets A best practice to conduct an interview learnt from more experienced analysts
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model 724
Figure 2. A knowledge management framework in SRE ba-
sed on SECI model.
related to software requirements. Furthermore, a virtual
“Ba” can be coupled to an Integrated Development En-
gineering (IDE) framework. Knowledge assets can be
exported from a virtual “Ba” to the IDE framework. Ac-
cordingly, the rendering of business processes and sys-
tem artifacts from the requirements description, can be
partially automated [30].
a) “Socializer” offers a set of communication, argu-
mentation and voting tools such as those used during
JAD sessions. Having such a subsystem can help SRE
actors to be more effective in guiding the socialization
toward their goals. The exchanged TK, embedded in dif-
ferent discussions, might be linked to concepts and rela-
tionships from ADO and SRO helping to its understanding.
b) “Externalizer” offers a set of semantic tools such
as semantic wikis, CAD tools, and prototyping tools, to
quickly build a prototype. The TK as well as the resulted
EK might be linked to concepts and relationships from
ADO and SRO improving their semantic.
c) “Combiner” offers a set of reuse based authoring
too l s i ncluding fusion, mer ging or s ynthesis services. The
primary EK as well as the composite EK might be linked
to concepts and relationships from ADO and SRO im-
proving their semantic.
d) “Internalizer” offers a set of active reading tools
such as semantic wikis. Se mantic annotation enriches the
unstructured or semi-structured data with a context that is
further linked to the structured knowledge of a domain.
For this purpose, the se mantic wiki exploits the concept s
and the relationship, stored in the two domain ontologies
ADO and SRO, and annotates the knowledge assets re-
lated to software requirements.
A semantic wiki is already proven to be a useful tool
for the elicitation of requirements [31]. Among the ex-
isting se mantic wiki s, SoftWiki focu ses on semantic co l-
laboration with respect to software requirements active-
ties [32]. Its aim is to let large and distributed stakeholders
be able to collect, semantically enrich, classify and ag-
gregate software requirements. It is based on the Ontol-
ogy (SWORE) adopted as SRO in our framework. Some
features provided by Softwiki are listed in Table 3.
The approach used in this paper is more innovative
than others used in similar works such as [24] and [25].
Indeed, it combines the SECI model and a couple of do-
main ontologies to make knowledge assets more accessible.
The knowledge repository contains a variety of assets
such as software requirements and shared minutes during
a JAD session (Table 2), offering a powerful source of
reuse for analysts to build a new SRS or to complete an
existing one. And finally the four subsystems include
recent collaborative tools such as semantic wiki.
6. Case Study
We suppose a virtual project aiming to determine soft-
ware requirements for a new pa yroll system. Examples of
these requirements may include: the payroll processing
should be completed within 24 hours; extra hours must
be r eco rd ed sep ara tely fr o m ord inar y ho urs; mana geme nt
reports should contain detaile d information abo ut normal
payment and extra-load payments for each department;
management reports should allow managers to automati-
cally analyze the data.
In order to illustrate the use of our framework in this
project, we need first of all an application domain ontol-
ogy (ADO) related to pa yroll d omain, which will b e used
in concert with (SRO) in order to annotate the knowledge
assets related to payroll software requirements. Figure 3
shows a model of such an ontology [33]. The main con-
cepts described are: Wage, Taxes and Employment con-
tract. The employment contract can be terminable, not
terminable or other. Terminable contracts can be seasonal
or temporary.
In this project, we propose the use of the two-step ap-
proach proposed in [27]: domain level requirements plus
design level requirements.
1) The first step is the domain level approach. In the
basic version of this approach one primarily focuses on
describing the user tasks collaboratively with users and
collecting information on the data to be stored in the
machine. The specification will contain the following
elements: introductory parts including business goals; the
limits of the system; data description; user tasks descrip-
tion saying that they have to be supported; a trace analysis;
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model725
Table 3. Softwiki’s features.
Feature Description
Adaptive content presentation The co ntent presen tat ion of pa ges can ch ange b as ed on seman tic ann otati ons. P ages ca n be enri ched wit h
the display of semantically related pages in a separate box or information can be displayed, which is
derived from the underlying knowledge base.
Enhanced navigation Offering extra information about the relation a link describes. Furthermore, it can provide context-aware
Typing of annotation Annotating links and text (requirements artifact) by giving them certain types.
Figure 3. Use of domain ontologies in SRE within a virtual Payrol l project.
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model 726
and quality requirements for critical quality factors. A
CRUD check (Create, Read, Update, and Delete) is nec-
essary to see tha t all req uir ed d ata are hand led i n so me t ask.
It should be followed by a review. Stakeholders are pri-
marily invited to correct the task descriptions.
2) The second step is the design level approach. A
design task that creates design level requirements for
complex interfaces. A prototype of screens is developed
on the basis of task description and data description. Then
the prototype is reviewed and validated through a usabil-
ity test to see its effective support of the user tasks. Fi-
nally, verification consists to see that design-level re-
quirements are satisfied.
Figure 3 illustrates the use of the domain ontologies
(ADO) and (SRO) and the knowledge repository, as two
components of the framework, within the payroll system
project. Payroll system related knowledge assets from the
knowledge repository are co nnected to co ncepts from bot h
ADO and SRO domain ontologies according either “re-
fers to” or “is a” links.
Furthermore, we assume that the above two-step ap-
proach follows an iterative process using a spiral model
whose main output is the SRS. The combination of the
two levels (domain and design) with the three SRE proc-
esses (elicitation; specification; and validation) results in
six phases as shown in Figure 4: (1) domain requirements
elicitation; (2) domain requirements specification; (3)
domain requirements validation; (4) design requirements
elicitation; (5) design requirements specification; and (6)
design requirements validation. The number of iterations
will change according the importance and the context of
each project.
Table 4 shows how the key elicitation SRE techniques
interviewing; observation; and questionnaires are used dur-
ing the first phase of domain requirements elicitation,
thro ugh the four subsystems of our framework: “Socializer”,
“Externalizer”, “Combiner”, and “Internalizer”.
Figure 4. A spiral view of the iterative two-step approach
Table 4. Using the framework in the two-step approach duri ng the domain requirements elicitation phase.
Interviewing Observation Questionnaires
(S) will help to foster discussion between
payroll s tak eholders offering communication
tools s uch as emailing, forum s, chat ting, etc.
(E) shou ld offer to
analysts a pr ototyping tool to help them to
translate in r eal time th e u sers’ needs into
prototype screens
interviewees a semantic wiki helping the
interviewee to express their d emands
(E) shou ld offer to the analysts a
video recording tool
(E) should provide to stakeholders web
based quest ionnaires to gather their
opinions and sugges tions about s ome
specific aspects of the cur rent p ayroll
(C) should provide to analysts statistical
tools that transform elem entary data into
more elaborated data
(I) (I) should offer to analysts a semanti c wiki t o
annotate the interviews transcripts
(E) shou ld offer to ana lysts a
semantic wiki to annotate the
obse r v ation note s
(I) should offer to analysts a s em antic
wiki to ann o tate the questionnaires results
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model727
7. Conclusions
In this paper, we aim to enable advanced services for all
key actors of the software requirements processes (elicit-
tation; specification; and validation). We came up with
the idea of applying SECI as a knowledge creation model
to the se proce sses. We have deve loped a knowled ge ma-
nagement framework in SRE based on SECI as a for-
malization of this idea. This framework integrates four
subsystems (“Socializer”, “Externalizer”, “Combiner”,
and “Internalizer”) matching the four modes of SECI
model and their corresponding “Ba”. These subsystems
are attached to the repository either for creation or ex-
ploitation of knowledge assets or both. Furthermore they
are connected to a couple of domain ontologies ADO and
SRO to foster semantic research.
The main novelty of our proposed framework is to re-
consider the SRE activities according a knowledge based
approach combining SECI model of knowledge creation
and domain ontologies.
The proposed framework is still at a conceptual level.
Currently, we are working on developing a prototype to
analyze the framework’s effectiveness for real-life ap-
plications. As a future plan, we intend to connect this
framework to a reuse based software requirements au-
thoring framework. The idea is to support the knowledge
management process according to SECI model by reus-
ing si milar knowledge assets from past soft war e pro jects.
[1] B. Wouters, D. Deridder and E. Van Paesschen, “The Use
of Ontologies as a Backbone for Use Case Management,”
Proceedings of the European Conference on Object-Ori-
ented Programming ECOOP, Workshop : Objects and Cla-
ssifications, a Natural Convergence, Sophia Antipolis and
Cann es, 2000 .
[2] V. Mayank, N. Kositsyna and M. Austin, “Requirements
Engineering and the Semantic Web, Part II. Representa-
tion, Management, and Validation of Requirements and
System-Level Archit ectures,” ISR Technical Repo rt, Uni-
versity of Maryland, Baltimore, 2004
[3] J. Lasheras, R. Valencia-García, J. T. Fernández-Breis
and A. Toval, “Modeling Reusable Security Require-
ments Based on an Ontology Framework,” The Journal of
Research and Practice in Information Technology, Vol.
41, No. 2, 2009 , pp. 119-133 .
[4] H. Kaiya and M. Saeki, “Using Domain On tology as Do-
main Knowledge for Requirements Elicitation,” Proceed-
ings of the 14th IEEE International Requirements Engi-
neerin g Conference, Minneapolis/St. Paul, 11-15 Septem-
ber 2006, pp. 189-198.
[5] I. Sommerville, “Software Engineering,” Pearson Educa-
tio n, Upper Saddl e R iver, 2011.
[6] P. Bourque and R. Dupuis, “Guide to the Software Engi-
neering Body of Knowledge,” IEEE Computer Society,
Washington DC, 2004.
[7] D. D. Champeaux, D. Lea and P. Faure, “Ob ject-Ori ented
System Development,” Addison-Wesley Longman Publi-
shing Co., Inc. Boston, 1993.
[8] IEEE Std. 830-1998, “IEEE Recommended Practice for
Software Requirements Specifications, IEEE Computer
Society,” Software Engineering Standards Committee, 20
October 1998, No. SH94654.
[9] D. Herlea, “Users Involvement in Requirements Engi-
neering P rocess,” Proceedings of the 10th Annual Know-
ledge Acquisition Workshop KAW96, Banff, 6-14 No-
vember 1996.
[10] H. J. Happel and S. Seedorf, “Applications of Ontologies
in Software Engineering,” Proceedings of the interna-
tional Workshop on Semantic Web Enabled Software En-
gineering SWESE, Athens, 5-9 November 2006.
[11] B. Nuseibeh and S. Easterbrook, “Requirements Engi-
neering: A Roadmap,” Proceedings of the International
Conference on Software Engineering ICSE, Limerick, 4-
11 June 2000.
[12] T. R. Gruber, “Toward Principles for the Design of On-
tolo gies Used for Knowled ge Sh aring,” International Jour-
nal Human-Computer Studies, Vol. 43, No. 5-6, 1995, pp.
907-928. doi:10.1006/ijhc.1995.1081
[13] B. H. C. Cheng and J. M. Atlee, “Research Directions in
Requirements Engineering, Future of Software Engineer-
ing FOSE,” Proceedings of ICSE, IEEE Computer Soci-
ety, Minneapolis, 2007, pp. 285-303.
[14] B. Hoenderboom and P. Liang, “A Survey of Semantic
Wikis for Requirements Engineering,” Technical Report
RUG-SEARCH-09-L03, SEARCH, University of Gron-
ingen, Groningen, 2009.
[15] P. Hildreth and C. Kimble, “The Duality of Knowledge,”
Information Research, V ol. 8, N o . 1, 20 02 .
[16] I. Nonaka and H. Takeuchi, “The Knowledge-Creating
Company: How Japanese Companies Create the Dyna-
mics of Innovation,” Oxford University Press, New York,
[17] A. Cabrera and E. F. Cabrera, “Knowledge-Sharing Di-
lemmas,” Organization Studies, Vol. 23, No. 5, 2002, pp.
687-710. doi:10.1177/0170840602235001
[18] M. K. Smith, “Michael Polanyi and Tacit Knowledge, the
Encyclopedia of Informal Education,” 2003.
[19] E. Wenger, R. McDermott and W. M. Snyder, “Culti-
vating Communities of Practice,” Harvard Business School
Press, Bos ton, 2002.
[20] M. A. Chatti, R. Klamma, M. Jarke and A. Naeve, “The
Web 2.0 Driven SECI Model Based Learning Process,”
Proceedings of the 7th International Conference on Ad-
vanced Learning Technologies ICA L T-2007, Niigata, 18-
20 July 2007, pp. 780-782.
Cop yright © 2011 Sci Res. JSEA
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model 728
[21] C. Hoadley and P. G. Kilner, “Using Technology to Trans-
form Communities of Practice into Knowledge-Building
Communities,” SIGGROUP Bulletin, Vol. 25, No. 1, 2005,
pp. 31-40.
[22] I. Nonaka, R. Toyama and N. Konno, “SECI, Ba and
Leadership: A Unified Model Knowledge Creation,” Long
Range Planning, Vol. 33, No 1, 2 0 00, pp . 5- 3 4.
[23] A. Naeve, P. Yli-Luoma, M. Kravcik and M. D. Lytras,
“A Modeling Approach to Study Learning Processes with
a Focus on Knowledge Creation,” International Journal
Technology Enhanced Learning, Vol. 1, No. 1-2, 2008, p p.
1-34. doi:10.1504/IJTEL.2008.020228
[24] J. Wan, H. Zhang, D. Wan and D. Y. Huang, “Research
on Knowledge Creation in Software Requirement Deve-
lopment,” Journal of Software Engineering & Applica-
tions, Vol. 3, 2010, pp. 487-494.
[25] M. I. Kamata, “Software Requirements Elicited through
Human-Centric Chance Discovery,” AAAI Fall Sympo-
sium Technical Report FS-02-01, 200 2, pp . 99- 1 05 .
[26] K. E. Emam, S. Quintin and N. H. Madhavji, “User Par-
ticipation in the Requirements Engineering Process: An
empirical Study,” Requirements Engineering Journal, Vol.
1, 1996, pp. 4- 2 6. doi:10.1007/BF01235763
[27] S. Lauesen, “Software Requirements: Styles and Tech-
niques,” Addison-Wesley, Boston, 2002.
[28] T. Riechert, K. Lauenroth, J. Lehmann and S. Auer, “To-
wards Semantic based Requirements Engineering,” Pro-
ceeding s of 7th International Conference on Knowl- edge
Management I-KNOW’07, Graz, 5-7 September 2007, pp.
[29] K. Pohl, “Requirements Engineering,” Dpunkt Verlag,
Grundlagen, Prinzipien, Techniken, 2007.
[30] T. Riechert and T. Berger, “Leveraging Semantic Data
Wikis for Distributed Requirements Elicitation,” Pro-
ceedings of the 4th Workshop on Wikis for Software En-
gineering Wikis4SE at 31st International Conference on
Software Engineering ICSE’09, IEEE Computer Society,
Vancouver, 19 May 2009, pp. 12-19.
[31] B. Decker, E. Ras, J. Rech, P. Jaubert and M. Rieth,
“Wiki-Based Stakeholder Participation in Requirements
Engineering,” IEEE Software, Vol. 24, No. 2, 2007, pp.
28-35. doi:10.1109/MS.2007.60
[32] S. Lohmann, P. Heim, S. Auer, S. Dietzold and T. Rie-
chert, “Semantifying Requirements Engineering—The Soft-
wiki Approach,” Proceedings of the 4th Interna tional C on -
ference on Semantic Technologies I-SEMANTICS, ACM,
Graz, 3-5 September 2008, pp. 182-185.
[33] J. Trinkunas and O. Vasilecas, “A Graph Oriented Model
for Ontology Transformation into Conceptual Data Mo-
del,” Infor m ation Te c hnology and Contr ol, Vol. 36, N o. 1A ,
2007, pp. 126-132.
Cop yright © 2011 Sci Res. JSEA