Linguistic Modeling Methods and Ontologies in Requirements Engineering Florian Lautenbacher 1 , Tanja Sieber 2 , Alejandro Cabral 3 , Bernhard Bauer 1 1 Programming Distributed Systems Lab University of Augsburg, Germany [lautenbacher|bauer]@ds-lab.org 2 Department of Information Science University of Miskolc, Hungary tanja.sieber@advan-ce.de 3 Oracle Strategic Program Buenos Aires, Argentina alejandro.cabral@oracle.com Abstract. Developing new software based on requirements specifications created by business analysts often leads to misunderstanding and lack of comprehension, because of the different background of the involved persons. If the requirements specifications instead have a clearly defined structure and comprehensive semantics, this obstacle can be resolved. Therefore, we propose to structure the requirements specifications using existing linguistic modeling methods and annotate the used terms with ontologies in order to enhance the understanding and reuse of these documents during the whole software engineering process. 1. Motivation Not only normal software development, but also the upcoming research area semantic-based software development (sometimes also called semantic-web enabled software engineering) typically has an iterative software development process starting with the requirements engineering and requirements analysis phase. Before beginning with the development of the software, the needs of the customer must be clarified and summarized into some requirements specification. These requirements contain all (or nearly most) of the details about the software product to be developed and are normally described in natural language. Some companies have therefore defined styleguides. However, most of the used terms are not defined in a concrete way which leads to misinterpretation and incomprehension, i.e. the semantics is not defined clearly. Sometimes glossaries are used to describe the expressions, but even those can be interpreted differently by various readers/writers. Missing or not clearly defined requirements lead to change requests for the software product once it is tested or in the worst case, when it is used by the customers. The customers might have thought of something different, but their requirement has not been described properly in the