Enhancing Domain Knowledge for Requirements Elicitation with Web Mining

To elicit software requirements, we have to have knowledge about a problem domain, e.g., healthcare, shopping or banking where the software is applied. A description of domain knowledge such as a domain ontology helps requirements analysts to elicit requirements completely and correctly to some extent even if they do not have such knowledge sufficiently. Several requirements elicitation methods and tools using domain knowledge description have been thus proposed, but how to develop and to enhance such description is rarely discussed. Summarizing existing documents related to the domain is one of the typical ways to develop such description, and an interview to domain experts is another typical way. However, requirements cannot be elicited completely only with such domain-specific knowledge because a user of such knowledge, i.e., a requirements analyst is not a domain expert in general. Requirements could be also elicited more correctly with both specific and general knowledge because general knowledge sometimes improves understandings of analysts about domain-specific knowledge. In this paper, we propose a method and a tool to enhance an ontology of domain knowledge for requirements elicitation by using Web mining. In our method and our tool, a domain ontology consists of concepts and their relationships. Our method and tool helps an analyst with a domain ontology to mine general concepts necessary for his requirements elicitation from documents on Web and to add such concepts to the ontology. We confirmed enhanced ontologies contribute to improving the completeness and correctness of elicited requirements through a comparative experiment.

I. Introduction

Software systems are never used alone, but they used together with things in the real world, e.g., hardware, human, existing other systems and so on for resolving problems in the real world. Suppose requirements for a conference management system like EasyChair. A requirements analyst has to understand things such as submissions, review processes, notifications and so on if he has to develop the system. We call such a set of things related to similar problems as a domain in this paper. Software requirements analysts thus take such a domain into account when they define requirements for a software system that solves problems in the domain. To take them into account, the most effective way is to work with domain experts. However, they are so busy in general and it is hard to work together so frequently. In addition, such domain experts never work together earnestly if analysts have little knowledge about the domain. Therefore, software requirements analysts have to acquire domain knowledge as much as possible when they elicit and define requirements for a system that will resolve problems in the domain.