4 Use-case Scenarios and Specification

• 4 Use-case Scenarios and Specification
  • 4.1 A Hypothetical Open Source Project
    • 4.1.1 Defining Organisational Processes
    • 4.1.2 Creating Groups and Associated Roles in Processes
    • 4.1.3 Processes of Entry and Exit to the groups
      • Entry and Exit to the Co-Developers Group
      • Entry to the Active Users Group
      • Benefits of using VOOP
  • 4.2 The Open Food Co-op3
    • 4.2.1 Defining Organisational Processes
    • 4.2.2 Creating Groups and Associated Roles in Processes
    • 4.2.3 Processes of Entry and Exit to the groups
      • Entry and Exit to the Coordinating Group
      • Entry and Exit to the producer and distribution groups
      • Entry and Exit to the producer and agents/shops groups
      • Entry and Exit to the consumer group
  • 4.3 VOOP Specification : System requirements
    • 4.3.1 Groups
      • G1 Hierarchical group structure
      • G2 A Seed Group
      • G3 Creating groups
      • G4 Group functionality
    • 4.3.2 The User
      • U1 Identity Creation & Login
      • U2 User profiles
      • U3 Joining Groups and Acquiring Roles
    • 4.3.3 Processes Types
      • Creating new types of processes
      • P1 Process Type Definition
      • P2 Creating Roles - Assigning Permissions to Groups
      • P3 Create Process Type
      • Joining and Leaving Group
      • J1 Apply
      • J2 Approve application
      • J3 Request to leave
      • J4 Approve Request to leave
      • Creating Sub-Groups
      • S1 Begin creating a Group
      • S2 Finish Creating the Group
      • Policy Document Management Components
    • 4.3.4 Distributed Features

The goal of the VOOP project is to develop an application, in which individuals or organisations can form and govern virtual organisations or virtual teams. The application will also contain a framework within which virtual organisations can flexibly specify and enact their governance processes.

The application will be known as the Virtual Open Organisational Platform or VOOP.

The Open Coop aims to use VOOP in order to map existing and prospective member organisations into a system of interrelated groups. In such interrelated groups, all participants can see the relations between the various groups, the members of the groups, the governance processes of the groups which are in progress, and those governance processes which are completed and no longer active. In this framework organisations will be "open organisations" in as much as they will have:

1. Transparency in the roles of participants
2. Clearly defined, and well documented, governance processes
3. Clearly defined rules surrounding participation in various sub-groups.

Such organisations or teams will be represented in VOOP as 'groups'. The interactions involved in governing the group will take the form of a set of processes.

Group creation and development is expected to reflect either the structure of an existing organisation, or a new organisation coming into existence in the virtual realm.

Since organisations are usefully analysed in terms of their processes 910, VOOP will facilitate the creation of, and participation in, governance processes. In particular the project will focus on the flexible specification and enactment of governance processes.

The following are use-case scenarios identified by the Open Coop which VOOP should enable. The first is a hypothetical use-case whilst the second is a use-case of an Open Coop project which is currently being developed by Dr Gary Alexander, Senior Lecturer in ICT at the Open University1 .

4.1 A Hypothetical Open Source Project

Much research exists concerning the social structure of Free Software and Open Source projects b3c79c9225919b63149d993fb382967f as well as Open Source projects as virtual organisations. Crowston and Howison b3c79c9225919b63149d993fb382967f follow many authors - Coxbd4e0f00e643977356e66ce17bf29a22, Gacek et al. 21, Mockus et al. 22, in characterising FLOSS2 projects as an "onion ring" diagram (as depicted in Figure 4.1). Moving from the centre of the diagram to the outer layers there are likely to be more participants and a lower level of involvement. At the centre are the few core developers who contribute the majority of the code and make the decisions about the evolution of the project. In the next layer come the co-developers who tend to contribute bug-fixes and make minor alterations to the code. Then come the active users who contribute bug reports and feature requests and can be quite large in number for some projects.



Figure 4.1: A synthesised FLOSS development team structure
(extract from Crowiston and Howison b3c79c9225919b63149d993fb382967f)

For a hypothetical example of a FLOSS project, with formally defined governance procedures, corresponding to the structure outlined above, the process of mapping the project into VOOP is outlined below. It should be stressed that many FLOSS projects do not currently have a formal governance structure. However according to the principles of open organisation, these projects are not open organisations since they do not have a written charter. It might be the case that were such an organisation to formalise its existing social structures, in order to become an open organisation, that processes similar to those specified below would result.

Formalising organisational processes should help organisations to ensure their organisational transparency. This is a key factor in simplifying participation in a core organising group for newcomers. Further, it should ensure that processes occur in a way which corresponds to the intentions of participants. Since unstructured interactions don't necessarily lead to the processes which were envisaged by participants, organisational governance/management is the activity of choosing processes 3.

4.1.1 Defining Organisational Processes

A core developer could set up a group on VOOP. She would first define a process relating to the high-level governance of the organisation. This might be considered the ultimate source of authority in the group/organisation. An example would be:

"policy proposals are debated for a week after which there is vote requiring the support of a majority of core developers. Also policy decision can be reversed with the agreement of more than 70% of the core developers."

Once a high level governance process like this is defined, the group is able to propose and approve lower level governance and management processes. At this stage the core developer creating the group might move on to the next stage of group creation, creating sub-groups and roles in the organisation. Alternatively they might choose to define some lower level processes which are already well established in the organisation. So for instance she might now define the following processes:


i) Proposals for developing a new branch of code. This might look like this:

"debate will continue for 1 day, then the proposal will be rated between +2 to -2 within the next 2 days. If the average rating is greater than 1 then the project will be taken to the implementation phase in which tasks, milestones, and dependencies will be mapped out and the developers will be assigned/assign themselves to tasks. After 3 months the implementation will be reviewed".



ii) Another process might be "bugtracking". Here the process could be defined as:

"any "active user" can submit a bug document, then a core or co-developer attends to it, and a core developer can archive it once it is fixed."

iii) In addition creating a feature request process would be a useful way of interfacing with the potential market for modifications to FLOSS software.

4.1.2 Creating Groups and Associated Roles in Processes

The group creator would then create three sub-groups with roles relative to the governance processes.

First, the Core Developer role would be the only role/group with permissions to take part in high-level governance process in any way. Second, they might be the only ones to be able to rate lower-level proposal for developing a new branch of code.
Additionally more specific roles such as "release coordinator" might be defined for individual members of the core group.

The co-developer role would have the permissions to contribute to processes relating to developing a new branch of code. However they would not be able to vote on proposals in this category.

Active users would be able to contribute to discussions and submit bug reports and feature requests as part of a code branch. If they so choose they should be able to attach bounties to feature requests and make them open for donations/bounties from others (this part will be beyond the scope of the project).

The group creator should send invitations to and/or create accounts for each of the core developers, co-developers and active users, to join VOOP. Each developer should then map themselves into the system by creating a personal profile with various attributes which should be configurable by group or by role.

4.1.3 Processes of Entry and Exit to the groups

Entry and Exit to the Core Developers Group
Once a Core Developers group is set up, entry to the group could require the approval of a certain percentage of the existing core developers. Other criteria of joining the group could be expressed informally, and implemented socially within the system. For instance if the group requires that to be a core developer an individual must have contributed more than 10,000 lines of code, then it will be the responsibility of each core developer not to approve an individual who has contributed less than this. It is normal in Open Source projects that since there are no contracts involved, developers can exit the project at will.

Entry and Exit to the Co-Developers Group

In order to become a co-developer an individual must get the approval of at least one existing co-developer or core developer.

Entry to the Active Users Group

Active users, should be able to register themselves without any approval, They should be able to create process instances under the classifications of, feature proposals, or bug reports.

Benefits of using VOOP

FLOSS projects have a tendency to have unclear and informal mechanisms of governance and decision making. By mapping their members and processes into VOOP they will formalize their governance mechanisms, and thereby increase their transparency, making it clear how to get involved and how decisions have been and will be made.

4.2 The Open Food Co-op3

Open Food Co-op, is an initiative of the Open Coop and is in the early stages of development. This is likely to be one of the first projects to pilot VOOP. The idea is to create a collaborative partnership between local organic food producers, shops/agents, distributors, and consumers.

4.2.1 Defining Organisational Processes

Once a group is set up on VOOP the high-level policy process will have to be defined. In this case it is expected that a Co-ordinating group will make policy for the whole group on a consensus basis. The process will look like this:

i) An issue is raised
ii) Coordinating group has a discussion.
ii) Coordinating group produces a proposal for a process which is approved by consensus (vote with single member veto).
iii) Proposal put to all members of the Open Food Coop for comment and approval by majority vote.
iv) If the proposal is approved by the Open Food Coop, it is implemented. Otherwise the Coordinating group reviews and revises the proposal, and either presents a new version or rejects the proposal.

The group creator could then go on to define further organisational processes before creating the group itself. Alternatively further processes could be defined from within the group using the above policy process. For instance a process may be defined corresponding to the process of getting food from producer to the consumer. This might look like this :

i) Food producers enter their produce for the next month or week into online forms.
ii) Consumers view the listings of food offered, select what they want, and select the shop/depot to which it is to be delivered. (In many cases, the consumers agents will do this on behalf of the consumers.)
iii) A logistics module lists the origins and destinations of produce needing to be delivered.
iv) The distributors view the listings and indicate which routes they will be making.
v) The distributors then transfer produce from the producer to the agents/shop.
vi) The produce and service is rated by the consumer.

N.B Its not expected that the necessary components to realise the logistics aspects of the process will be implemented as part of this project.

4.2.2 Creating Groups and Associated Roles in Processes

Five sub-groups with roles relative to the processes will need to be defined. Each member may be a member of more than one sub-group and thereby have more than one role.

i) Coordinating group
The coordinating group plays the main role in high level policy. That is they respond to issues raised by proposing policies. They also actively recruit for sub-groups such as producers, agents and distributor.

ii) Producer group
This group includes farmers, gardeners, and food processors (i.e. cheese makers, cooks) They are able to vote on policies proposed by the Coordinating group. They are able to put up produce on the consumer-producer process. Like most other groups they would elect a representative onto the coordinating group in order to represent their interests.

There might be different sub-groups within the producer group having slightly different roles. For instance it is anticipated that there will be both a farmers' group and a gardeners' group.

The producer group might also have an internal governance process aimed at optimising collective production to best match consumer demand.

iii) Distribution group
This group will include farmers and shops, and others who already do deliveries, to which will be added people willing to take on regular and irregular deliveries. The main function of this group will be to rationalise and co-ordinate the desired deliveries. They carry out stage v) delivering the produce from the farmer to the depots/shops. They will also elect a representative to the coordinating group.

iv) Agents
Agents act on behalf of consumers or producers who do not wish to participate in the computer network, entering transactions on their behalf. They will thus fulfill the function of actively increasing the consumer base (marketing). Agents may choose to work together to market produce under a collective brand. This would entail having an internal governance process, as well as defining various processes around the creation of brand.

v) Consumers
Receive info on what is available/coming soon from producers and events organisers. Many consumers may not interact with the Food Coop online but rather buy from an agent in the real world. Feedback from consumer will be actively pursued by the Food Coop, in order to feed into the Coordinating group's work. This would entail a process in which consumers report their experience and any major trends would be reported to the coordinating group. Consumers will also elect a representative to the Coordinating group.

4.2.3 Processes of Entry and Exit to the groups

Entry and Exit to the Coordinating Group

The Coordinating group will consist of one representative from each of the 5 sub-groups. These representatives will be elected by each subgroup, through a process of continual debate, and voting, which will occur every 6 months. There will be 1 week of debate by the end of which sub-group members will be expected to have voted.

Entry and Exit to the producer and distribution groups

This will require approval by the coordinating group. Approval will be determined by the explicit approval of at least one member of the Coordinating group but can be vetoed by any member of the coordinating group.

Entry and Exit to the producer and agents/shops groups

Anyone can choose to join this group, but those found to be misrepresenting the Food Coop or flaunting rules can be banned by the Coordinating group.

Entry and Exit to the consumer group

Anyone can join this group, however agents should actively seek to involve consumers with relations to them, in order to gain a visible online reputation.

4.3 VOOP Specification : System requirements

Here I will layout a functional specification for the implementation of the application. The features here are a distillation and to some extent a rationalisation of the requirements laid out in the use-case scenarios, as well as a few more general points from the Background and Context section.

4.3.1 Groups

G1 Hierarchical group structure

Organisations or teams will be represented as groups. Where an organisation consists of a number of teams or departments, the group representing the organisation will have a number of sub-groups. Therefore groups should be structured hierarchically.

So, for example, within the Open Coop group there might be a Open Food Coop group, and a Software Development group. Within the Open Food Coop group there would again be multiple groups, such as the Producers, Consumers, and Distributors etc.

System requirement: Hierarchically nested groups

G2 A Seed Group

To reflect the fact that the Open Coop is a membership organisation in which many groups operate, an initial seed group will have to be created from which users will then be able to navigate to and join the various groups. The seed group is also the place where organisations new to the Open Coop can create a group to represent themselves. In the deployment of the software for the Open Coop, this seed group will represent the Open Coop itself.

Since the system is intended to be an open-access system for creating virtual teams and organisations, any web-user will be able to create a group within the seed group. In fact its expected that the seed groups functionality will be restricted to having members join and create groups. That is, there will be no process for creating new process types in the seed group. This is intended to allow the seed group to be initially a place of experimentation where users can test the effects of different governance processes on the evolution of groups.

It is important to realise that the above configuration should be only one possible deployment of the software. For instance, the permission to create a new group in the seed group, could be allocated to a different group of trusted users with relatively stringent entry criteria (e.g. approval of existing members). Indeed its likely that in the virtual organisations which exist below the seed group that sub-group creation would be restricted.

System requirement: a seed group should be created from which all other groups are created and navigated to.

G3 Creating groups

When creating a new group, a user will first be expected to set the purpose and principles of the group. These are simple text entries which give potential members or collaborators useful information about the group.

The user will also be expected to define some key types of processes, as well as assigning roles within them. These are the types of processes which the group will have on creation. It is important to realise that once the group is created, new types of processes can only be created through existing processes. The system requirements for process definitions and roles are discussed in detail later.

In order to have full functionality, groups should normally be created with at least a minimal set of types of processes which allow:

1.creation of new types of processes,
2.joining or leaving the group,
3.creating a subgroup within the group.

It is perfectly possible that a group would not have all three of these processes on creation. However since they are normally expected, the user should be prompted to create each of these types whilst creating a new group.

System requirement: Flexible creation of types of processes when creating a group. Prompt the user to create core process types, as well as purpose and principles.

G4 Group functionality

Once a group is created, the group is the place from which new processes are initiated. Most processes will in some way modify some aspect of the group itself. For instance, when the process of a new user joining the group is completed, the user will be added to the group's user list. The user should also be able to browse from group to group, and browse the users of a group.

System requirement: The user should be able to initiate processes from within the group (assuming the user has the necessary roles), browse to other groups, or browse the users of the group.

4.3.2 The User

U1 Identity Creation & Login

Since the Open Coop is an open organisation any web visitor will be able to create a secure identity and begin using VOOP. Once an identity is created the user will be able to login using that identity, at this stage the user will not be a member of any groups, but will be able to browse the contents of groups.

System Requirement: Creation of secure identities.

U2 User profiles

The user must have a set of user-attributes which constitute a profile. A user-attribute will be a label associated with a typed value, for instance the label might be “age” and the value might be an integer of value 10. It should be possible for any individual to change their own user-attributes. Users should also be able to view each other's profiles.

System Requirement: User-editable profiles.

U3 Joining Groups and Acquiring Roles

Assuming a user has the roles which are necessary to apply to join a particular group, on requesting to join the group the user will have to go through the associated process. It is likely that this process will require the user to submit some details which are specific to the group. Once a user is a member of a group, the user will acquire the roles which have been allocated to the group.

System Requirement: Users acquire roles from their groups

4.3.3 Processes Types

Processes are the key mechanism for change in the system. The process types associated with a group, define the ways in which groups can be changed. By assigning roles in process types to other groups, we define the ways in which groups can interact.

In order to demonstrate the effectiveness of the underlying system, it will be necessary to develop a minimal set of components which can be composed into process types. Below I have grouped the elements by the process types they are intended for creating. There are also some extra components which might be used in many possible types of processes.

Creating new types of processes

In order that the governance of groups can evolve its necessary to have a process type which can be used to create new process types. P1 to P3 are the components its envisaged which will be required.

P1 Process Type Definition

A flexible way of formally specifying governance processes is essential to this project, since it is envisaged that many “organisational forms” will map themselves into the Open Coop system. The Process Type Definition component will allow the user to compose a process type definition. The process type definition specifies the order of components in the process and the conditions (constraints) on which a component activity is considered complete.

System Requirement: component for flexibly defining the order of components in a new process type


A process needs to be able to execute different branches of components depending on whether a certain precondition is met at a certain point in the process.

For instance in a policy-making process, a vote component might be an activity which forms part of a “make a policy decision” process which looks like this:





Fig 4.2 Branching in a Workflow on a Precondition


Depending on whether the precondition (“proportion_votes_for > 50%” in this case) is satisfied we execute either the Implement and Archive components or the Revise and Restart components.

When the “goal” (constraint) of the vote component is fulfilled the vote activity is complete and the policy process moves onto the next activity. What the next activity is, depends on the outcome of the vote with reference to a precondition (“proportion_votes_for > 50%”) for moving to the the next process.

System Requirement: need for branching in the process-based on preconditions


The process definition should allow customisation of certain stages in the process. For instance the voting stage could be configurable to facilitate majority decision or consensus with single member veto. While it is hoped that the process definition will be configurable through a simple web interface, this is probably beyond the scope of this project.

System Requirement: configuration of components as part of process definition

P2 Creating Roles - Assigning Permissions to Groups

Every component in a process has an interface which is made up of a number of method signatures. Each method signature can be assigned to any number of groups. The set of method signatures which any group has assigned to it for a process type is considered their role in the process.

This component allows roles in a process to be created thus assigning access to methods to members of the relevant groups. This component is of course dependent on P1, the process type definition component, since it is not possible to assign method signatures, until we know which components constitute the process.

System requirements: A component for assigning permissions in a process type to a group, thus creating roles in a process type each associated with a group.

P3 Create Process Type

Once a process type definition, and the roles in the process type, are fully specified, the process type will have to be created and added to the list of processes which can be initiated from the group. This needs to be a separate component so that it is possible for users to propose process type definitions and roles, which will only be realised under certain conditions. For instance, we may insert a vote component between P3 and P2 and then execute a different branch of the process definition depending on the result of the vote. P3 is dependent on both P1 and P2 having occurred earlier in the process.

System Requirement : Component to create previously defined process types

Joining and Leaving Group

J1 to J4 are the components that will be required in order for groups to have processes with which users can join or leave.

J1 Apply

This component should provide the necessary actions for the user to apply to join the group. The component should determine any user-attributes which are required by the group, but not already included in the user's profile. It should then request that the applying user enters the required details.

For example the main Open Coop group might require the fields: username, password, and email address. While the Open Food Group might require the fields username, password, telephone, and vegetarian. When a user who is already a member of the Open Coop applies to the Food group, they should be requested for their telephone number, and whether or not they are vegetarian.

System requirement: The component needs to be able to identify which of the required attributes are already fulfilled and which still need to be added to the users profile.

N.B By assigning the permission for initiating a group's, apply to join, process we can control who can apply to join a group. For example, if we assigned the permission to the Open Coop group, it would effectively be possible for every registered user to join the group. However if we assign the role to some other group X, then it will become necessary to join X before joining the original group.

J2 Approve application

In this component someone with the role to do so, can approve the application which was entered in J1. J2 is dependent on J1. When J2 is complete, the user who applied in J1 will be a member of the group.

If a group wanted to have some kind of vote on whether or not they should approve an application for membership, this could be done by inserting a vote component in the join process, between J1 and J2.

System requirement: Component for a user to approve an application, and add a user to the group

J3 Request to leave

If a user is already part of a group, they should be able to ask to leave the group using this component. It might also be possible for other users to suggest that a user is excluded from a group. This could use the same component, with a slightly different configuration.

System requirements: Component for a user to leave the group

J4 Approve Request to leave

This will remove a user from the group, and is dependent on J3. Of course, there may be other aspects of this process, for instance if a user is under contract. If the user has been asked to leave the group by another user there may be a debate and/or vote involved. Such other components should be placed between J3 and J4 in order to influence whether or not J4 will be executed.

System requirements: Component for a user to be removed from the group

Creating Sub-Groups

Users should be able to start new groups within existing groups by initiating the process to “create a new sub-group” (assuming they have the necessary roles). This process constitutes a group design exercise in which the stages of mapping the corresponding virtual organisation into the VOOP are executed. These stages will include defining the purpose and principles of the group, as well as designing the groups process types. Since creating new process types makes use of components P1 and P2 this is a good example of reuse of component interfaces.

S1 Begin creating a Group

Initially a 'purpose' and a set of 'principles' should be prompted for. This can be specified in text and act as guidelines for participants to think about the organisation. The component must also prompt the user to create the types of process that the group will be initiated with.

System Requirement: Component should prompt for purpose, principles, and process type creation

The next stages will involve defining governance processes for the group. Therefore it will be possible to use the components P1 and P2 for defining processes and creating roles.

S2 Finish Creating the Group

Once the required processes have been added to the group, this component creates the new group. S2 is dependent on S1. Once this activity is completed the group will have a new subgroup, with the corresponding processes created by components P1 and P2.

System Requirement: To be able to create a new group, as a subgroup of the group where the process was initiated.

Policy Document Management Components

In order to be properly considered a governance system it will also be necessary to have components for managing policy creation. These would include: proposing policy documents, debating, revising, and voting/rating.

System Requirment: A simple set of components for managing policy documents

4.3.4 Distributed Features

Ideally this project would be implemented as a distributed system of communicating web servers. Each server would host groups and would communicate in order to create seamless services. Anticipated services requiring distributed communication between instances of VOOP include:

1.Creating relationships between groups on different servers. For instance a group on one server may have a role in a process in a group on another server.
2.Creating topological graphs, for instance drawing graphs where the nodes are groups, and the arcs connecting the nodes are roles in the processes of other groups.

System requirement: An architecture that supports future development of distributed services. Due to time constraints it is not expected that any distributed services will be implemented as part of this project.