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

Tasks / Elements Softgoals / Constructs

Navigate[shop]
KeywordSearch[product]
ToolBox[shopping]

Customize[language]

WildcardSearch[product]
Report[shop]
PageLayout[GUI]
InfoBox[font]
SSL[protocol]
Cookie[transaction]
Template[layout]
Template[navigation]
Monitor[shop]

Consistency [D]
Availability [D]
Maintainability [D]
Adaptability [D]
Correctness [D]
Performance [D]
Confidentiality [D]

Usability [C,D]
Responsiveness [C]
Security [C,D]
Modifiability [C]
Accessibility [C]
Accuracy [C]

FAQ[shop]
PasswordProtection[account]
Manage[account]
EmailInformation[product]
FaxInformation[product]
HttpForm[order]

SecureForm/HttpsForm[oder]

Fig. 7. List of elements and constructs for media shop

in Fig. 7. In our approach, the set of tasks determines the common ground and
is shared among all analysts. In addition to its name, each task also contains
the subject matter [55] shown in squared parentheses. Softgoals are treated as
personal constructs, so we specify the owner(s) after each softgoal in Fig. 7.
Where softgoals have the same name but different owners, we treat them as dis-
tinct constructs. The labeling convention — explicitly marking every softgoal's
owner after it (“C” refers to “customer” and “D” represents “developer”) —
is adopted in this paper. This also addresses the traceability concern from the
model management perspective [40].
The construction of a repertory grid is perhaps best regarded as a particular
form of structured interview with each stakeholder. The answers to such ques-
tions as, “how does this task affect the system's maintainability?”, may give
us an understanding of the interweaving of the stakeholder's terminology and
provide us with an understanding of her outlook that no dictionary could offer.
Exchange : Each grid expresses the way in which a particular stakeholder views
the domain and in what terms she seeks to make sense of the underlying elements.
Each of these dimensions is expressed in personally meaningful terms, and is
significant to the person who used it.
In a shared context, each stakeholder's personal construct system overlaps to
some degree with others, and this makes it possible for people to exchange their
grids data to share their individual perceptions of the domain. Such exchange
needs to be administered in a structured manner in order to reduce stakeholders'
cognitive burdens, and at the same time, to achieve sensible results that are
amenable to interference analysis.
We only exchange the extracted common set of tasks between stakeholders,
and keep the use of softgoals inside each person's individual conceptual sys-
tem. Structural exchange allows the tasks in the goal model derived from one
stakeholder to be assessed by another in order to determine whether the two
stakeholders have consensus or conflict in their use of terminology and concepts.
In our approach, only concrete entities, i.e., tasks, are exchanged, because at
this stage, the abstract constructs only have meaning within each person's indi-
vidual conceptual system. A construct is a discriminator, not a verbal label [10].