In collaborative systems, users work together in order to collaborate, communicate and coordinate each other. To perform these tasks, users should be aware of other user's actions, usually by means of a set of awareness techniques. In this paper, CSRML (Collaborative System Requirements Modelling Language) is presented as an extension of i* to deal with the specification of the CSCW requirements. In these systems collaboration and awareness of other users' presence / actions are paramount. We apply CSRML to a conference review system, where papers are reviewed in a collaborative way.
Requirements elicitation can be considered the cornerstone to achieve the quality of the developed systems. Failing in accomplishing this phase can make the rest of the development process also fail, with the consequent cost in terms of time and money. Therefore, a correct requirements specification is paramount for any kind of system.
As in traditional single-user systems, CSCW (Computer Supported Cooperative Work) systems are not exempt from this need. They are a special kind of software whose users can perform collaboration, communication and coordination tasks. These systems have to be specified by using a special set of requirements, usually of a nonfunctional nature. They usually result from the users' need of being aware of the presence and activity of other remote or local users, with who they perform the above mentioned collaborative tasks. This is the so-called Workspace Awareness, which can be defined as the up-to-the-moment understanding of another person’s interaction within a shared workspace.
Then, a proper specification of the system, identifying clearly the requirements of the system-to-be, specially the awareness requirements, is one of the first steps to overcome this problem. 2
In previous works [
Because of the special kind of requirements of CSCW systems, we present CSRML as an extension of i* that includes some elements for modelling the special collaboration features of CSCW systems. The elements of CSRML (Fig. 1), excluding those whose meaning is the same as in i*, are: · Role: A role is a designator for a set of related tasks to be carried out. The difference between i* and CSRML is that an actor playing a role can participate in individual or collaborative tasks (through participation links) and can be the responsible for the accomplishment of a goal (through responsibility links). Thus, an actor can both dynamically change the roles it plays, and simultaneously play several roles. In addition, the graphical notation is also different from the i* role (the concept of role/actor boundary is not used in CSRML). · Actor: An actor is a user, program, or entity with certain acquired capabilities (skills, category, and so forth) that can play a role in executing (using devices) or being responsible for actions. An actor has to play a role (specified by means of a playing link, see Fig. 1) in order to participate in the system. · Task: The concept of task in CSRML is the same as in i*. They only differ in the introduced notation to define the importance of a task: one, two or three exclamation signs, depending on the importance of the task. Two kinds of CSRML tasks have been identified: ! Abstract task: This kind of task consists in an abstraction of a set of concrete tasks and, possibly, other elements. We are not able to assign participation links directly to this kind of tasks. ! Concrete task: These are the tasks the participants are involved to. The abstract tasks are refined in these ones. Participants will be assigned to the task through participation links. There are four types of these tasks: o Individual task is a task that an actor can perform without any kind of interaction with other actors. o Collaboration / Communication / Coordination task two or more actors are involved in order to perform any kind of collaboration / communication / coordination among them. · Awareness softgoal: CSRML refines the i* concept of softgoal into a new specialization: awareness softgoal, that represents a special need of perception of other user’s presence / actions, without which the task the user wants to perform would be affected negatively or even could not be done. · Awareness resource: This special kind of resource corresponds to an implementation or a design solution to accomplish an awareness softgoal. · Playing link: A playing link is used to represent when an actor assumes a role. This link has a guard condition that represent when a role can be played by an actor. · Participation link: A participation link denotes who are involved in a task. This link has an attribute to specify its cardinality, i.e., the number of users that can be involved in a task. · Responsibility link: A responsibility link assigns a role (played by an actor) to a (soft)goal or task. This link represents who is the stakeholder responsible for a goal/task accomplishment. It is not necessary that this stakeholder is involved in the goal sub-tasks. Nevertheless, if the role is responsible for a goal or task, this role is also responsible for the elements it is divided into, unless a responsibility link reaches one of the elements it is divided into.
Goal
Softgoal [!!! / !! / !] Task
Resource Individual Task
Awareness
Softgoal
D Dependency Link [Guard] Playing Link
Communication
Task Awareness
Resource Means-end Link
Task Decomposition Link Responsability Link
1..* Participation Link
Collaboration
Task
Coordination
Task Actor
Role
+ Contribution Link
It is worth noting an additional difference between CSRML and i*: CSRML is practically hierarchical (see Fig. 2 (a) (d)). Thus, it fosters the scalability of the model created by using this notation. In a first level, we have the Responsibility diagram, in which the system's main goal is decomposed into main tasks and quality softgoals. Also, in this diagram, the goals and tasks responsibilities are defined.
In a second level appear Task refinement diagrams, in which the system's main tasks are decomposed into new goals, softgoals, tasks and resources, and roles are assigned to tasks. This constitutes another difference between CSRML and i*. Because CSRML has been thought for collaborative systems, i* boundaries for actors/roles were discarded, since they would not support assigning a task to more than one role. In addition, the Quality factors diagram completes the system specification showing the quality softgoals and the elements that contribute to their accomplishment. 3.1
Case Study: Collaborative Conference Review System with CSRML To check out the validity of our proposal, we are going to use the CSRML notation to model a case study based on a collaborative conference review system in order to illustrate its expressiveness capacity for CSCW systems. First, in Fig. 2 (a), we can see the system goals diagram, in which the system main goals are defined. As shown, we are going to achieve the system goals by means of the realization of the system's main task: the preparation of the review process of papers for a conference by using techniques of collaboration among users.
Fig. 2 (b) shows the responsibility diagram with the main system’s task and its decomposition in quality softgoals and tasks. In this figure, it can be observed that the use of responsibility links shows who is responsible for goals and tasks. Note that if a role is responsible for a goal or task, this role is also responsible for the elements it is divided into, unless a responsibility link is specified to one of the elements it is divided into. Also, the playing links are used to represent the condition that must be met for an actor to play a role. For the sake of model readability, a task decomposition will be shown in Fig. 2 (c).
Fig. 2 (c) depicts Papers review task refinement diagram. In this figure, tasks are refined into more specific ones or new goals, until individual or collaborative (collaboration, coordination or communication) tasks are specified. It can be observed that for collaborative tasks, more than an actor (playing a role) is involved through participation links. This figure includes two awareness softgoals. One of them is related to the knowledge of who reviews each paragraph, and the other one corresponds to the use of remote cursors. In this figure, different cardinalities for participation links are used. For example, for Paragraph review, three experts must participate. Also, this figure illustrates some degrees of priority that can be assigned to tasks: normal, high ([!]), very high ([!!]) and highest ([!!!]).
Finally, Fig. 2 (d) depicts the Quality factors diagram. In this model, the quality factors that contribute to achieve the conference review with a high quality level are shown. These factors are represented as softgoals and they are related to the main quality softgoal by means of contribution links with positive contributions. The achievement of all these quality softgoals is obtained in different ways. For instance, the Helpfulness softgoal is achieved by means of an awareness softgoal and its corresponding awareness resource consists in a remote cursors implementation.
Conference preparation by
using techniques of col aboration among users Conference creation
Papers submission
Papers assignation
Papers review
Ensure compliance with
quality standards Chair CP
Main author
We found out in two previous works [
In order to check out the suitability of this language, we have modelled a collaborative system. For the sake of clarity, in this paper an excerpt of this system consisting in a conference preparation system with collaborative reviews has been presented. This case study was modelled because it has a set of characteristics that were hard or impossible to be represented with the original i* notation. These characteristics were properly described by introducing a set of new elements and links into i* notation. The quality and awareness representation has been made possible by means of new awareness elements and the inclusion of a new set of diagrams in order to provide some structure to the specification.
Resuming, CSRML helps in improving understandability [
One of our ongoing works is closely related to the development of e-learning systems. Since LoUISE research group has been working during the last years in this kind of systems, several patterns have been described up to date. One of the main problems they have is that they have been specified in an informal way that cannot be easily reused for the specification of different systems. Therefore, we are studying how CSRML can be used to improve their specification.
Another future work consist in a validation procedure to validate the developed CSCW system against the initial set of requirements specified with CSRML and his compliance with the ISO 25010 quality in use factors.
This work has been supported by the following projects: (PEII09-0054-9581) from the Junta de Comunidades de Castilla-La Mancha and (DESACO, TIN2008-06596C02-01) from the Spanish Government.