%0 Conference Paper %1 Kaiya2005 %A Kaiya, Haruhiko %A Saeki, Motoshi %B Proc. Fifth International Conference on Quality Software (QSIC 2005) %D 2005 %K %P 223--230 %R 10.1109/QSIC.2005.46 %T Ontology based requirements analysis: lightweight semantic processing approach

@inproceedings{Kaiya2005, added-at = {2011-01-17T15:22:00.000+0100}, author = {Kaiya, Haruhiko and Saeki, Motoshi}, biburl = {https://www.bibsonomy.org/bibtex/24766a11b0ab11ecfc51504d421b697eb/lama}, booktitle = {Proc. Fifth International Conference on Quality Software (QSIC 2005)}, doi = {10.1109/QSIC.2005.46}, interhash = {c7f5e742a8d0154d2cc7f8f3eb36936a}, intrahash = {4766a11b0ab11ecfc51504d421b697eb}, keywords = {}, month = {19--20 Sept. }, pages = {223--230}, review = {The authors propose a mapping between elements of a FRS and a domain ontology. given a mapping, one can reason on the ontology and thus process the FRS semantically without heavyweight NLP techniques. Aims: Detect incompleteness and inconsistency, measuring the quality of the document with respect to its meaning, and predicting requirements changes. Their ontology consists of a thesaurus and a set of logical inference rules. Ontology as a Semantic Model for RE Documents Ontology must have atomic concepts that are interpreted the same way by any stakeholder in a specific application domain. The ontology of the authors consists of a thesaurus: Concepts are functions, objects, environment:actor, environment:platform, constraint, or quality. Relationships are generalize, aggregate, synonym, antonym, associate, contradict, cause, apply, perform, support, or require. Incompleteness and inconsistencies can be detected due to the require and contradict relations in the ontology. The mapping between the FRS and the ontology is assumed to be achieved by the requirements analyst. Semantic analysis is performed via 3 FOL rules; e.g. VsVxVy: inSpec(x,s) && require(x,y) -> inSpec(y,s). The example is written in a somewhat "unnatural language": Requirements document for a music player: Play a music, pause. Go to net or previous music. Forward and rewind. Adjust volume and mute. Repeat play list. Random play list. Then they find several inconsistencies and incompleteness; e.g. play list is not clearly specified (whatever that means). Metrics for Requirements Documents They show 4 formulas for determining correctness, completeness, consistency, and unambiguity. All of them refer to the ontology as basis; thus everything from the domain must be in the ontology, but only that part of the world, that is supposed to be in the software/FRS. Since the ontology is assumed to be complete, a complete FRS must be inconsistent, iff the ontology contains contradict relations. Prediction of Requirements Change Idea: Collect patterns of requirements that change frequently to predict changes... They found the pattern of "append new functionality" and "improve the quality of existing functionality" (not very surprising though...!). Their require relation suggests functions that are likely to be added. The relation aggregate(x, quality) suggests things that are likely to change, if quality is to be improved. Again everything must be modeled in the ontology beforehand... Conclusion Domain ontology in high quality is indispensable for the presented approach. So they want to study, how to build high quality ontologies. --- Review Sven 1.) Mapping of requirements to domain ontology 2.) A tool to support the requirements engineer. 3.) Restricted languages (such as ACE) and formal notations have the inherent problems. Too hard to use or just not applicable to the existing domain without too much effort. Negative: As a matter of fact, this approach needs a perfectly suited ontology to work properly.}, timestamp = {2011-01-17T15:22:00.000+0100}, title = {Ontology based requirements analysis: lightweight semantic processing approach}, year = 2005 }