Ontology Development for the Domain of Software Requirement Elicitation Technique

: - Domain ontology is the ontology of describing domain-specific objects, it provides definitions of the concepts in a specific domain, as well as the relationships between them. 5W1H analysis method is widely utilized to give a comprehensive and delicate analysis to a specific issue. The Hierarchical Modelling Methods which includes: Button-Up, Top-Down and Middle-Out is used to model concepts. These conceptual modelling methods solved the real problem in different application domain, but they did not give an analysis and extraction method for concepts and relations in domain ontology, especially large and complex ones, and not present a general modelling method suitable for all kinds of domain ontology. Domain ontology for software requirement elicitation is developed using 5W1H approach, the ontology specify concepts (classes) and relations between the concepts in software requirement elicitation domain. The 5W1H approach helped in extracting and analyzing concepts and relations within the domain of discourse. In this project, 5W1H conceptual modelling method is used for classifying the concepts in the software requirement elicitation domain, the concepts in the domain were extracted from six interrogative elements of 5W1H, which include: Who, When, Where, What, Why and How, and relations between those concepts is built.


INTRODUCTION:
The success of a software project is heavily dependent on the quality of requirements capture and analysis. According to the survey in many failed software projects, the projects that failed because of the bad requirements account for about 45%. Errors made in this process are extremely expensive to correct when they are detected during implementing or testing period. Affected software quality would give a significant impact on society and economy such as increasing costs and business interruption (Fauziah B, et al. 2005). A good requirement specification document can help to avoid the early mistakes, improve efficiency and rate of success of software project development but this can only be achieved if requirements are elicited properly. In the past two decades, many experts in the field of software requirement elicitation had come up with many methods of capturing requirements, however, there is still communication gap between the customer and requirement analyst, one of the reasons is lack of explicit or agreed-upon definition of the key concepts in software requirement elicitation domain. Thus, the need to develop Ontology for the Software requirement elicitation domain. The creation of ontology in the domain of requirement elicitation can strengthen the communication between customer and requirement analyst which lead to the development of more reliable software. The ontology is a repository of questions, can be expanded by adding more questions. Ontology is a discipline that is part of the knowledge representation field (Sowa, 2000). In ontology, a precise definition is associated with each concept and relationship type that is used.

LITERATURE REVIEW
In the study by (LI et al, 2007) a formal approach that uses description logic to describe ontology is suggested, integrity and derivation rules are modelled, these rules restrict business behaviour. Syntax, semantics and visualization are the three aspects in which these rules are represented. The requirements model checking framework is also provided combining domain ontology and domain rules, which makes the requirements elicitation process both guided by domain ontology and restricted by domain rules. Hence, making the acquired requirements comply with both the business rules and domain knowledge. It gives a requirements model with UML class diagram and checks the model using domain ontology and rules.
According to (Yuqin and Wenyun, 2006), domain ontologybased approach was proposed which can be used to elicit and also analyze requirements. The top down method where problem is decomposed into several sub problems is used. when decomposing problem domain, abstract stakeholders other than practical ones where used. Incompleteness and inconsistency of domain requirement is detected using reasoning logic based on ontology relations. The proposed requirements elicitation method using ontology does not give a method to improve the quality of the elicited requirements.
In the study by (Maria and Achilles, 2011), A domain Ontology was developed using use case diagrams. this is done so that creators of educational materials that are related to software engineering course can have common references. Some software engineering experts assessed the ontology and satisfies that all aspects of UCD is adequately covered. the Ontology proposed can be used in various aspects such as in the field of object-oriented analysis, a part of e-learning application etc. The proposed Use Case diagram ontology fulfils the requirements that he had defined, as it can help to the semantic annotation and retrieval of learning resources, such as learning objects and learning goals, and it can answer queries about the field of METHODOLOGY In this study, the methodology of (Uschold, M. King, M. 1995) is employed. This is based on the experience of developing the Enterprise Ontology, which is a collection of terms and definitions relevant to business enterprises (Grüninger, M., Fox, M, 1995). The stages are as follows: Identifying the domain, Concepts Identification, Concepts Organization, Ontology representation and finally, Evaluation. It is worth mention that, for the Concept Organization, the "5W1H" conceptual modelling method is employed and the Ontology representation is done using Protégé. Fig 1 below represents the methodology (b) Concepts Organization (Hierarchy): There are several possible approaches in developing a class hierarchy (Uschold and Gruninger 1996). In this study, we use the top-down approach, which begins with the definition of the most general concepts and subsequent specialization of the concepts. The 5W1H conceptual modelling method is a modelling method that is made up of six interrogative element which are What, Why, Where, When, Who and How. Through 5W1H approach, concepts of domain ontology is extracted from six aspects and relations between those concepts is built. 5W1H method is originally used to completely report a piece of news story by answering six questions as follows: What, Why, Where, When, Who and How (Carmagnola, F. 2008). The 5W1H method is widely utilized to give a comprehensive and delicate analysis to a specific issue or knowledge, such as in production, management, marketing and so on. Similarly, domain ontology covers distinct knowledge among certain domains. To construct domain ontology, the first important step is to completely and accurately extract knowledge as a set of concepts and relations, and their domain as the same (Stader, J. 1996).
In the ontology, the most general classes of questions were created first: What, Where, Why, When, Who, and How, all as subclasses of the default root class Thing. Each of these classes is followed by subclasses which are less general than the upper classes, and subsequent specialization of these classes. The figures below diagrammatically depict how the ontology hierarchy has been designed: (c) To represent this ontology, Protégé is used. This is an ontology editing tool, made by Stanford University. its user Interface is highly usable. Protégé is highly recognised in terms of its scalability and extensibility.

CONCLUSION
The presence of the domain knowledge for software requirement elicitation will have a big influence on efficiency and the completeness of the requirements gathered in the requirements elicitation process for developing information systems. Acquisition of the domain knowledge is especially important for the requirements elicitation by novices in the task. In this project, a domain ontology was developed for requirement elicitation, which defines concepts in the domain. The effectiveness of the ontology was confirmed by the evaluation carried out using recall and precision method which determine the relevancy and irrelevancy of the concepts defined in the domain ontology. REFERENCES: