Crosscutting Quality Attributes for Requirements Engineering

Abstract:

Quality attributes are usually integrated with functional requirements at the later stages of the software development process. One of the reasons is that the current approaches fail in dealing with the crosscutting nature of some of those attributes, i.e. it is difficult to represent clearly how these attributes can affect several requirements simultaneously. Since this integration is not supported from requirements to the implementation, some of the software engineering principles, such as abstraction, localization, modularisation, uniformity and reusability, can be compromised. What we propose is a model to identify and specify quality attributes that crosscut requirements including their systematic integration into the functional description at an early stage of the software development process, i.e. at the requirements stage.

Introduction:

Separation of concerns refers to the ability of identifying, encapsulating and manipulating parts of software that are crucial to a particular purpose [19]. Separation of concerns reduces software complexity and enhances understandability and traceability throughout the development process. It minimizes the impact of change promoting evolution.

Non-functional concerns, i.e. quality attributes, such as response time, accuracy, security, and reliability, are properties that affect the system as a whole. Existing approaches to deal with quality attributes have some limitations due to the diverse nature of these attributes. Most approaches handle quality attributes separately from the functional requirements of a system. This shows evidence that the integration is difficult to achieve and usually is accomplished only at the later stages of the software development process.

Another problem is that the current approaches fail in addressing the crosscutting nature of some of those attributes, i.e. it is difficult to represent clearly how these attributes can affect several requirements simultaneously. Since this is not supported from the requirements stage to the implementation stage, some of the software engineering principles, such as abstraction, localization, modularisation, uniformity and reusability, can be compromised. Furthermore, the resulting system is more difficult to maintain and evolve.

The above discussion highlights the need to include crosscutting quality attributes as fundamental modelling primitives at the requirements level. The motivation for this is essentially to provide improved support for separation of crosscutting quality attributes during requirements engineering, hence offering a better means to identify and manage conflicts arising due to tangled representations. This helps to reduce complexity by promoting traceability and reusability, benefiting the system’s adaptability and evolvability.

What we propose is a model to identify and specify quality attributes that crosscut requirements, including their systematic integration into the functional description at an early stage of the software development process, i.e. at the requirements stage.

The rest of this paper is organised as follows. Section 2 presents a model for early quality attributes and discusses its main activities. Section 3 applies the approach to a case study. Section 4 describes some related work. Finally, Section 5 draws some conclusions and points to areas for future work.

A Model for Early Quality Attributes:

The process model we propose is UML compliant and is composed of three main activities: identification, specification and integration of requirements.

• • The first activity consists of identifying all the requirements of a system and selecting from those the quality attributes relevant to the application domain and stakeholders.

  • The second activity is divided into two main parts:

    • (1) specify functional requirements using a use case based approach;

    • (2) describe quality attributes using special templates and identify those that cut across functional requirements (i.e. crosscutting quality attributes).

  • The third activity proposes a set of models to represent the integration of crosscutting quality attributes and functional requirements.

Figure 1 depicts the main activities of this model. The template we propose to specify a quality attribute was influenced by the approaches of Chung et al [3, 15] and Malan and Bredmeyer [13, 14] (see Table 1).

Template for Quality Attributes:

Conclusion:

Developing a seamless software development process that provides traceability and modularisation is of vital importance to maintainability and evolvability. Handling crosscutting quality attributes at the early stages of the software process avoids the well-known problems of tangled specifications and code. Several approaches have been proposed to handle quality attributes, but none of them addresses the crosscutting nature of some concerns. On the other hand, a lot of work has been carried on to deal with tangled code (e.g. aspect-oriented programming). This highlights the need to tackle crosscutting quality attributes at the requirements level. Therefore, the motivation for this work is to provide improved support for separation of crosscutting functional and non-functional properties during requirements engineering, hence offering a better means to identify and manage conflicts arising due to tangled representations.

Our approach proposes three main activities: identify, specify and integrate requirements, so that separation of concerns at the requirements level can be achieved. Firstly we identify all the requirements of a system and select from those the quality attributes relevant to the application domain and stakeholders.

Secondly, we specify functional requirements, using a use case based approach, and describe quality attributes using special templates, identifying those that crosscut functional requirements. Finally, we propose a set of models to represent the integration of crosscutting quality attributes with functional requirements.

Our future work will focus on validation of crosscutting quality attributes, their integration with other requirements and resolution of possible conflicts resulting from the integration process. Our goal is also to develop a notation to describe quality attributes, their interactions and composition relationships at the requirements level.