Handling Conflicts in Aspectual Requirements Compositions - Transactions on Aspect-Oriented Software Development - page 147

2.2 Specify Concerns

This task is composed of several subtasks whose main goal is to collect several types of
information about a concern, store that information in a template (see Table 1) and build
concern visual models (e.g., UML use case, interaction and class diagrams [22]).

Table 1. A template to specify concerns

Concern
Elements

Definition

Name Concern designation.
Description Short description of the intended behaviour of the concern.
Sources Source of information, e.g., stakeholders, documents, system's domain,
catalogues and business process.
Stakeholders Entities (person or organization) that have an interest in a particular
decision. This includes people who influence a decision, or can influence
it, as well as those affected by it.
Decomposition Concerns can be decomposed into simpler ones based on AND and OR
relationships. When all (sub) concerns are needed to achieve the concern,
we have an AND relationship. If not all the sub concerns are necessary to
achieve the concern, we have an OR relationship.
Classification Helps the selection of the most appropriate approach to model the
concern (e.g. functional, NFR [11]).
Type This element states if the concern is crosscutting or non-crosscutting.
This information is derived based on the “Required Concerns” (below).
List of Responsibilities
Responsibility
#

List of what the concern must perform; knowledge or proprieties the
concern must offer.
List of Contributions
Contribution # List of concerns that contribute/affect this concern. This contribution can

be positive ( + ) or negative ( - ).

List of Importance
Stakeholders'
Importance

Expresses the importance of the concern for a given stakeholder. It can
take the values: Very Important , Important , Medium , Low , Very Low and
Don't Care .
List of Required Concerns
Required
Concerns#

List of concerns needed or requested by the concern being described.

The Name element is the concern designation, while the element Description
provides a textual explanation about the concern's objectives and behaviour. The
Sources element states the origins of the concern, having several possible values, as
stakeholder requirements, external catalogues of non-functional requirements (as in
[11]), etc.
Non-functional requirements are mapped into non-functional concerns. These
might be very coarse-grained, compared with other concerns. Therefore, we suggest
the use of Softgoal Interdependency Graphs (SIG) [11] that shows the