Analysis of Early Aspects in Requirements Goal Models: A Concept-Driven Approach - Transactions on Aspect-Oriented Software Development - page 67

complicated to understand. ” Tools that supported focused representations would
be desirable.

Question 5: Do you perceive the proposed approach to be compatible and
consistent with the existing practices, values, standards, and technologies shared
in your organization or institution?
Quality Attribute: Compatibility.
“ Too early to tell ” was a representative response to this question. Some an-
alysts expressed concerns to the proposed approach, such as scalability, tool
support, and so on.

Although this initial evaluation was preliminary and much improvement was
needed for the proposed approach, analysts felt that having a conceptually pre-
cise treatment for early aspects was necessary and important, and RGT and
FCA were to be readily used in RE to tackle interesting problems.

6 Related Work

Baniassad et al. [1] presented an integrated approach to manipulating early
aspects and exploiting them throughout the software development life cycle.
The approach emphasizes the use of intuition, domain knowledge, and heuristics
to facilitate the identification of aspects in requirements. In goal-based model-
ing, softgoals represent tangled and scattered concerns, and have been treated
as candidate early aspects recurrently in the literature (e.g. [25, 54]). Niu and
Easterbrook [25] argued that to become true early aspects, not just candidate
ones, softgoals need to have specific operationalizations, or advising tasks [54],
to contribute to their satisfactions. Yu et al. [54] also used the media shop ex-
ample in their study, but no attempt was made to show how their process could
be extended if multiple viewpoints and conflicting concerns were involved. Our
approach extends previous work and existing knowledge, thoroughly analyzes
the contribution links between tasks and softgoals in requirements goal models,
and provides a conceptually rigorous framework for handling various concerns
addressed in those models.
NFR catalogue [5] attempts to collate, from a wide range of sources, verifi-
able information on non-functional requirements in specific domains. One of the
main motivations of catalogue or ontology building is the possibility of knowl-
edge sharing and reuse: as soon as a particular domain (such as banking or
meeting scheduling) is fixed, it seems reasonable to expect a large part of do-
main knowledge to be the same for a variety of applications, so that the high
costs of knowledge acquisition can be better justified. Catalogue-based methods
suggest that requirements analysts equip themselves with a glossary of standard
terms to make communication easier and more precise. However, these methods
can cause problems when stakeholders continue to use different interpretations
of the terms codified in the catalogue. They also miss an important opportunity
to explore differences in stakeholders' own categories so as to better understand