**4. KMoS-RE©: an approach from knowledge management discipline**

The KMoS-RE© strategy [6] is a high-level plan to achieve a set of requirements of a solution or product through the eliciting, structuring and creating of knowledge. Following the work of [24], the strategy consists of three phases: *domain modelling (DM), system modelling (SM)* and *specification developing (SD)* and structures its flow of activities according the KEM-RE. Furthermore, it includes transversal activities to identify and make explicit the most possible quantity of tacit knowledge. Those activities are conducted by the identification of presuppositions [18] and classification of verbs according the Blooms' taxonomy [23]. The strategy also includes artefacts to facilitate the sharing knowledge: a record of wrong beliefs and the PoK matrix (Section 4.3). A brief explanation of each phase is provided as follows:


has been demonstrated through the time. The system model is obtained from the KDEL and the conceptual model. The behaviours identified in this phase will also change the values of the PoK matrix.

• **Specification development phase (SD)**. In this phase, the requirements are derived from the Uses Cases' scenarios of the future system and incorporated into the solution requirements specification (SlRS).

**Figure 5** depicts a general view of the KMoS-RE© strategy in a unified modelling language (UML) activity diagram. Every activity of the strategy corresponds to one stage of the KEM-RE: model validations (MV) is related to knowledge validation (KV), knowledge elicitation (KE) is related with the stage of the same name, model discussion (MD) corresponds to knowledge sharing and exchange (KS & E) and domain modelling (DM), system modelling (SM) and specification development (SD) correspond to knowledge integration and application (KI & A). The swim lanes in the figure represent the activities developed by each type of actor.

**Figure 5.** Knowledge management on a strategy for RE.

**4. KMoS-RE©: an approach from knowledge management discipline**

**Figure 4.** Knowledge evolution model for requirements elicitation.

96 Knowledge Management Strategies and Applications

vided as follows:

The KMoS-RE© strategy [6] is a high-level plan to achieve a set of requirements of a solution or product through the eliciting, structuring and creating of knowledge. Following the work of [24], the strategy consists of three phases: *domain modelling (DM), system modelling (SM)* and *specification developing (SD)* and structures its flow of activities according the KEM-RE. Furthermore, it includes transversal activities to identify and make explicit the most possible quantity of tacit knowledge. Those activities are conducted by the identification of presuppositions [18] and classification of verbs according the Blooms' taxonomy [23]. The strategy also includes artefacts to facilitate the sharing knowledge: a record of wrong beliefs and the PoK matrix (Section 4.3). A brief explanation of each phase is pro-

• **Domain modelling phase (DM)**. In this phase, the terms, i.e. the concepts, attributes and relationships, and the basic integrity restrictions are formalized through a consensus, in order to understand the application domain without worry about the solution. The terms are recorded in the Knowledge of Domain on an Extended Lexicon (KDEL); a lexical that classifies them into objects, subjects and verbs. The KDEL is used to facilitate the building of a graphical conceptual model. The externalization of this knowledge will enable achievement a consensus among the stakeholders; hence to minimize the symmetry of ignorance. The concepts and relationships identified in this phase will generate the first version of the piece of knowledge (PoK) matrix. In addition, a graphical conceptual model is required in order to facilitate the cognitive dialogue with the domain specialists. Requirements engineers will decide what kind of conceptual model use, from entity-relationship model to

• **System modelling phase (SM)**. In this phase, the current and future system processes are formalized. The current system corresponds to the system, as it exists at present. The future system represents the system after the deployment of a solution or product. The Use Cases technique was selected to model the system, both current and future, because its usefulness

ontologies, depending on the characteristics of the domain.
