Collaborative Requirements Engineering: Bridging the Gulfs Between Worlds - Intentional Perspectives on Information Systems Engineering - page 356

Filters

Reliability

Carer
vets

Learning
Operation
Other stakeholder

Improve
Social Skills

Cost

Review
before
send

Privacy

+ benefit influence Cost -ve influence

Goal Alternatives- FRs - FRs FRs FRs Criteria Criteria Criteria - NFRs Criteria - NFRs NFRs NFRs

Fig. 3 Design rationale diagram (QOC notation [13] , example from [34] ) which illustrates the
decision space of design solutions to address the user's personal goal to improve his/her social
skills in e-mail communication

of working memory since large quantities of information can be inspected at will,
so we can read information rather than having to remember it. The representation
becomes an external extension to our memory. Representations support negotiation;
for example, design rationale [ 6] (see Fig. 3) presents a set of alternatives (solu-
tions) for a requirements problem (the issue in gIBIS) and criteria through which
alternatives can be debated. Design rationale summarises the decision space as the
common ground for negotiation.
Other representations, ranging from decision trees to decision tables and ranked
lists, all help to summarise the decision space so dialogues can progress towards
an agreed common ground. In many cases software tools facilitate the process by
comparing many attributes of requirements and proposed solutions, for example
House of Quality decision matrixes [ 10] , or goal trees in Analytic Hierarchy Process
[ 12] .

4.4 Validate and Communicate

These activities have very different implications for common ground. Validation is
the process of establishing that the requirements specification and proposed system
design satisfy users' requirements. In this case the external behaviour of the sys-
tem is the necessary common ground which has to be tested and agreed between
developers and users. Hence, in Fig. 2, validation occupies both areas of common
ground, discussing the results of walkthroughs, demonstrations and simulations,
while reviewing and critiquing the specifications when discrepancies between sys-
tem behaviour and user requirements have been discovered. Verification, in contrast,
addresses checking and proving the correct internal behaviour of the specified