This paper aims to develop an Indian-logic based approach for automatic generation of software requirements from a domain-specific ontology. The structure of domain ontology is adapted from Indian logic. The interactive approach proposed in this paper parses the problem statement, and the section of domain ontology, which matches the problem statement, is identified. The software generates questions to stakeholders based on the identified concepts. The answer is analysed for presence of flaws or inconsistencies. Subsequent questions are recursively generated to repair the flaw in the previous answer. These answers are populated into requirements ontology, which contains problem specific information coupled with the interests of the stakeholder. The information gathered is stored in a database, which is later segregated into functional and non-functional requirements. These requirements are classified, validated and prioritized based on combined approach of AHP and stakeholders’defined priority. Conflict between requirements is resolved by the application of cosine correlation measure.
TopIntroduction
Requirements engineering is a part of software engineering that deals with a structured set of activities needed to create and maintain a systems requirements document (Davis 1993; Kontonya and Sommerville, 1998; Loucipoulos and Karakostas, 1995; Martin, 1988). Requirements are obtained, stored, identified, classified, prioritized, traced and validated throughout the requirements engineering process. SRS (Software requirements specification) is the outcome of this process. Requirements engineering must concern itself with an understanding of beliefs of stakeholders (epistemology), the question of what is observable in the world (phenomenology), and the question of what can be agreed on as objectively true (ontology) (Bashar and Steve,2000). Software requirements specification (SRS) is a complete description of the behavior of the system to be developed. The requirements are collected from the stakeholders generally through traditional techniques (Bashar and Steve, 2000), i.e. by means of questionnaires and discussions, specific to the problem domain. The answers are gathered and the initial requirements are formulated. By further exploration of the requirements, more meaningful questions emerge for which the convincing answers are collected and organized into an SRS template. Requirements elicitation and documentation are complex activities. So, not only the requirements themselves but also the people involved and the means for managing the requirements will evolve during the project (Bjorn Decker et. al., 2007).
Automation of requirements engineering involves the following activities: development of domain-specific ontology, generation of questions from the domain ontology, generation of requirements template, filling the template by answers collected from the stakeholders, requirements database generation, requirements identification, classification and prioritization, and requirements validation.
The significance of automating requirements generation with respect to cognitive informatics shall be summarized as follows: The domain knowledge (say, Banking) of the requirements analyst is tapped into the domain ontology. This domain ontology is installed with the consulting entity which is a software agent. This entity interacts with the client entity situated at the client’s place in the customer environment. The client entity is also a software agent which may or may not have a previous notion about the requirements of the software (say, ATM) which is to be developed under that particular domain. While the client entity and the consulting entity interact with one another, their interaction appears as if two humans are interacting with one another. The reason is that, the consulting entity proposes various enquiries taken from the domain ontology, into the client entity, anticipating appropriate response. To generate a proper response, the client entity should analyse it’s own knowledge base, which is more similar to a system analyst at the customer site, trying to reason and answer out all the questions proposed to him with respect to the scope of the project. The responses proposed by the client entity is analysed by the consulting entity for the presence of flaws. The flaws identified are cleared by proposing further questions based on the flaws. To do this, the consulting entity executes a reasoning and inference procedure over the arriving responses, which is more identical to a requirements engineer talking to a system analyst over telephone. Therefore, the fundamental objective of the proposed idea is to provide the knowledge replica of system analyst and requirements engineer as ontologies at two different software agents and to allow them interact, reason, inference and conclude at the essential requirements needed for the software to be developed.