Object-oriented analysis and design have been more concerned with system functionality, neglecting non-functional aspects; the result is code which is tangled and difficult to maintain, contradicting main principles of object orientation. Aspect Oriented Software Development (AOSD) proposes the early specification of non-functional requirements. However, a standard and homogenous vision of the AOSD terminology is still missing. The goal of this work is to integrate AOSD concepts, classic requirements engineering notions, and the new standard ISO/IEC 25030 on software quality requirements.The main result of this study is the REASQ (REquirements, Aspects and Software Quality) conceptual model, expressed in UML. All the modelling concepts are formalized into three related ontologies, representing the ambits of aspect-orientation, software quality and requirements engineering. The ontologies can be used as an umbrella to specify quality requirements in aspect-oriented engineering processes.

The comprehension and correct specification of requirements increase with the complexity of present software systems, particularly if they have to respond to requirements going beyond the range of the main system functionality and that must be taken into account early during the development process. The Scientific community focuses now on the requirements engineering discipline, for the importance of nonfunctional or quality requirements with direct impact on the accomplishment of the main system's functionalities. This work models an aspect-oriented quality requirements engineering process (AOQuaRE), based on the treatment of non-functional requirements scattered and/or entangled among the functionalities of the system (crosscutting concerns), from the early steps of the development process.An important contribution of this work is the specification of quality requirements by the new standard ISO/IEC 25010 for software product quality.Keywords-crosscutting concern, aspect, software quality, AOSD, SQuaRE, AOQuaRE. I. INTRODUCCIÓNUna de las mejores prácticas de la ingeniería del software es seguir un proceso de desarrollo maduro. Así, la metodología del proceso de desarrollo ha evolucionado buscando mejoras para garantizar la calidad del producto de software resultante. Sin embargo, como describir y garantizar un producto de software de calidad de acuerdo a la madurez del proceso, es una actividad aún poco clara. Los métodos de desarrollo de software existentes son dirigidos más por la especificación de la funcionalidad del sistema que por la consideración de sus aspectos no funcionales. En general, estos aspectos no funcionales son considerados en etapas posteriores del desarrollo, contribuyendo con el enmarañamiento y la dispersión del código final, contradiciendo la propiedad de flexibilidad a cambios del desarrollo orientado a objetos.Por otra parte, la comprensión de los requisitos y la importancia de su correcta especificación, se incrementa drásticamente con la complejidad de los sistemas de software, particularmente si éstos tienen que responder a exigencias que van más allá del alcance de sus funcionalidades principales tales como interoperabilidad, adaptabilidad, disponibilidad, seguridad, entre otros. Estas exigencias pueden estar asociadas a las funcionalidades o no, pero deben ser consideradas oportunamente por los profesionales del software en el desarrollo de sus aplicaciones y deben dirigir la atención de la comunidad de investigadores hacia la disciplina de la ingeniería de requisitos, en particular hacia los requisitos no funcionales, los cuales tienen un impacto directo en el cumplimiento de la funcionalidad principal o servicio ofrecido por los componentes del software. Estos requisitos no funcionales asociados generalmente a las propiedades de calidad del software y que en muchos casos se diseminan y entrecruzan entre las funcionalidades principales (requisitos funcionales), dificultando su entendimiento, mantenimiento y reutilización, son reconocidos generalmente como incumbencias o concerns ...