Section 17.1. REQUIREMENTS ENGINEERING

17.1. REQUIREMENTS ENGINEERING

Broadly scoped requirements and constraints form good candidates for aspectization at the requirements level. However, currently only a small set of requirements engineering techniques specifically aim to provide new abstractions and composition mechanisms to modularize and compose such concerns. Other requirements-level approaches achieve separation of concerns through the separation of functional and non-functional requirements. Non-functional requirements are constraints that affect several components of a system and are associated with quality of service (e.g., usability, security). Thus, they can be seen as good candidates for aspects.

Goal-oriented approaches [57], such as KAOS [25] and i* [86], are good examples of methods where non-functional requirements play a major role. A goal is an objective that the system under consideration should achieve. It can be formulated at different levels of abstraction, and it covers functional and non-functional concerns. The i* framework identifies and models organizational requirements and adopts the goal and softgoal modeling concepts. A softgoal represents a non-functional requirement that we expect to satisfy within acceptable limits.

There are other mechanisms, such as problem frames [43] and viewpoints [32], which manage concerns during requirements. Problem frames focus on the environment in which a system is located instead of the system itself or its interfaces. Problem frames are concerns that can be handled as aspects. Separation of crosscutting properties has been considered in PREView [76], a viewpoint-oriented requirements engineering method. A PREView viewpoint encapsulates partial information about the system. Requirements are organized in terms of several viewpoints, and analysis is conducted against a set of concerns intended to correspond broadly to the overall system goals. In applications of the method, the concerns that are identified are typically high-level non-functional requirements.

Approaches explicitly created to handle aspectual requirements are those presented in [7, 34, 68, 70]. Grundy proposes an aspect-oriented component requirements engineering (AOCRE) method targeted at component-based software development [34]. He has developed a categorization of diverse aspects of a system that each component provides to end users or other components (namely user interface, collaboration, persistence, distribution, and configuration). Baniassad and Clarke [7] propose Theme to provide support for aspect-oriented analysis and design through Theme/Doc and Theme/UML, respectively. In this section, we will focus on the analysis part of the approach and leave the design part to be analyzed in Section 17.3. Analysis is carried out by first identifying a set of actions in the requirements list that are, in turn, used to identify crosscutting behaviors. The authors define actions as sensible verbs for the domain. An action is a potential theme, which is a collection of structures and behaviors that represent one feature. The aspect-oriented requirements engineering (AORE) model [68, 70] relates concerns to requirements to see which concerns crosscut the stakeholders' requirements and qualify as candidate aspects. The model supports separation of the specification of aspectual requirements, non-aspectual requirements, and composition rules in modules representing coherent abstractions and following well-defined templates. The composition rules employ informal and often concern-specific actions and operators to specify how an aspectual requirement influences or constrains the behavior of a set of non-aspectual requirements. The modularization makes it possible to establish early trade-offs between aspectual requirements, thereby providing support for negotiation and subsequent decision-making among stakeholders. At the same time, early separation of crosscutting requirements facilitates the determination of their mapping and influence on artifacts at later development stages. Further support for traceability in the AORE model is provided by the PROBE framework [48], which generates proof obligations based on standard linear temporal logic that should hold for an aspect-oriented system from the initial aspectual requirements and their associated trade-offs. The temporal logic assertions can be used as input to formal methods tools such as model-checkers or as the basis for deriving test cases.

Given such a range of alternatives, how do we select what best satisfies an organization and its project needs? The decision process consists of two main steps. The first step is to select a subset of candidate approaches from the whole set of existing ones. The guideline to help us in achieving this is dictated by a set of organizational constraints, ranging from budget limitations to existence of expertise on particular approaches.

The second step is to choose one specific approach or an integration of several from the reduced set. The guideline here needs to take into consideration the development process we would like to use. The criteria that may influence our decision are:

Support for aspectual concepts. Does the approach support the basic AOSD concepts directly?

Activities of lifecycle. Which activities of the development process are supported?

Composition rules. Does the approach provide explicit rules to compose aspects with requirements?

Handling conflicts. Does the approach provide a method to identify and resolve conflicting aspects?

Maturity. Has the approach been used in real projects?

Mapping to later artifacts. Does the approach foresee how the aspectual requirements are mapped onto design and implementation artifacts?

Tool support. Does a tool support the approach?

Table 17-1 shows the results of applying these criteria to the approaches mentioned here.

Table 17-1. Comparing the Approaches

Criteria Approach	Support for Aspectual Concepts	Activities of Lifecycle	Composition Rules	Handling Conflicts	Maturity	Mapping to Later Artifacts	Tool Support
KAOS [25]	No	RE+specification	No	Yes	Yes	Yes	Grail
i* [86]	No	Org. req.+RE	No	Yes	Yes	No	OME
Problem frames [43]	No	RE+architecture	Yes	No	Yes	Yes	No
PREView [76]	No	RE	No	No	Yes	No	JPREView
AOCRE [34]	Yes	RE for CBS	No	No	Partially	Yes	JComposer
AORE [68, 70]	Yes	RE	Yes	Yes	No	Yes	ARCaDe
Theme [7]	Yes	Analysis and design	Yes	No	No	Yes	Theme/Doc

Considering this comparison table, the main issues that may help us in our decision are:

KAOS. KAOS is an established reference on goal-oriented approaches for requirements engineering. One of its main advantages is using a formal language (first-order temporal logic with real-time constraints) to specify critical parts of the system, besides allowing informal modeling. KAOS uses goals to detect and manage conflicts among requirements. It has been used in several industrial projects [57].

i*. The i* framework is very effective at identifying and modeling the business domain of an organization. It does not directly support mappings to later activities of the software lifecycle, but recent work is being developed to derive UML models from i* models [17, 71].

Problem frames. Problem frames categorize software development problems. As the author does not provide a systematic way to use the concepts, the approach may be difficult to learn and apply. Recent work combines problem frames with software architectures [37].

PREView. PREView has already been used in small- and medium-sized safety-critical systems. As such, it has the advantage of proposing a stable set of concepts and a reliable method. Beyond alerting the requirements engineer to the risk that viewpoint requirements and concerns may cause inconsistencies, the approach does not identify the mapping or influence of crosscutting properties on artifacts at later development stages.

AOCRE. AOCRE supports modularization of aspectual requirements during component-based software development. The strength of the approach is its focus on handling crosscutting concerns in component-based systems. Its major drawback is the lack of clarity on how to identify aspects for each component. Also, it lacks mechanisms to handle conflicts and omits how aspects and components are integrated together.

Theme/Doc. Theme/Doc supports the requirements analysis activity by providing an approach to identify base and crosscutting behaviors. Having a tool that supports lexical analysis of the requirements to identify the major actions of a domain and relate them with the original requirements is an interesting feature. Having the major actions related between them through the requirements is a good basis to help identify behaviors that may be crosscutting.

AORE. In the AORE approach, the separation of composition information from the aspectual and non-aspectual requirements makes them highly independent of each other, thereby providing an improved separation of concerns. This also improves the reusability of the aspects in some instances. Since the composition rules operate at the granularity of individual requirements, it is possible to identify and manage conflicts at a fine granularity. This optimizes the task of the requirements engineer identifying negotiation points for the stakeholders. The identification of the mapping and influence of a requirement-level aspect promotes traceability of broadly scoped requirements and constraints throughout system development, maintenance, and evolution. However, the approach is in its infancy, needing to be validated in real projects.