Journal of Software Engineering and Applications, 2011, 4, 718-728
doi:10.4236/jsea.2011.412084 Published Online December 2011 (/journal/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. Email: az_chikh@ksu.edu.sa
Received October 7th, 2011; revised November 14th, 2011; accepted November 27th, 2011.
ABSTRACT
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 research has been continuously stru- ggling towards a higher abstract software modeling during 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.
Activities 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 s
oftware 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 researchers. They 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 relat
ed 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 work.
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 development.
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 inter-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 [11].
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 describe
d using an ontology language, with vary- ing degrees of formalization and expressiveness. 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 tools 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
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 membe
rs 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 than 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 & Takeuchi [16] propose the SECI knowledge creation model as a key for KM in organizations. They view knowledge as an activity rather than an object and they focus on knowledge creation, collab
oration and pra- ctices rather than knowledge transmission as stated in [20, 21].
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.
spring framework documentation
The creation of knowledge is a continuous process of dynamic interactions between EK and TK. The four modes 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 p
articipants share and articu- late their mental models and skills; 3) Systemizing Ba: 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 consider 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 process more sufficiently between the cus-tomer and the supplier, being respectively considered by the author as an application domain expert and an IT ex- pert.
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
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- section.
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 the 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 dev
elopment, 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- tegory.
Two domain ontologies are used by our framework to represent the domain knowledge: Application Domain Ontology (ADO) and Software Requirements Ontology (SRO).
∙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 semantic 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 ontology (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 separ
ation. 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- tails. Abstract requirements have the subclasses—Goal, Sce- 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 by integrating discussions amongst the stakeholders and voting in the model. In order to interlink requirements with existing documents or resources, SWORE contains the classes Raw Information and Reference Point together with suitable properties [28].
Style and Level, which are drawn using shading styles, are the main classes of the extended part. A software re- quirement 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” to a given mode gets through a transformation proc-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.
1swoogle.umbc.edu/.
2SWORE is available for download at: softwiki.de/SWORE.
A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model
722
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 s
pecification 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 dictionary style is one example of output of this mode. The externalization pro- cess is controlled, among others, by 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 knowledge.
∙ 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 combination.
∙ Internalization mode occurs in the exercising Ba. Software requirements specification and other softw
are 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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。