Crosscutting quality attributes for requirements engineering

Moreira, Ana; Araújo, João; Brito, Isabel Sofía

doi:10.1145/568760.568790

Cited by 72 publications

(52 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Cada caso de uso de calidad (denominado así por el tipo de concern que representa, es un caso de uso incluido, según Moreira y otros [16] permitirá describir los diferentes aspectos no funcionales del sistema. Se propone la utilización de una plantilla de descripción de concern (tabla 2) por cada concern de calidad para registrar su descripción, contribución a otros concerns.…”

Section: Ii22 Especificar Concerns De Calidadunclassified

“…• Relacionar cada caso de uso de calidad con los casos de uso funcionales a través de una relación de inclusión como en [16].…”

Section: Ii22 Especificar Concerns De Calidadunclassified

“…son representados como casos de uso particulares, denominados casos de uso aspectuales debido a que representa un "aspecto" y deben estar relacionados con los casos de uso base del sistema mediante relaciones de inclusión o «include» [16], en lugar de relaciones de extensión o «extends» como lo plantean Jacobson y Ng en [14]. Se propone que la relación sea de inclusión debido a que se considera de gran importancia la consideración del concern transversal y debe necesariamente ocurrir, con una relación del tipo extensión la ocurrencia es menos fuerte y por tanto opcional.…”

Section: Representación Como Aspecto Candidatounclassified

“…El propósito de esta tarea es la relación de los diferentes concerns transversales (aspectos candidatos) con los concerns funcionales identificados, mediante la representación de tales aspectos en un modelo de casos de uso a través de un caso de uso aspectual utilizando el estereotipo <<aspecto candidato>> y utilizando la relación «include» como en [16].…”

Section: Ii31 Relacionar Concerns Funcionales Y Concerns Transversunclassified

See 3 more Smart Citations

A process for aspect-oriented quality requirements engineering: AOQuaRE

Castillo

Losavio

Matteo

2013

2013 XXXIX Latin American Computing Conference (CLEI)

View full text Add to dashboard Cite

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 ...

show abstract

Section: Ii22 Especificar Concerns De Calidadunclassified

“…• Relacionar cada caso de uso de calidad con los casos de uso funcionales a través de una relación de inclusión como en [16].…”

Section: Ii22 Especificar Concerns De Calidadunclassified

Section: Representación Como Aspecto Candidatounclassified

Section: Ii31 Relacionar Concerns Funcionales Y Concerns Transversunclassified

See 2 more Smart Citations

A process for aspect-oriented quality requirements engineering: AOQuaRE

Castillo

Losavio

Matteo

2013

2013 XXXIX Latin American Computing Conference (CLEI)

View full text Add to dashboard Cite

show abstract

“…In order to overcome the lack of expressiveness of the Use Cases, we have decided to exploit the extension proposed by Moreira et al (Moreira et al, 2002). This extension allows one to describe some stereotypes to describe quality factors such as security or reliability that can be applied to use cases to specify NFR.…”

Section: ) Use Casesmentioning

confidence: 99%

An empirical evaluation of requirement engineering techniques for collaborative systems

Teruel

Navarro

López-Jaquero

et al. 2011

15th Annual Conference on Evaluation &Amp; Assessment in Software Engineering (EASE 2011)

View full text Add to dashboard Cite

A collaborative system is a distributed software which allows several users to work together and carry out collaboration, communication and coordination tasks. To actions, usually by means of a set of awareness techniques. When we are defining a collaborative system, the awareness techniques can be considered as non-functional requirements bounded to some quality factors, such as usability. However, serious flaws can be found during the specification of these systems if we use the usual Requirement Engineering techniques available, because their expressiveness limitations when dealing with non-functional requirements. In this paper an empirical evaluation is introduced to determine if these techniques are really appropriate to model groupware requirements and which is the best approach to specify this kind of systems. With this aim, a collaborative text editor is used to evaluate whether the current techniques for Requirement Engineering are appropriated or not, exploiting the relation between awareness capabilities and standard quality factors.

show abstract

Aspect‐Oriented Software Development: an Introduction

Brichau

Chitchyan

Rashid

et al. 2008

Wiley Encyclopedia of Computer Science and Engineering

View full text Add to dashboard Cite

Modularity of software has long been the primary mechanism used in software development to improve reuse and support maintainability. However, certain concerns do not fit the module boundaries in contemporary software‐development paradigms. The consequence of such crosscutting concerns, such as logging, persistence, security, and so forth, is that the responsibilities of the individual modules are not clearly demarcated. Not only is a module responsible for its core state and behavior (pertaining to its business functionality, for instance) but also for that of the crosscutting concern (such as logging). This phenomenon is referred to as tangling. At the same time, we observe the scattering effect whereby a given crosscutting concem,for example, logging, is not modularized in a single element and hence hampers our ability to reason about its effect and behavior with respect to the other modules; such reasoning requires inspection of all the modules where logging is realized. This requirement goes against the established best practice of separation of concerns because the crosscutting effect results in software that is difficult to understand and maintain. Addressing this problem of crosscutting is the main focus of aspect‐oriented software‐development (AOSD) techniques. In this article, we provide an introduction to AOSD by highlighting how it provides systematic support for identification, modularization, and composition of crosscutting concerns throughout the software lifecycle.

show abstract

Crosscutting quality attributes for requirements engineering

Cited by 72 publications

References 10 publications

A process for aspect-oriented quality requirements engineering: AOQuaRE

A process for aspect-oriented quality requirements engineering: AOQuaRE

An empirical evaluation of requirement engineering techniques for collaborative systems

Aspect‐Oriented Software Development: an Introduction

Contact Info

Product

Resources

About