1. Camilo Fitzgerald UCL Computer Science
Support for Collaborative Elaboration of Requirements Models
Camilo Fitzgerald
UCL Computer Science
06th March, 2009

2. Scope Requirements Elaboration in Collaborative Environments:
Requirements Engineering is a highly collaborative process.
Projects like Firefox and Ubuntu have demonstrated the success of using collaborative environments for requirements elaboration.
The Problem:
Elaboration currently takes place though free-for-all discussions with multiple discussants, after which the models are updated.
Discussants have different views, which frequently lead to arguments that are unstructured and pathological.

3. Existing Work The Literature:
Little work exists that aids multiple-parties with conflicting viewpoints to elaborate requirements collaboratively.
That which does exist requires a single analyst to seek resolutions to the conflicts between discussants.
Alternative – Involve discussants directly:
It is the contributors themselves who have the knowledge needed to resolve these conflicts.
We no longer need to encode their viewpoints for an analyst.

4. Arguments over a Goal-Graph
The Principle:
Discussants collaboratively construct a goal graph and annotate it with issues and arguments.
Annotating a model element will require a series of subsequent actions to be performed in order to remove it.
The discussants are advised on the different sets of actions available to them and their respective benefits.
Application of these actions will drive forward the goal-graph’s elaboration and resolve conflicts of opinion.

5. Example (1)
Alice constructs the following partial goal-graph for a meeting scheduler specification:
Achieve [Meeting Request Satisfied]
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

6. Example (2)
Bob believes that the Participant’s Constraints Known goal is too ideal and so places an Over-Optimistic annotation on it.
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

7. Example (3)
The Over-Optimistic annotation has the following properties:
Annotation Annotation A
Owner Bob
Instance Of Over-Optimisation Annotation
Concerns Goal (Achieve[Participant’s Constraints Known])
Informal Definition We cannot guarantee that every intended participant will communicate their date constraints in due time.

8. Example (4) The discussants are then advised on subsequent actions:
Weaken the goal on which the Over-Optimistic annotation is placed
Or, remove the goal on which the annotation is placed
Or, place a Challenge annotation on the Over-Optimistic annotation
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

9. Example (5)
Alice is not happy with the placement of the Over-Optimistic annotation and so places a Challenge annotation upon it:
Challenge
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

10. Example (6) The Challenge annotation has the following properties:
Annotation Annotation B
Owner Alice
Instance Of Challenge Annotation
Concerns Over-Optimistic Annotation(Annotation A)
Informal Definition Why can we not guarantee that every intended participant will communicate their date constraints in due time?

11. Example (7) The discussants are then advised on subsequent actions:
Either, remove the Over-Optimistic annotation
Or, strengthen the Over-Optimistic annotation
Challenge
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

12. Example (8)
Bob decides to strengthen the Over-Optimistic annotation, adding to its definition:
Annotation Annotation A
Owner Bob
Instance Of Over-Optimisation Annotation
Concerns Goal (Achieve[Participant’s Constraints Known])
Informal Definition We cannot guarantee that every intended participant will communicate their date constraints in due time. For example, some participants may be unreachable.

13. Example (9) The discussants are then advised on subsequent actions:
Either, remove the Challenge annotation
Or, strengthen the Challenge annotation
Challenge
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

14. Example (10)
Alice now believes that the Over-Optimistic annotation is justified and so removes the Challenge annotation:
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

15. Example (11) The discussants are now advised to:
Weaken the goal on which the Over-Optimistic annotation is placed
Or, remove the goal on which the annotation is placed
Or, place another Challenge annotation on the Over-Optimistic annotation
Achieve [Meeting Request Satisfied]
Over-Optimistic
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

16. Example (12)
Collin decides that a weakening of the goal would be the best solution, and alters the goal’s definition:
System Goal Achieve [Participant’s Constraints Known]
Owner Alice
Instance Of Information Goal
Concerns Meeting, Participant, Scheduler,
Informal Def Constraints will be known by a certain date for all participants invited to a meeting. Those who have not replied by this date are removed from the list of expected participants.

17. Example (13) The Over-Optimistic annotation is removed, and:
The elaboration process has progressed.
Conflicts of opinion between discussants have been resolved.
We have gained some ‘free’ rationale.
Achieve [Meeting Request Satisfied]
Achieve [Participant’s Constraints Known]
Achieve [Meeting Planned]
Achieve [Participants Notified]

18. Benefits of the Contribution
The technique results in:
Guided discussions that drive forward the elaboration process.
Arguments take take less time and effort to reach conclusion.
The ability to check for circular arguments, or those that are diverging from closure.
Free rationale recording.
Direct discussant involvement when resolving conflicts in opinion.
No heavyweight formalisation of discussants viewpoints needed.

19. In Development
Annotations - A minimal, yet powerful set of annotations that allow contributors to raise issues and deal with conflicts of opinion.
Strategies - Sets of strategies available to discussants when dealing with different annotations, and the benefits of using them.
Disagreement Support - Support for cases where contributors disagree on which annotation removal strategy to follow.
Prototype – A modified version of the Trac tool to demonstrate the technique’s capabilities. prototype tool

20. Contact Information
Camilo Fitzgerald
University College London
Dept. of Computer Science, MPEB
London WC1E 6BT
Office: 7.08
Tel: +44 (0) (Direct Dial)
Fax: +44 (0)
C.Fitzgerald (at) cs.ucl.ac.uk
Web:
Supervisors: Emmanuel Letier & Anthony Finkelstein