La orientación a aspectos y el nuevo estándar SQuaRE para requisitos de software

Isi Castillo^1,2, Francisca Losavio², Alfredo Matteo²

¹Universidad Nacional Experimental Sur del Lago, Laboratorio de Informática, Estado Zulia, Venezuela

²Universidad Central de Venezuela, Escuela de Computación, Centro ISYS, Caracas, Venezuela

castilloi@cantv.net, flosav@cantv.net, almatteo@cantv.net

RESUMEN

El desarrollo de software orientado a aspectos (AOSD), representa un nuevo paradigma de ingeniería de software basado en los conceptos de la programación orientada a aspectos (AOP). La investigación se centra en el tratamiento temprano de las incumbencias (concerns) transversales en combinación con los procesos clásicos de ingeniería de requisitos, en los cuales los requisitos de calidad son relevantes. A pesar del interés en esta línea de investigación, no resulta evidente encontrar una visión compartida y homogénea sobre los términos utilizados. El objetivo de este trabajo consiste en integrar los principales conceptos del AOSD con las nociones de ingeniería de requisitos y la reciente terminología sobre requisitos de calidad del nuevo estándar ISO/IEC 25030 (SQuaRE 25030), con el fin de establecer un mejor entendimiento y consenso hacia un vocabulario común para la emergente disciplina de la ingeniería de requisitos de calidad orientada a aspectos. El resultado principal de esta integración es un modelo conceptual, expresado en el lenguaje de modelado unificado (UML).

Palabras clave: Aspectos, Incumbencias, Incumbencias transversales, Ingeniería de requisitos, Calidad de software, ISO/ IEC 25030, ISO/IEC 25010, SQuaRE.

Aspect orientation and the new SQuaRE standard for software requirements

ABSTRACT

Aspect oriented software development (AOSD), based on aspect oriented programming (AOP), is part of the post-object paradigm of software engineering. This study deals with the early treatment of crosscutting concerns combined with classical engineering requirements processes in which quality requirements are relevant. In spite of the increasing interest in this line of research, a homogenous vision of the terminology involved is yet to be established. The goal of this work is to integrate the main concepts used in AOSD, with the notions of engineering requirements and the recent ISO/IEC 25030 software quality requirements terminology, setting the basis for a better understanding and consensus towards a common vocabulary for the emerging Aspect Oriented Quality Requirements Engineering discipline. The main result of this integration is a UML conceptual model.

Keywords: Aspects, Concerns, Crosscutting concerns, Requirements engineering, Software quality, ISO/IEC 25030, ISO/ IEC 25010, SQuaRE.

Recibido: enero de 2009 Recibido en forma final revisado: noviembre de 2010

INTRODUCCIÓN

Una de las mejores prácticas de la ingeniería del software, es seguir un proceso de desarrollo maduro. En este sentido, el proceso de desarrollo ha evolucionado buscando mejoras para garantizar la calidad del producto de software resultante. Sin embargo, 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 hacen mayor énfasis en la especificación de la funcionalidad del sistema que en considerar sus aspectos no funcionales. En general, estos aspectos no funcionales son considerados en etapas posteriores del desarrollo, lo que contribuye con el enmarañamiento y la dispersión del código final, y contradice la propiedad de flexibilidad de los cambios del desarrollo orientado a objetos. Por otra parte, la importancia de tener un entendimiento claro y una correcta especificación de requisitos, se ve influenciada por la complejidad de los actuales sistemas de software, en particular si estos tienen que responder a incumbencias (concerns) tales como interoperabilidad, adaptabilidad, disponibilidad y seguridad, propiedades que van más allá de las funcionalidades básicas del sistema o del servicio ofrecido por el componente de software. Estas incumbencias, que en general no son exigencias directas del usuario, pueden afectar a múltiples componentes (Brito & Moreira, 2003); por ello la importancia de ser consideradas desde las etapas tempranas al igual que las funcionalidades básicas. En la actualidad, la disciplina de ingeniería de requisitos está tratando de establecer un razonamiento preciso para considerar estos tipos de requisitos que afectan múltiples componentes. La ingeniería de requisitos orientada a aspectos (AORE) y el diseño arquitectural orientado a aspectos (AOAD) (Early Aspect Home Page, 2008; Filman et al. 2005), estudian la identificación y el manejo temprano de las incumbencias transversales (concerns transversales) para mejorar la calidad del código (Brito & Moreira, 2003a; Brito & Moreira, 2003b; Early Aspect, 2008; Filman et al. 2005; Rosenhainer, 2004). Este enfoque se conoce como aspectos tempranos (early aspects). En lo sucesivo se hará referencia al término concern.

Una incumbencia o concern es una propiedad o punto de interés de un sistema (Filman et al. 2005). El Instituto de Ingenieros Eléctricos y Electrónicos (The Institute of Electrical and Electronics Engineers, Inc , IEEE) define el término como aquellos intereses relacionados con el desarrollo del sistema y su operación, o cualquier aspecto crítico e importante para los stakeholders o participantes en el proyecto de software (IEEE, 2000). En ISO/IEC 9126-1 (2001) un concern es un requisito del sistema, es decir una consideración que debe ser tomada en cuenta para satisfacer una meta del sistema. Kiczales et al. (1997) en la AOP, define a los concerns transversales como los concerns que son encontrados dispersos en múltiples módulos o enmarañados en un único módulo, por ejemplo persistencia de datos, control de acceso. Un aspecto en la AOP, es definido como una unidad modular diseñada para implementar un concern; puede contener código con instrucciones de dónde, cómo y cuándo invocarlo (Filman et al. 2005). En la ontología presentada en Van den Berg et al. (2005), un aspecto es definido como una unidad que modulariza un concern transversal. Kiczales et al. (1997) define un aspecto como la estructura que encapsula un concern transversal. En nuestro trabajo, un aspecto es considerado como una unidad que implementa un concern transversal de acuerdo a la definición presentada en la ontología de orientación a aspectos (Van den Berg et al. 2005). La separación de los concerns transversales y su composición en aspectos, en las primeras etapas de la ingeniería de requisitos, son las principales tendencias de investigación en la disciplina de aspectos tempranos o Early Aspects.

Por otra parte, en la literatura los conceptos aspectos y concern son frecuentemente considerados sinónimos. En la AORE, los términos requisitos y concern son utilizados indistintamente y las incumbencias transversales o concerns transversales son asociados indistintamente con un alto nivel con las propiedades de calidad o requisitos de calidad del producto de software, tales como disponibilidad, confiabilidad y en un bajo nivel con los atributos de calidad (o atributos medibles) como tiempo de respuesta, en el sentido de ISO/IEC 9126-1. En Rosenhainer (2004) un requisito es considerado un tipo especial de concern. Nótese que los principales conceptos y definiciones utilizadas en el dominio del AOSD son extensiones de la terminología de la AOP (Kiczales et al. 1997; Laddad, 2003). En la actualidad, son pocos los trabajos presentados donde se asocie la orientació con aspectos, el estándar ISO/IEC 9126-1 para especificar requisitos de calidad y la ingeniería de requisitos. Navarro et al. (2004) presenta una propuesta para organizar los requisitos integrando técnicas orientadas a aspectos dentro de un enfoque orientado a metas. Van den Berg et al. (2005) presenta una primera versión de una ontología sobre la orientación a aspectos, en particular en esta ontología se incluye un glosario para términos comunes del AOSD y una propuesta para un framework conceptual.

El objetivo principal de este trabajo es establecer un modelo conceptual que integre la emergente terminología del AOSD, la reciente terminología sobre requisitos de calidad de los nuevos estándares ISO/IEC 25030 (2006) e ISO/IEC 25010 (2007), y de algunas nociones de ingeniería de requisitos presentadas en RECLAMO (Chirinos et al. 2004). Este modelo pretende establecer un mejor entendimiento y consenso hacia un vocabulario común que pueda ser usado en el contexto de una emergente disciplina de Ingeniería de Requisitos de Calidad Orientada a Aspectos (AOQuaRE). Además de la introducción, este trabajo está estructurado de la siguiente manera: la sección 2 introduce la familia de estándares SQuaRE: ISO/IEC 25010 (2007) para especificar el modelo de calidad del producto de software y ISO/IEC 25030 (2006) para la identificación de los requisitos de software. La sección 3 presenta el modelo conceptual integrado propuesto. La sección 4 presenta brevemente un caso de estudio y, finalmente, se presentan las conclusiones y trabajo futuro.

SQuaRE

SQuaRE está conformado por una familia de estándares sobre requisitos de calidad de software y evaluación, agrupados en varias divisiones, bajo el titulo general Software Product Quality Requirements and Evaluation (ISO/IEC 25030, 2006; ISO/IEC 25010, 2007). De acuerdo al estándar sobre requisitos de calidad SQuaRE 25030 (2006), el sistema de software es usualmente parte de un sistema más grande y complejo, en el cual los requisitos de software y requisitos del sistema están estrechamente relacionados y los requisitos de software no pueden ser considerados de manera aislada. En consecuencia, es importante considerar los requisitos de calidad de software en las primeras etapas del ciclo de vida, como parte importante de la especificación general de requisitos. Este estándar se enfoca en los requisitos de calidad bajo una perspectiva del sistema. En SQuaRE, los requisitos son categorizados en ISO/IEC 25030 (2006) y especificados mediante un modelo de calidad según el estándar ISO/IEC 25010 (2007) (actualmente sigue en vigencia el estándar ISO/IEC 9126-1). El modelo de calidad está organizado jerárquicamente en características y subcaracterísticas hasta los atributos, los cuales son los elementos medibles. Los atributos especifican los requisitos de calidad del software en términos de medidas y valores objetivos. El estándar proporciona una serie de recomendaciones y una guía para especificar estos requisitos, para así garantizar que estén en conformidad con las necesidades de los participantes en el proyecto de software o stakeholders. En particular esta investigación se centra en los estándares ISO/IEC 25010 (2007) (modelo de calidad) y ISO/IEC 25030 (2006) (requisitos de calidad) de la serie SQuaRE, presentados a continuación.

ISO/IEC 25010 (2007)

Los productos de software son construidos conforme con necesidades específicas requeridas por sus usuarios. Su calidad es determinada en la medida de que estas necesidades son alcanzadas. La especificación de la calidad del software debe ser detallada y precisa. El modelo de calidad es una manera de formalizar esta especificación. ISO/IEC 25010 - Quality Model (ISO/IEC 25010, 2007) será una actualización del actual estándar ISO/IEC 9126-1 (ISO/IEC 9126-1, 2001), con el mismo propósito de definir un modelo de calidad y de proveer una guía práctica sobre el uso del modelo de calidad. De acuerdo a la versión en revisión de ISO/IEC 25010, un modelo de calidad está definido como un conjunto de características de calidad, subcaracterísticas y sus relaciones; proporciona un framework para especificar los requisitos de calidad y evaluar la calidad de un producto de software, ofreciendo un entendimiento común y la terminología de calidad de software. Las características son refinadas en subcaracterísticas, en una jerarquía multinivel y éstas en atributos los cuales son los elementos medibles a los que se les asignan métricas. ISO/IEC 25010 es una revisión del actual estándar ISO/IEC 9126-1 (ISO/IEC, 2001), con cambios menores. La versión en revisión de ISO/IEC 25010 (2007) mantiene las mismas definiciones de ISO/IEC 9126-1, sin embargo en cuanto a la estructura, cambia en la característica “funcionalidad”, y en particular sus sub-características “seguridad” e “interoperabilidad” pasan a ser características de alto nivel, llevando de 6 a 8 las características del ISO/IEC 9126-1. Efectivamente, para tratar con las aplicaciones actuales de software, por ejemplos orientadas a servicios Web, resulta más natural considerar estas propiedades como características de primer nivel. Según ISO/IEC 25010 (2007), la calidad del producto está definida en general por tres modelos de calidad: modelo de calidad interna, externa y de calidad en uso.

ISO/IEC 25030 (2006)

ISO/IEC 25030 – Requisitos de calidad (ISO/IEC 25030, 2006) que proporciona una guía para identificar los requisitos de calidad del software, para validar la completitud de la especificación de los requisitos y para identificar criterios de aceptación y aseguramiento de calidad del producto de software. Enfoca principalmente los requisitos de software; la categorización completa de los requisitos en ISO/IEC 25030 (2006) se muestra en la figura 1.

De acuerdo a la categorización propuesta en la figura 1, los requisitos de software dirigen el proceso de desarrollo de software (producto de software). Los requisitos del producto de software incluyen requisitos funcionales y de calidad (requisitos de propiedad inherente) y requisitos gerenciales (requisitos de propiedad asignada). Los requisitos funcionales incluyen requisitos específicos del dominio de aplicación, así como también los requisitos funcionales de los usuarios; estos requieren el alcance de metas de calidad las cuales son también un tipo de requisito de calidad. Los requisitos de calidad pueden también implicar requisitos estructurales y arquitecturales. Los requisitos de propiedades asignadas representan los requisitos que pueden cambiar sin que ocurran cambios en el software, incluye, por ejemplo, requisitos por el precio, fecha de entrega, suplidor del producto. En ISO/IEC 25030 los requisitos funcionales determinan lo que el software es capaz de hacer y los requisitos de calidad determinan como se ejecuta el software. En otras palabras, los requisitos de calidad muestran el grado con el cual el software es capaz de proveer y mantener sus servicios y tienen tres vistas diferentes: requisitos de calidad en uso, requisitos de calidad interna y requisitos de calidad externa (ISO/IEC, 2006).

MODELO INTEGRADO PARA LA INGENIERÍA DE REQUISITOS DE CALIDAD ORIENTADA A ASPECTOS

El modelo conceptual integrado propuesto facilita el razonamiento sobre las principales nociones inherentes a una disciplina de requisitos de calidad orientada a aspectos. En nuestro modelo los elementos requisitos de software, concern y características de calidad son las principales nociones utilizadas para interrelacionar la terminología más resaltante de tres ámbitos: requisitos de software, orientación a aspectos y calidad de software, en los cuales se integra la terminología del AOSD, ISO/IEC 25030 y 25010 para la categorización de los requisitos y algunas nociones de RECLAMO (Chirinos et al. 2004; ISO/IEC, 2006; ISO/IEC, 2007; Sommerville et al. 1997) (figura 2).

De manera general, se consideran los requisitos como descripciones del comportamiento principal del sistema o de sus propiedades o atributos y/o de las restricciones sobre el proceso de desarrollo y/o del entorno de ejecución (Sommerville et al. 1997; Wiegers, 2003). Los requisitos de software son especificados y derivados de los requisitos del sistema, en el sentido de ISO/IEC 25030 (2006). Sin embargo, consideramos que las reglas de negocio impuestas por la organización que requiere el producto de software, pueden imponer algunos de los requisitos del sistema. Las reglas de negocio pueden venir también de una organización externa, por ejemplo una institución gubernamental y pueden estar relacionadas con componentes existentes, a menudo restringen quien pueda ejecutar determinados casos de usos o estipular que el sistema de software debe contener cierta funcionalidad para cumplir con las políticas de la organización. Por otro lado, las reglas de negocio pueden implicar metas de calidad específicas que son implementadas como un mecanismo o componente (funcionalidad implícita), en adición a la funcionalidad básica. Así, el modelo de metas de Lamswerdee (2003), el framework de requisitos no funcionales (NFR) de Chung & Yu (2000) o los recientes enfoques de Brito & Moreira (2003a, 2003b), pueden ser usados para especificar tempranamente esta funcionalidad implícita. Una funcionalidad implícita puede ser considerada como un requisito funcional no expresado directamente por el usuario. Según el acuerdo general (Brito & Moreira, 2003a; Sommerville et al. 1997; Wiegers, 2003), los requisitos de software son clasificados en requisitos funcionales y no funcionales, en ISO/IEC 25030 los requisitos no funcionales corresponden directamente a los requisitos de calidad (figura 1) (ISO/IEC, 2007). Así, en el modelo se tiene la relación de herencia para expresar que los requisitos funcionales y de calidad son una especialización de los requisitos de propiedad inherente (figura 2). Los requisitos funcionales capturan el comportamiento del sistema y pueden ser expresados como servicios o componentes que deben cumplir metas de calidad específicas.

Los requisitos de calidad especifican las condiciones que el sistema debe satisfacer para restringir, condicionar o controlar la ejecución de los componentes del sistema. De acuerdo a ISO/IEC 25030 (2006), un requisito de calidad está asociado con una característica de calidad y es definido por un modelo de calidad (ISO/IEC 25010, 2007), el cual es usado para caracterizar el dominio de aplicación. Adicionalmente los requisitos de calidad según ISO/IEC 25030, están categorizados en requisitos de calidad en uso, requisitos de calidad interna y externa (expresados por las relaciones de herencia en el modelo).

Con respecto al ámbito orientación a aspectos en el modelo, un concern define un requisito de software y este es especializado en concern funcional, no funcional y concern transversal. Obsérvese que los concern funcionales y no funcionales pueden ser omitidos en el modelo por la relación existente con los requisitos de propiedades inherentes. Sin embargo, se han dejado para mostrar que un concern puede entrecruzar tanto a un concern funcional y a un no funcional.

Por otra parte, un concern transversal es implementado por un aspecto mediante un mecanismo de composición, un aspecto también puede implementar una funcionalidad implícita. Un mecanismo de composición define un aspecto y tiene asociado tres conceptos de gran importancia: punto de corte, puntos de unión y avisos (Van den Berg et al. 2005; Laddad, 2003).

Un punto de corte es una expresión que identifica un punto específico o conjunto de puntos en la ejecución de un sistema. Los puntos de unión que ejecutan los avisos, son también definidos por el mecanismo de composición y representan los puntos de interés en algunos artefactos del ciclo de vida en el cual dos o más concern pueden ser compuestos. Los avisos proveen las acciones que ocurrirán en los puntos de unión y complementan o restringen otros concern en dichos puntos. Los puntos de corte, puntos de unión y los avisos, son elementos esenciales para implementar un aspecto. Una característica de calidad derivada de un requisito de propiedad inherente o de una funcionalidad implícita, puede ser un potencial concern transversal y por tanto un aspecto candidato. Este punto es de gran importancia para el tratamiento de los aspectos en las etapas tempranas del desarrollo de software, donde la noción de aspecto candidato es introducida (Brito & Moreira, 2003a). El estándar ISO/IEC 25030 (2006) está relacionado solamente con el ámbito de los requisitos de software del sistema en general y no trata con el ámbito de orientación a aspectos; sin embargo, en el modelo las relaciones entre estos ámbitos se han establecido. Adicionalmente, el ámbito de la calidad de software del estándar ISO/IEC 25010 (2007) ha sido también modelado y relacionado con los otros ámbitos.

Finalmente, para concluir sobre la terminología discutida sobre tres importantes áreas de investigación de la ingeniería del software, puede indicarse que un concern corresponde a un requisito de software (Rosenhainer, 2004) que debe ser tratado en el desarrollo del software (Laddad, 2003), puede ser usado en la disciplina de ingeniería de requisitos y en el modelado de la arquitectura. Al usar el modelo se establece una correspondencia entre los estándares ISO/IEC 25030 y 25010 de SQuaRE y el emergente paradigma del AOSD. En la actualidad, los concerns no funcionales y los requisitos de calidad, están relacionados con una o más características de calidad del modelo de calidad (potenciales concerns transversales) lo cual representa una de las principales metas del desarrollo de software orientado a aspectos (AOSD, 2008; Filman et al. 2005).

CASO DE ESTUDIO

A continuación se ilustran algunos de los conceptos más relevantes del modelo propuesto, con el caso de estudio sobre una aplicación web para una tienda de juguetes en línea. La figura 3 presenta una versión simplificada del modelo de casos de uso para la aplicación, donde se identifican los principales requisitos funcionales (casos de usos) y los concerns transversales no funcionales asociados a tales requisitos funcionales (casos de usos incluidos como aspectos candidatos). Este caso de estudio está basado en una versión simplificada de una tienda de juguetes en línea: un cliente (usuario web) pueda comprar un juguete en línea registrando una cuenta y especificando un login. El sistema permite al cliente navegar a través de un catálogo en línea, el cliente puede agregar artículos a su carro de compra o removerlos sin dificultad; cuando el cliente desee cerrar la compra o “checkout”, su meta es comprar los artículos que se encuentren cargados en su carro de compras usando su tarjeta de crédito. Adicionalmente, un cliente puede verificar el estado de su orden y cancelar una orden sólo si la misma no ha sido procesada. En general, un cliente espera del sistema operaciones seguras, procesamiento rápido, navegación fácil a través del sistema, el cual debe operar los 365 días del año.

REQUISITOS FUNCIONALES Y REQUISITOS DE CALIDAD

Para este tipo de aplicación los concerns no funcionales (requisitos de calidad) son identificados y relacionados con los requisitos funcionales (tabla 1), posteriormente a estos requisitos de calidad le son asociadas características de calidad según ISO/IEC 25010 (2007) para identificar los concerns transversales más representativos. La tabla 1 presenta algunos de los elementos del modelo propuesto (considerados de mayor relevancia) y sintetiza la composición de los principales requisitos funcionales y de calidad del sistema. En la misma se identifican los concerns transversales más importantes y se denotan como aspectos candidatos (seguridad, disponibilidad, precisión, tiempo de respuesta, interoperabilidad, usabilidad). Estos concerns transversales son objetivos de calidad identificados de los requisitos funcionales y pueden ser implementados como un aspecto, razón por la cual se denotan como aspectos candidatos.

La figura 3 ilustra los concerns transversales identificados, los mismos son representados como un estereotipo denominado caso de uso “aspecto candidato”. Nótese que precisión aparece en un solo requisito funcional, por lo tanto no es transversal y que los requisitos interoperabilidad y disponibilidad dependen respectivamente del entorno de red y de la disponibilidad de los servidores, en una arquitectura orientada a servicios (SOA). La usabilidad es responsabilidad de la componente de Interfaz usuario.

CONCLUSIONES Y TRABAJO FUTURO

Este trabajo presenta un modelo conceptual en UML integrado para el razonamiento, entendimiento y manejo de las principales nociones relacionadas con el paradigma de desarrollo de software orientado a aspectos. El modelo integra tres ámbitos de investigación principales en la ingeniería del software: la ingeniería de requisitos clásica, el estándar de requisitos de calidad de software SQuaRE y el emergente paradigma del AOSD. Consideramos que el uso de estándares, aunque puede parecer restrictivo debido a que imponen normas rígidas, es en general un paso adelante hacia un entendimiento común para promover la adecuada interacción de grupos de trabajo con diferentes intereses y naturaleza; al ser la ausencia de entendimiento común en un equipo de desarrollo una de las principales causas de fallas en el software. Un ejemplo en la adopción de estándares por la comunidad es el uso de UML. El modelo presentado representa una herramienta útil en las etapas tempranas del desarrollo; por ejemplo, durante la modelación de la arquitectura del sistema, cuando los requisitos deben ser claramente identificados, clasificados y cuantificados. Su utilización como soporte en la definición de un proceso de ingeniería de requisitos de calidad y su formalización mediante una ontología es parte de nuestro trabajo en progreso. En particular el modelo será aplicado en la caracterización del dominio de los sistemas fiables, donde el manejo temprano de las incumbencias transversales es de crucial importancia.

LISTA DE TÉRMINOS

AOSD: Aspect Oriented Software Development

AOP: Aspect Oriented Programming

UML: Unified Modeling Language

AORE: Aspect Oriented Requirements Engineering

AOAD: Aspect Oriented Architectural Design

IEEE: Institute of Electrical and Electronics Engineers

RECLAMO: Requirements Classification Model

AOQuaRE: Aspect Oriented Quality Requirements Engineering

NFR: Non-functional Requirements framework

SOA: Service Oriented Architecture

AGRADECIMIENTOS

Se agradece a los árbitros por su aporte en la cuidadosa revisión de este trabajo, así como al Consejo de Desarrollo Científico y Humanístico (CDCH) de la Universidad Central de Venezuela, proyecto ADIRE, No. PG-03-7310-2008/1.

REFERENCIAS

1. AOSD Home Page (2008). Recuperado en Octubre 2008. http://www.aosd.net.        [ Links ]

2. Brito, I., Moreira, A. (2003a). Advanced separation of concerns for requirements engineering. VIII Jornadas de Ingeniería del Software y Base de Datos, JISBD 2003. Alicante, España. Recuperado en Diciembre 2008. http://citi.di.fct.unl.pt/member/member-act.php?id=30 & type=publications.        [ Links ]

3. Brito, I., Moreira, A. (2003b). Towards a composition process for aspect-oriented requirements. Early Aspects Workshop at AOSD Conference. Boston. Recuperado Diciembre 2008. http://citi.di.fct.unl.pt/member/member_act.php?id=30 & TYPE=PUBLICATIONS.        [ Links ]

4. Chirinos, L., Losavio, F., Matteo, A. (2004). Identifying quality-based requirements. Information Systems Management (ISYM). Auerbach Publications, 21(1), pp.15-21.        [ Links ]

5. Chung L., Nixon B., Yu, E. , Mylopoulos, J. (2000). Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers.        [ Links ]

6. Early Aspect Home Page. (2008). Recuperado en Octubre 2008: http://www.early-aspects.net        [ Links ]

7. Filman, R., Elrad, T., Clarke, S., Aksit, M. (2005). Aspect-Oriented Software Development. Addison Wesley, Boston.        [ Links ]

8. IEEE (2000). Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Std. 1471-2000.        [ Links ]

9. ISO/IEC 25030 (2006). Software Engineering. Software Product Quality Requirements and Evaluation (SQuaRE). Quality Requirements.        [ Links ]

10. ISO/IEC CD 25010 (2007). Software Engineering. Software Product Quality Requirements and Evaluation (SQuaRE). Quality Model and guide. Draft.        [ Links ]

11. ISO/IEC 9126-1 (2001). Information Technology - Software Engineering Product Quality. Part 1: Quality Model.        [ Links ]

12. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J. (1997). Aspect-Oriented Programming. ECCOP’97 Object-Oriented Programming, 11th European Conference, M. Aksit y S. Matsouka, Eds. LNCS 1241, pp.220-242.        [ Links ]

13. Laddad, R. (2003). AspectJ IN ACTION. Practical Aspect-Oriented Programming. Manning Publications.        [ Links ]

14. Lamsweerde, A. (2003). From system goals to software architecture. In M. Bernardo and P. Inverardi, editors, SFM, Formal Methods for Software Architectures. LNCS Springer-Verlag, pp.25-43.        [ Links ]

15. Navarro, E., Letelier, P., Ramos, I. (2004). Goals and Quality Characteristics: Separating Concerns. In Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design Workshop (AOSD). Lancaster.        [ Links ]

16. Rosenhainer, L. (2004). Identifying Crosscutting Concerns in Requirements Specifications. In Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design Workshop (AOSD). Lancaster.        [ Links ]

17. Sommerville, I., Sawyer, P. (1997). Requirements Engineering. A Good Practice Guide. John Wiley and Sons, New York.        [ Links ]

18. Van Den Berg, K., Conejero, J., Chitchyan, R. (2005). AOSD Ontology 1.0 - Public Ontology of Aspect-Orientation. Technical Report AOSD-Europe-UT-01, AOSD-Europe.        [ Links ]

19. Wiegers, K. (2003). Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. Microsoft Press, Washington, USA.        [ Links ]