Department of Computer ScienceUniversity College London

Requirements Conflict Resolution in Collaborative

Environments

Camilo Fitzgerald

First year VIVA Report for the degree of Doctor of Philosophy at University

College London

July 2008

Abstract

Management of conflicts in requirements engineering has been shown to be critical to a projects success, yet work in this area is still in its early stages. Collaborative environments are particularly well suited to requirements engineering, due its highly collaborative nature.

Even less has been done, however, to use the features available in a collaborative setting to provide solutions to the requirements conflict management problem. It is therefore proposed that research is conducted into finding new techniques for using these features to aid the requirements engineer in resolving requirements conflicts.

2

Table Of Contents

1 Introduction........................................................................41.1 Motivation........................................................................41.2 Article Overview...............................................................42 Context...............................................................................62.1 Goal-Oriented RE..............................................................62.2 Classification of Conflicts...................................................82.3 Conflict Management.......................................................113 Conflict Management in Requirements Engineering..............123.1 Overview........................................................................123.2 Requirements Partitioning...............................................133.3 Interaction Identification.................................................143.4 Interaction Focus............................................................163.5 Resolution Identification..................................................163.6 Resolution Selection........................................................183.7 Requirements Update......................................................193.8 Limitations of Current Techniques....................................194 Collaborative Environments in Requirements Engineering....224.1 Overview........................................................................224.2 Model-Based Support......................................................234.3 Process Support..............................................................254.4 Awareness Support.........................................................254.5 Collaboration Infrastructure Support................................264.6 Limitations of Current Techniques....................................275 Proposed Contribution........................................................296 Approach...........................................................................306.1 Scope.............................................................................306.2 Proposed Research..........................................................306.3 Validation of Research.....................................................316.4 Timetable.......................................................................31

3

1 Introduction

1.1 Motivation

A survey of large IT projects in the US conducted in 1995 found requirements related issues to be perceived as the major cause for impaired, challenged and failed projects (Standish Group, 1995). A more recent report from the Meta Group (2003) claimed that 60-70% of IT project failures are still to be attributed to poor requirements management. Correspondingly, a rapid growth has been seen in the past two decades in the field of requirements engineering as a response to the industry’s need for better solutions.

A study of 17 IT projects in 1988 found that “conflict among system requirements caused problems on every large project interviewed” (Curtis et al., 1988). More recently, a case study focusing on smaller projects noted that between 40% and 60% of system requirements were involved in conflict (Egyed and Boehm, 1998). Indeed, conflicts and interactions among requirements are commonplace and need to be managed carefully if a software project is going to stand a good chance of succeeding.

Conflict management has already been approached from several different angles. Support for dealing with conflicts has been incorporated into requirements frameworks such as i* (Yu, 1997) and KAOS (Lamsweerde et al., 1998). Meanwhile, various other frameworks such as WinWin (Boehm et al., 1995), CORA (Robinson, 1999) and the Viewpoints Framework (Finkelstein and Sommerville, 1996) have been specifically developed to manage conflicting requirements.

Some recent publications have taken steps to providing requirements conflict management in a collaborative web based environment. The SOP project (Decker et al., 2007) has developed a wiki using the Volere requirements specification template, and is currently in the process of integrating a consistency checker that will scan for inconsistencies in requirements documents created with their tool. WikiWinWin (Yang et al., 2008) is also in development, and aims to provide a wiki front-end to the WinWin tool.

The tools presented in these publications, however, are in their early stages and are limited in what they can achieve. Furthermore, many properties of collaborative environments are yet to be exploited within the context of conflict management.

4

1.2 Article Overview

The remainder of this article is split into five sections. Section 2 provides the background required to understand the article, in which the following aspects of requirements engineering are covered; goal-oriented requirements engineering, conflicts and conflict management.

Sections 3 and 4 then review the relevant literature on requirements conflict management and the use of collaborative environments. Both of these sections are structured according to themes; The six stages of Robinson’s requirements interaction lifecycle (Robinson et al., 2003) is used for the conflict management review, and Whitehead’s four areas of collaborative support (Whitehead, 2007) for the survey of collaborative environments.

A PhD research proposal is then put forward in section 5, and the approach for carrying out this research is given in section 6.

5

2 Context

This section briefly introduces the background for the remaining sections of the document. References provide links to further information on the topics discussed.

2.1 Goal-Oriented RE

A running example of a goal oriented requirements framework will be used to clarify the terms and concepts presented in this section. Furthermore, it is proposed in Section 6 that research validation will use an extension of such a framework. Some background on the subject will therefore be presented in this subsection. Goal-oriented requirements engineering (GORE) techniques have been developed by the research community in an effort to combat some of the problems facing the requirements gathering and evolution process. These include (Lamsweerde, 2001):

Completeness, Correctness and Pertinence of requirements. Issues with communication of requirements to stakeholders. Readability of complex requirements documents. Problems with mapping alternative requirements Effective requirements conflict management.

The premise of GORE is that traditional requirements elicitation methods such as stakeholder interviews, scenarios and use cases are used to develop a goal model which is then elaborated. The running example is taken from a software development project conducted by University College London for the charity National Children’s Homes (NCH) in 2006:

In cases where a child residing in the locality has been seriously abused, NCH The Bridge are responsible for undertaking a Case Review of the events leading the incident. The objective of this review is to analyse the causes of the incident and provide insight into how future incidents might be avoided.To assist with this review, all records concerning the case are collected from professional agencies that have dealt with the child. These agencies comprise of the police, social workers, health services, schools and various others. Records are then collated into chronologically ordered documented called a Chronology.

6

In figures 1 and 2 two partial goal graphs for the project are shown. The key elements to be noted are as follows:

Goal: An objective the system under consideration must achieve. In Figure 1 these are the boxes that do not have agents assigned to them.

Agent: An actor to which assumptions or requirements are assigned. This actor is then responsible for ensuring that they are upheld.

Requirement: A leaf node in the goal graph assigned to The System. Consequently, the system to be built is responsible to upholding all requirements.

Assumption: A leaf node in the goal graph assigned to an agent other than The System.

Figure 1: NCH Project example - Partial Goal Graph

7

Figure 2: NCH Project example - Partial Goal Graph

See (Lamsweerde, 2001) for more details on goal-oriented requirements engineering.

2.2 Classification of Conflicts

In requirements engineering the terms conflict and inconsistency still lack precise definition and are often used interchangeably to describe differing concepts, ranging from conflicts between stakeholders (Easterbrook, 1994) to logical inconsistencies between artefacts specified in a requirements model (Lamsweerde et al., 1998). This subsection attempts to identify and classify the different forms of conflict that arise, using the NCH project example to clarify terms. The most prominent split in the literature lies in whether a technique deals with conflicts in a more logical manner, usually working formally and addressing behavioural requirements and goals, as opposed to taking a qualitative stance and dealing with quality requirements and goals. In figure 3 the work reviewed in section 3 are placed on the relevant sides of this split.

8

Figure 3: Logical and qualitative requirements conflict management.

Some crossover exists between the two, for example quality goals can be modelled in a behaviourally in KAOS and dealt with in the same way as behavioural goals. An instance of this in the NCH project might be the remodelling of the quality goal: “Agencies should not need an excessive extra amount of time using the system”, as: “Agencies should be able to input each event in under 20 minutes”.

Two examples will now follow to clarify the difference between the logical and qualitative stances, using the KAOS and WinWin techniques respectively.

KAOS Example:A KAOS (Lamsweerde et al., 1998) based analysis of the NCH example may flag a conflict between goal (1.12) in Figure 1 and goal (2.5) in Figure 2; A logical inconsistency occurs when both goals are realised since the confidentiality of unencrypted data sent over email cannot be guaranteed.

WinWin Example:In the WinWin model (Boehm et al., 1995) stakeholder’s win conditions are collected and inspected for conflicts, where a win condition is defined as the desired objective of an individual. Below is an example of two win conditions that might be found to conflict:

Win Condition X:

9

Owner: Agencies Condition: No excessive extra effort should result from the new system.

Win Condition Y: Owner: NCH Staff Condition: Anonymisation of data should be done by Agencies.

A typical WinWin analysis might reveal that the fulfilment of win condition Y implies extra effort for Agencies and thus comes into conflict with win condition X.

On the logical side, Lamsweerde provides us with a useful taxonomy that covers inconsistencies that might occur with requirements (Lamsweerde et al., 1998): Process Level Deviation: Occurs where

there is a violation of a process level rule. Example: The two agents assigned to the same requirement in Figure 4 constitutes a process level deviation since each requirement may only be assigned to one agent according to the process level rules.

Instance Level Deviation: Covers inconsistencies created in the requirements at run time. Example: NCH Staff fail to prompt agencies for their records (violation of requirement 1.8).

Terminology Clash: Arises when the same concept is referred to in different parts of the requirements model by different terms. Example: Chronology is referred to as a ‘Chronology’ in some places in the requirements model and referred to as a ‘Journal’ in other parts.

Designation Clash: Designation clashes occur when two distinct concepts are referred to by the same term. Example: The set of records received by a single agency might be incorrectly referred to as a ‘Chronology’, resulting in a designation clash with the use of the same term use correctly in the rest of the model.

Structure Clash: The same single real-world concept is given two differing structures. Example: A record might be described as [Time, Date, Source, Event Text] in some part of the model and as [Time, Source, Event Text] in another.

Conflict: A minimal set of requirements that contain a logical inconsistency. The KAOS example given above is an example of this.

Divergences and Obstacles: These are special cases of a conflict. A divergence is conflict that only occurs when boundary condition exists.

10

Figure 4: Process Level Deviation

An obstacle is similar to divergence condition, but concerned with a specific event that might lead to a requirement or goal becoming impossible to satisfy. See (Lamsweerde et al., 1998) for more details.

Boehm has attempted to classify qualitative conflicts by providing an exhaustive taxonomy of all types quality requirement and producing sets of these that could conflict with each other (Boehm and In, 1996a). ‘Dependability vs. Performance’ is an example of such a conflict.

Another distinction is to be made between model inconsistencies and real-world inconsistencies. An inconsistency, or conflict, found in the real world usually manifests itself in an inconsistency in the requirements model where it can be found and dealt with. Conversely, not all model inconsistencies correspond to real world inconsistencies. For example, a terminology clash may simply be a mistake made when creating the requirements model.

2.3 Conflict Management

This subsection introduces the conflict management framework that will be used to structure the literature survey in the section 3.

As with the usage of the terms conflict and inconsistency, there is no agreed upon framework or ontology for the requirements conflict management process. The Requirements Interaction Lifecycle (Robinson et al., 2003) is an example of a proposed framework for managing conflicts: Requirements Partitioning: Requirements are partitioned into

manageable subsets to ease identification of conflict. Interaction Identification: Conflicts are identified. Interaction Focus: Further analysis of the requirements model to aid

with resolution identification and selection. Resolution Generation: A set of resolutions to a conflict is identified. Resolution Selection: The most appropriate resolution for a conflict is

chosen. Requirements Update: A resolution is applied to the requirements

model it is transformed accordingly.

It should be noted, however, that this framework does not encompass all the actions available to the requirements engineer during the conflict management process, but instead focuses on the steps needed to fix a conflict. Other such actions include:

11

Deferral of a fix. This might be preferable if more information or different circumstances make a conflict easier to resolve at a later date.

A meta-fix, by which the rules behind the requirements model are themselves altered to remove conflicts.

Robinson’s Requirements Interaction Lifecycle, nonetheless, is useful framework for the conflict management process and will be used in the next section to structure the review of the conflict management literature.

12

3 Conflict Management in Requirements Engineering

This section reviews some relevant literature on conflict management, giving an impression of what has already been achieved by the requirements engineering community. Section 3.1 gives a brief introduction to the work reviewed in this section. A more detailed summary will then be given in sections 3.2 through 3.7, each of which describes how the work aids the requirements engineer at the corresponding stages of Robinson’s Requirements Interaction Lifecycle (Robinson et al., 2003). Finally, the limitations of the work reviewed are discussed in section 3.8.

3.1 Overview

Research into requirements conflict management, although still not fully developed, covers a wide range of conflict types and stages of the Requirements Interaction Lifecycle. The work introduced in this sub-section, and subsequently elaborated in those that follow, gives an impression of the scope covered by this research.

Two leading goal oriented requirements modelling frameworks, KAOS (Lamsweerde et al., 1998) and i* (Yu, 1997), have both included support for requirements conflict management and will be reviewed. The NFR (Mylopoulos et al., 1992) extension for i* and Egyed’s work on Requirements Conflicts and Cooperation (Egyed and Grunbacher, 2004) will also be considered, in which interactions with non-functional requirements are taken into account.

Fixing Inconsistencies in UML Models (Egyed, 2007) covers methods for repairing inconsistencies between artefacts in UML models as opposed to requirements models. It does, however, provide useful insight into techniques that could be applied to requirements engineering. The facilities available with Xlinkit (Nentwich et al., 2003), a tool used for detecting and resolving inconsistencies in data stored in XML format, also bear close relation to the needs of the requirements conflict management.

The literature on WinWin (Boehm et al., 1995), an approach designed to detect conflicts been stakeholder’s win conditions and negotiate compromises will be summarised alongside two extensions for the process, QARCC (Boehm and In, 1996a) and S-COST (Boehm and In, 1996b).

13

Robinson’s work on Conflict-Oriented Requirements Analysis (CORA) (Robinson, 1999) will be considered, which provides formulaic methods for removing conflicts from a requirements model by applying transformations. His work on Root Requirement Analysis (Robinson and Pawlowski, 1997) will also be detailed, in which techniques are detailed for deciding which conflicts to resolve first from a large set.

The work on Viewpoints (Finkelstein and Sommerville, 1996) will also be covered, which provides a meta-meta level framework for which developers can specify their own frameworks. The focus here is allow stakeholders to produce parallel specifications in which conflicting elements are permitted to co-exist, to be later resolved when combining specifications. Both Berzins’ work on Merging Changes to Software Specifications (Berzins, 1998) and Feather’s Combining Parallel Specifications (Feather, 1989) also attempt to address the problem of resolving conflicts when combining specifications or adding to them incrementally. MPARN (Multi-Criterion Preference Analysis for Systematic Requirements Negotiation) (In et al., 2002) will also be discussed, which assists the developer in choosing the best resolution for a conflict form a set of possible candidates.

3.2 Requirements Partitioning

“Given a document with a great many requirements, requirements partitioning seeks to focus interaction analysis on manageable requirement subsets” (Robinson et al., 2003).

The underlying frameworks in both KAOS (Lamsweerde et al., 1998) and i* (Yu, 1997) inherently provide a wide range of support for requirements partitioning. The goal models produced provide meaningful partitions; KAOS partitions using a parent-child relationship between goals using a tree-like structure, while i* bases its partitions on the actors to which goals are designated.

Both techniques also allow for a rich set of object-oriented data to be stored with the goals that can be used to partition the requirements in other ways. Notably, The NFR (Mylopoulos et al., 1992) framework for i* provides a means associating goals with their positive and negative effects on the non-functional requirements, which can be used as a powerful way of partitioning requirements according to those which are most likely to interact with each other.

14

The WinWin (Boehm et al., 1995) model, like i* and KAOS, allows for partitioning the win conditions according to their attributes. The QARCC (Boehm and In, 1996a) extension to WinWin is a good example of such a method, in which quality attributes taken from a predefined taxonomy are associated with the win conditions. This is then used later for conflict identification by flagging candidate conflicts between quality attributes that are likely to conflict.

Egyed’s work on Requirements Conflicts and Cooperation (Egyed and Grunbacher, 2004) assumes a method similar to QARCC for associating quality attributes to requirements. It is argued, however, that methods like QARCC flag many false conflicts and that an extra partitioning step is needed, whereby requirements are partitioned according to their traceability links. By doing this candidate conflicts are disregarded if their requirements are not linked by traceability, and thus many false conflicts are removed.

Fixing Inconsistencies in UML Models (Egyed, 2007) captures a developer’s interactions with an UML modelling IDE, currently applied to IBM Rational Rose™, and checks for inconsistencies in the model as changes are made in real-time. Partitioning takes place each time a rule is checked against a change made to the UML model, in which only those objects linked to that being altered are considered. Xlinkit (Nentwich et al., 2002) runs user-defined consistency rules as a batch on XML document sets. Partitioning takes place each time a rule is checked against an artefact by only considering those links associated with the artefact being checked. These two techniques could easily be re-applied or adapted to requirements modelling languages and might be able to provide a powerful tool for fixing inconsistencies in requirements models.

The work on Viewpoints (Finkelstein and Sommerville, 1996) provides a meta-meta level framework on which modelling languages can be defined. In consequence, it is left to the developer to design partitioning techniques. A toy example of this can be seen in (Easterbrook and Nuseibeh, 1995), where a partitioning takes place at the state-chart level. The result is the comparison of two state-charts that represent sub-sections of a telephony system.

Feather’s work on Combining Parallel Specifications (Feather, 1989) assumes that a specification will be developed in small steps incrementally, allowing each small step to be merged with the previous specification and checked for conflicts and inconsistencies. Feather also

15

suggests that isolated parts of a specification can be elaborated in parallel and later merged by combining each parallel branch step by step, checking for conflicts in each case. Partitioning implicitly takes place since only new additions to the specification in each step are checked against the rest. An application of this technique can be seen in Berzins’ Merging Changes to Software Specifications (Berzins, 1998), where elaborations to specifications expressed using logic are combined in much the same way. 3.3 Interaction Identification

“Given a set of requirements, requirements interaction identification seeks to determine requirements which are mutually incompatible in that they imply systemic failures in the resulting operational system”. (Robinson et al., 2003)

A formalisation exists for each KAOS inconsistency type, as described in section 2.2. This, coupled with the formalisation of the goal graph using temporal logic, allows for the detection of inconsistencies in a model using formal analytical methods. Three such techniques are described in (Lamsweerde et al., 1998) for detecting divergences. Model consistency rule checks could be used on any requirements specification built using KAOS to detect other inconsistencies such as process level deviations.

With the NFR (Mylopoulos et al., 1992) extension for i*, functional requirements will have been associated with their positive and negative effects on the non-functional requirements. It can then be determined which functional requirements interact using pre-defined support and detract links between the non-functional requirements, which denote positive and negative interactions. Non-functional requirements explicitly expressed in the goal model can also be analysed in this way to discover further interactions.

WinWin (Boehm et al., 1995) in its basic form does not provide any explicit support for conflict identification, instead it suggests that the developer analyses the win conditions and manually searches for conflicts amongst them, known as issues. The QARCC (Boehm and In, 1996a) extension for WinWin, automates the process by flagging candidate conflicts by providing an analysis similar to that of NFR; win conditions are associated with quality attributes and pre-defined interactions between these quality attributes are then used to flag win conditions that may conflict. For example, a possible conflict would be flagged between a win

16

condition attributed with ‘development affordability’, and another with ‘portability’.

In Egyed’s work on Fixing Inconsistencies in UML Models (Egyed, 2007) inconsistencies are identified by checking, in real-time, any changes made to a model against a hard-coded set of UML modelling consistency rules. Similarly, Xlinkit (Nentwich et al., 2002) checks XML documents against user-defined consistency rules in a batch process. As with the partitioning process, potential exists for re-applying Egyed’s methods to requirements modelling languages, or encoding requirements consistency rules into Xlinkit.

As with partitioning, Viewpoints (Easterbrook and Nuseibeh, 1995) does not explicitly specify a specific method for identifying conflicts. Instead, a strategy is proposed and it left up to the developer of a viewpoint-oriented model to design the specifics. The strategy is as follows; parallel views of a specification are produced corresponding to those of different agents, which may be incomplete and modelled using in different techniques. This is encouraged in order to allow each stakeholder freedom of expression without the constraints imposed by the need to build a complete model, or by the use of a specific modelling language. The developer of the viewpoint-oriented model must then construct a system for combining these specifications, which may involve conversion from one model to another. At this point that inconsistencies between views should be detected, although it is up to the developer how exactly this is done.

As mentioned in the partitioning subsection, Feather’s Combining Parallel Specifications (Feather, 1989) suggests that conflicts should be identified as small incremental changes are made to the specification, although no specific technique is given for doing this. Berzins’ Merging Changes to Software Specifications (Berzins, 1998) employs the same principles and provides algebraic techniques for identifying areas of specifications, described in Boolean logic, that may conflict when merged.

3.4 Interaction Focus

“Some requirements interactions depend on other requirements interactions. For example, the resolution of one conflict may introduce new conflicts into the requirements set; conversely, one resolution may remove multiple conflicts” (Robinson et al., 2003). Interaction focus seeks address this issue by the partitioning of a set of requirements conflicts in order to chose the most appropriate conflicts to resolve first.

17

The interaction focus problem is extremely pertinent, since choosing the right conflict to resolve first could lead to the removal of many others, which saves a developer time and effort. It is also a problem, however, that has received very little attention from the requirements engineering research community, which may have do with its complexity. It seems as though only one attempt exists in the literature to address it directly; Root Requirement Analysis (Robinson and Pawlowski, 1997), in which it is proposed that conflicts that contain requirements with the highest level contentiousness should be put forward for resolution first. Robinson defines contentiousness here as the percentage of conflicting interactions that a particular requirement has among all requirements.

Potential exists within the literature work on interaction focus; resolving conflicts involving goals closer to the root of the tree in KAOS goal graphs (Lamsweerde et al., 1998), for example, may be beneficial since conflicts involving goals lower down the graph are likely to be affected by the outcome of their resolution. This principle is similar to that proposed in Root Requirement Analysis since higher-level goals will be more likely to have a higher level of contentiousness.

Robinson suggests some research areas that may provide useful solutions to the interaction focus problem (Robinson et al., 2003):

A cost-value trade-off analysis of requirements may help to decide which conflicts to resolve first.

Negotiation literature may provide leads into solving the problem. For example, it is suggested that the easiest conflicts to should be resolved first so as to build trust among negotiating participants.

Conflicts that contain requirements that must be achieved exactly as stated, or requirements of high importance may also want to be considered for resolution first.

3.5 Resolution Identification

Given that requirements conflicts have been identified, resolution identification seeks to produce sets of resolutions, with each set offering alternative fixes to a particular conflict (Robinson et al., 2003).

KAOS describes several formal methods for identifying resolutions to conflicts within its models. Below follow some examples, refer to (Lamsweerde et al., 1998) for the full list of resolution identification methods.

18

Alternative goal refinement: Consider alternative refinements of the goal-graph at a level higher than that at which the conflict occurs that eliminates the conflict.

Avoid boundary conditions: If a boundary condition exists that prevents a goal from being satisfied in some cases, create a new goal stating that the boundary condition must be avoided.

Goal restoration: If a boundary condition cannot be avoided, the goal affected could be weakened or ignored when the boundary condition takes place, and thereafter restored.

Goal weakening: Weaken the conditions of a goal so that it still provides utility, but no longer results in conflict.

Robinson’s Work on Requirement Conflict Restructuring (Robinson, 1999) also provides model transformations for eliminating conflicts. Robinson also suggests these could be applied not only to eliminate conflicts, but also in an effort to transform the model into a state where subsequent resolution becomes easier to perform. The goal-oriented nature of i* (Yu, 1997) means that some of the techniques available for KAOS can be used, such as alternative goal refinement. KAOS, however, is more formally defined and therefore not all methods can be applied. Boundary conditions, for example, have not explicit form of representation in i*.

With WinWin (Boehm et al., 1995), a manual identification of resolutions is suggested, whereby a set of options is created for each conflict between win conditions. The QARCC extension for WinWin (Boehm and In, 1996a) aids with the identification of options by providing pre-defined textual option suggestions for each of the conflict types defined in its ontology. For example, suggested options for a conflict between ‘development affordability and portability’ include, among others, the following two pre-defined options: “relax constraints on schedule, performance, hardware and other attributes”, and “find and incorporate some relevant reusable software”. S-COST (Boehm and In, 1996b), an extension to QARCC, gives more concise textual option suggestions to resolve cost related conflicts. It does this by taking additional input on the cost and scheduling estimates for implementing win conditions and those for the project overall, and using these to improve the feedback given to the user.

Egyed’s work on Fixing Inconsistencies in UML Models (Egyed, 2007)and Nentwich’s Xlinkit (Nentwich et al., 2003) tool perform resolution identification in very similar ways and both benefit from the ability to produce a correct and complete set of fixes automatically. In Xlinkit there

19

are three classes of fix, known as repair actions; add, delete and change. While a set of these actions can be automatically generated, some of them may be partial and need further user input. For example, a change action may require an element to be given a new name value, which cannot be automatically ascertained, and the user is therefore required to input this value. The same process is true Egyed’s work.

The Viewpoints (Finkelstein and Sommerville, 1996) framework, being defined at the meta-meta level, does not provide any explicit form of resolution identification. A toy example of implementation can be seen, however, in (Easterbrook and Nuseibeh, 1995) where a set of predefined fix actions are provided for each consistency rule. This method is similar to that in Xlinkit and Egyed’s work.

3.6 Resolution Selection

“Resolution generation can present a great many ways to remove a requirements conflict. Resolution selection seeks to determine how one can select an appropriate resolution” (Robinson et al., 2003).

In most of the work reviewed in this document resolution selection it left up to requirements engineer. This includes the KAOS and i* frameworks, Viewpoints, Egyed’s Fixing Inconsistencies in UML models and Xlinkit. This may be because different resolution selection strategies are suited to different situations, thus it would be difficult to provide a definitive resolution selection technique. The techniques that do exist, however, can be applied to aid resolution selection in any of the work reviewed.

Resolution selection implies some form of prioritisation among either resolutions, or requirements. If requirements prioritisation is used, then a resolution is subsequently chosen that causes the least damage to requirements of higher priority. Thus resolution selection is almost synonymous with prioritisation, although a developer must always take care in weighting the costs of prioritisation against the benefits gained from a good choice of resolution.

A popular technique for requirements prioritisation is to perform cost-value analysis, as demonstrated in A Cost-Value Approach for Requirements Prioritisation (Karlsson and Ryan, 1997), in which the cost of implementation and the value gained when implemented are estimated for each requirement and then used for pair-wise comparison

20

between them. The case studies in this paper have shown this technique to be effective.

In WinWin, the budgeting and scheduling data from the S-COST (Boehm and In, 1996b) extension can be used as a driving factor for prioritisation of options. Another extension for WinWin, MPARN (In et al., 2002), uses preference analysis and multi-criterion decision making theory to aid users in selecting options. The basic premise is as follows:

I. The criteria on which options are to be judged are explored.II. Options are assessed according to these criteria.III. The relative weights of criteria are assessed.IV. A ranking order is given to the options using multi-criterion decision

making theory

If a decision cannot be automatically reached using MPARN, then the resulting option scores can be used to assist the stakeholders with their decisions.

3.7 Requirements Update

The details of the update that needs to be performed, such as a requirements model transformation, can be extracted directly from the resolution chosen. Therefore all that needs to be done at this stage is simply apply a given update.

In i* (Yu, 1997) and KAOS (Lamsweerde et al., 1998) updates are done manually. It seems that it would be relatively simple, however, to integrate automation of updates into a tool that supported conflict management. Updates in WinWin (Boehm et al., 1995) are perhaps the simplest in all the literature covered here; an option chosen as a resolution is simply renamed to a point of agreement. An update will need to be applied in Viewpoints (Finkelstein and Sommerville, 1996), but is left up the developer of the viewpoint oriented framework.

Both Xlinkit (Nentwich et al., 2002), and the tool described in Egyed’s Fixing Inconsistencies in UML Models (Egyed, 2007) provide automatic updates given a chosen resolution. These updates are simply transformations applied the UML model in the case of Egyed’s work, or the XML database in the case of Xlinkit. It seems that requirements model updates could also be automated just as easily, given that resolutions are fully described.

21

3.8 Limitations of Current Techniques

A range of conflict management techniques has been presented in this section, demonstrating a selection of the current state of the art. The work described, although extensive, still does not provide a complete conflict management solution to aid the requirements engineer at all stages of the project lifecycle.

A complete conflict management system would need to encompass all forms of conflict that may arise. These include:

Human oriented conflicts, such as those found with WinWin. Conflicts between quality goals, such as those found using QARCC. Logical conflicts between behavioural goals, such as those found with

KAOS. Logical inconsistencies in a model, such as those found with Egyed’s

Fixing Inconsistencies in UML models.

Effort has been made to provide support for multiple types of conflict, especially in KAOS where quality goals can be represented as behavioural goals. KAOS also supports techniques for managing both conflicts between behavioural goals and model inconsistencies. We are, however, still a long way from providing a solution that deals with all these types of conflict.

Support must also be provided for all stages of the requirements conflict lifecycle. This is another issue with most of the work described, particularly at the resolution selection stage. Figure 5 shows a breakdown of the work reviewed into these stages. Most complete in this respect are the Xlinkit and the tool presented in Egyed’s Fixing Inconsistencies in UML Models. Both provide automation at most stages of the lifecycle, with the exception of the resolution selection and interaction focus stages. These tools are not designed to deal with requirements issues, but could be adapted to provide an automated management solution for requirements model inconsistencies quite effectively.

Partitioning

Interaction

Identification

Interaction Focus

Resolution Identificat

ion

Resolution

Selection

Update

KAOS i* (with NFR) WinWin (with QAARC)

22

S-COST MPARN Egyed’s Conflicts and Corporations

Viewpoints Requirements Conflict Restructuring

Root Requirement Analysis

Feather’s Combining Parallel Specifications

Berzins’ Merging Changes to Software Specifications

Xlinkit Egyed’s Fixing Inconsistencies

Figure 5: Requirements conflict lifecycle as addressed in the literature

Some of these techniques, including WinWin, i* and KAOS are being put to practical use, yet widespread usage of conflict management tools is still lacking in industry. Packages such as EasyWinWin (Briggs and Gruenbacher, 2002) and KAOS/GRAIL (Darimont et al., 1997) are examples of tools that have been used in an industrial setting, but more still needs to be done in order to provide good usable solutions. This is especially the case for smaller companies; studies have shown that find it hard to adapt to new requirements solutions (Aranda et al., 2007) and need extra incentives if they are to use these tools.

Aspects of requirements conflict management exist that have been ignored for the most part in the literature, and should also be included in a complete requirements conflict management tool. These include: The facility to defer the resolution of conflict, whereby it is put off to a

later date when more information or different circumstances may make

23

the conflict easier to resolve. In some cases, particularly with human-negotiation oriented conflicts, the conflict may be no longer considered to be of importance at a later date. Little has been done to provide advice on when to do this or integrate this concept into a framework. The work on Viewpoints comes the closest to dealing with this issue; “Frameworks in which inconsistency is tolerated help by allowing resolution to be delayed” (Easterbrook and Nuseibeh, 1995).

When a resolution to a conflict is applied, it may introduce more conflicts or resolve others. Almost no work has been done to analyse or deal with this ‘ripple effect’. The work on Root Requirements Analysis (Robinson and Pawlowski, 1997) is an exception to this, as it aids the developer with the discovery of requirements that will be more likely to affect others. Tool integration of features advising as to how resolutions affect the requirements model in this way would be of great benefit to the requirements engineer, as picking the most appropriate resolutions would save much time and effort.

A system for tracking and tracing requirements conflicts similar to those available for bugs, such as Bugzilla, would also be of great benefit to the requirements engineer. For example, conflicts that have already been addressed may resurface and valuable information on how the conflict was previously dealt with could be easily gathered using such as system.

Finally, little work has been done to incorporate requirements conflict management into the computer supported collaborative setting. This would not only facilitate collaboration, but may also provide means to further assist with conflict management. For example, much could be gained from the extraction of data on how users are interacting with a conflict management system. The next section gives a review of some collaborative work relevant to conflict management in requirements engineering.

24

4 Collaborative Environments in Requirements Engineering

This section gives an overview of the collaborative tools, environments and techniques available the requirements engineer. An emphasis is placed on the collaborative work relevant to conflict management. Section 3.1 gives a brief introduction to the work reviewed in this section. A more detailed summary will then be given in sections 3.2 through 3.5, each of which gives details on how the work relates to each of the four categories of collaborative software engineering support as described by Whitehead (Whitehead, 2007). Finally, the limitations of the work reviewed are discussed in section 3.6.

4.1 Overview

Facilities for requirements conflict management in collaborative environments is scarce in both the industrial and the research setting. This section therefore introduces some general-purpose requirements management environments, alongside some recent publications that attempt to deal with conflict management issues directly. The work introduced in this sub-section is elaborated in those that follow.

There are many commercial tools that provide support for collaborative requirements engineering; Telelogic DOORSi, Rational RequisitePROii

and Borland CaliberRMiii are all examples of heavyweight desktop based support tools, while Gatherspaceiv, eRequirementsv and ART-SCENE (Maiden et al., 2006) provide web-based requirements management services.

The experimental RETH (Kaindl, 2004) tool will be reviewed, which provides additional functionalities such as requirements function point analysis. The Compendium (Shum et al., 2006) project will be discussed, which provides a tool for mapping group thought and decision. Xlinkit (Nentwich et al., 2002), and its integration into the Eclipsevi IDE will also be discussed.

Specific support for requirements conflict management, although very much in its early stages, does feature in some works. A tool has been developed for the WinWin approach called EasyWinWin (Briggs and i http://www.telelogic.com/doors/ii http://www-306.ibm.com/software/awdtools/reqpro/iii http://www.borland.com/us/products/caliber/index.htmliv http://www.gatherspace.com/v http://www.erequirements.com/vi http://www.eclipse.org/

25

Gruenbacher, 2002) that implements WinWin theory over a Group Support System (GSS). Another WinWin adaptation, WikiWinWin (Yang et al., 2008), has made steps towards integrating WinWin into a web-based wiki. The SOP (Decker et al., 2007) project uses a wiki to enable stakeholders to collaboratively elicit and maintain requirements on-line. The project is currently also in the process of integrating a model consistency checker. Robinson has developed a prototype, DealMaker (Robinson, 1999), that provides some computer aided collaborative support specifically aimed at requirements conflict management.

Finally, two tools, OZ (Ben-Shaul, 1994) and Augur (Froehlich and Dourish, 2004), specifically designed for process and awareness support respectively will also be mentioned.

4.2 Model-Based Support

Software engineering involves the creation of multiple artefacts. Each type of artefact has its own semantics ranging from free form natural language, to formal semantics. The creation of these artefacts is synonymous with the creation of models, and requires support within collaborative environments. (Whitehead, 2007)

This category is very relevant to requirements conflict management, as some form of modelling framework will need to be set up to describe and address conflicts. A common theme is to use established use-case based requirements elicitation and management models, consisting of support for use-cases, scenarios, actors and requirements objects. All the commercial tools covered do not deviate far from this model, presumably because it is the most widely accepted. Requirements traceability, whereby changes to requirements are traced over their lifetime, is recognised as an important feature by commercial tools and support is provided with their models. Instant documentation is also commonly supported; allowing users to generate self contained requirements documents from stored models.

Most of the commercial tools provide additional elements in their models to further aid the user. Gatherspace, for example, provides a facility to create and track issues, which works in much the same way that traditional bug-tracking systems work. Borland CaliberRM provides an additional business-oriented model that used to create use-cases, with

26Figure 6: CaliberRM Decision tree model

a view on making it easier for less technical stakeholders to express their needs. Figure 6 shows an example of this model, whereby a stakeholder can build a decision tree of events that are later translated into use-cases. The SOP (Decker et al., 2007) project follows the modelling structure used by most commercial packages, but instead provides it over a wiki where use-cases, actors, requirements and scenarios are represented as pages.

The RETH tool (Kaindl, 2004) makes heavy usage of object-orientation, and allows any artefact from use-cases to documents written in natural language to be represented as an object. Automatic generation of links between objects is make possible by introducing hyperlinks based on textual matches. The tool also includes requirements function point analysis and meta-model compliance checks. These features, along with the object-oriented structure may serve as useful mechanisms if a requirements conflict management system were to be built on top of RETH.

Whitehead points out that current tools are lacking the capture of decisions made when creating and modifying requirements models, or design rational (Whitehead, 2007). The Compendium (Shum et al., 2006)project, although not designed specifically for requirements, is a good example of a collaborative tool that address this problem. Figure 7 gives a graphical view of the model, which is based on issues, options and decisions.

Figure 7: Compendium meta-model

27

Robinson’s collaborative DealMaker prototype has its model centered around his Conflict Oriented Requirements Analysis architecture (Robinson, 1999). In contrast to the usual use-case structure, this model allows for a logical definition of requirements similar to that of the KAOS approach. This in turn allows for the detection of conflicts and possible resolutions, which are both modelled within the system as first class objects.

EasyWinWin (Briggs and Gruenbacher, 2002) and WikiWinWin (Yang et al., 2008) are two attempts to provide collaborative conflict management support using WinWin theory (Boehm et al., 1995) using a group support system (GSS) and a wiki respectively. The models used in these tools are therefore both taken directly from the WinWin model, as described in the previous section.

4.3 Process Support

Engineers working together to develop a large software project can benefit from having a predefined structure for the sequence of steps to be performed, the roles engineers must fulfil, and the artefacts that must be created. This predefined structure takes the form of a software process model, and serves to reduce the amount of coordination required to initiate a project. By having the typical sequence of steps, roles, and artefacts defined, engineers can more quickly to tackle the project at hand. (Whitehead, 2007)

Commercial tools clearly see the need for process support as a great deal is provided in the form of tutorials, walkthroughs, wizards, demos and templates. The Compendium (Shum et al., 2006) tool also has an active community supporting it, and provides a social community web-site and regular workshops that provide further process support in addition to standard techniques.

In contrast, the research tools and prototypes covered provide less process support. An exception to this is those designed in a wiki, WikiWinWin (Yang et al., 2008) and SOP (Decker et al., 2007), in which users have been allowed to collaboratively evolve their own process support within the wiki. An advantage of providing process support in this way is that it becomes flexible; changes can be made easily and then collaboratively approved. This contrasts strongly with traditional, more rigid process support systems that may hinder the evolution of process support over time. There does, however, exist a possibility for negative

28

outcome when using this approach; users may over-simplify a process resulting in a decrease in the value gained from its use.

Research has also been done into tools that exclusively provide process support (Osterweil, 1987) leading to the production of collaborative tools such as OZ (Ben-Shaul, 1994), that allow users to define software process support collaboratively.

4.4 Awareness Support

Awareness does not support a specific task, and instead aims to inform developers of the ongoing work of others. By increasing the awareness of the activities of other engineers, coordination activities can be performed sooner and conflicts can be potentially avoided (Whitehead, 2007).

Requirements engineering typically requires a high level of involvement from multiple stakeholders, and consequently user involvement has benefits for the quality of service and the products produced in RE (Emam et al., 1994). Awareness support tools are therefore particularly relevant to the requirements process as they promote involvement among developers and stakeholders. Awareness also provides project supervisors with a means to monitor the levels of user involvement, and therefore act accordingly if they are not satisfactory.

Awareness in software engineering is usually provided via version control systems (Whitehead, 2007), and this approach is adopted by the commercial requirements tools covered here. This may not be appropriate in some instances of the requirements process as stakeholders typically are not familiar with their usage. Web-based platforms such as Gatherspace and eRequirements have an advantage here since desktop software does not need to be installed, and stakeholders can view and interact with the requirements process without needing to install any software.

The ART-SCENE (Maiden et al., 2006) project provides a web-based interface accessible from PDA’s, for which studies have shown an improvement in the discovery and documentation of requirements. RequisitePRO provides a web interface into its desktop-based system, further promoting awareness.

The requirements tools and prototypes arising from research provide little by the way of awareness with the exception of WikiWinWin (Yang et al., 2008) and SOP (Decker et al., 2007). The wiki platforms used by these

29

tools allow stakeholders and developers to easily access the current status of the project and view the work of others.

The Augur (Froehlich and Dourish, 2004) tool takes input from version control system usage and visualises it specifically for awareness support. Augur is designed, however, for developers’ usage while writing and submitting code. A similar tool may be of use to the requirements process to provide visualised awareness of the requirements process for both developers and stakeholders.

4.5 Collaboration Infrastructure Support

Collaboration infrastructure support aims to improve interoperability among collaboration tools, and focuses primarily on their data and control integration (Whitehead, 2007).

The commercial heavyweight desktop tools covered, DOORS, RequisitePRO and CaliberRM, all advertise integration with other computer aided software engineering tools in their own product lines. Telelogic DOORS also offers integration with HP QualityCenter, a product that tests for overlooked defects, change requests and requirements. In contrast, the web-based commercial tools provide less in the way of integration, although Gatherspace offers a full XML export of its data that could be used for manual integration into other systems.

The tools and prototypes from the research community covered here provide little integration. This may be, understandably, because their main purpose is to demonstrate a method or technique, rather than provide full user support. An exception to this is Xlinkit (Nentwich et al., 2002) that plugs in to Eclipse, an IDE that provides a good deal of collaboration infrastructure. For example, a version control plug-in for Eclipse such as SVN could be seamlessly used on an Xlinkit project, or, Xlinkit could automatically scan XML output from other eclipse projects. This is particularly relevant to requirements conflict management since the possibilities to adapting a system such as Xlinkit, as described in section 3, mean the advantages of integration with the Eclipse IDE would also be made available.

RETH (Kaindl, 2004) also provides some basic integration by allowing any file to be included in its system as an object and subsequently scanned for links to other artefacts as described in section 4.2.

30

4.6 Limitations of Current Techniques

A range of collaborative requirements engineering tools has been presented in this section, demonstrating a selection of what is currently available to the requirements engineer. It seems as though there are no commercial collaborative requirements conflict management tools available, and that those arising from research are still in the first stages of development.

Models in commercial collaborative tools focus on use-case based models, and support is missing for newer requirements models such the goal-oriented techniques KAOS (Lamsweerde et al., 1998) and i* (Yu, 1997). The Objectiver tool, evolved from KAOS/GRAIL (Darimont et al., 1997), is an attempt to provide the industry with support for goal-oriented requirements engineering but has not been adopted for wide-spread usage.

Awareness, process, and integration have a fair level of support in commercial collaborative environments but are almost non-existent in those coming from research that provide some form of conflict management. Some of the work reviewed, however, has attempted to include these features and the means employed could be taken as an example for future research projects. These include the integration support provided by Xlinkit (Nentwich et al., 2003) and the collaborative process support provided by SOP (Decker et al., 2007),

The lack of usage and support for collaborative tools that provide alternatives to traditional use-case based models means that very little by way of requirements conflict management support is available in the industrial setting. Progress is being made, however, in collaborative the requirements conflict management tools emerging from research. Furthermore, attempts are also being made within these tools to address some of the collaborative issues laid out by Whitehead (Whitehead, 2007). This includes the design rational support provided by Compendium (Shum et al., 2006) and the use of PDAs as novel technologies in ART-SCENE (Maiden et al., 2006).

Whitehead also states that broader participation is an area for research to focus on. Tools like EasyWinWin (Briggs and Gruenbacher, 2002) and DealMaker (Robinson, 1999) take advantage of the collaborative environment to raise user participation levels and coordinate multiple users at different locations. WikiWinWin (Yang et al., 2008) and the SOP project (Decker et al., 2007) use wiki technology and the philosophy

31

behind it to further improve participation levels. There is little done, however, to use the features of a collaborative environment to directly address the conflict management problem. It seem as though the only mention of this method comes from Decker in reference to the SOP project:

“Frequent changes to pages, so-called edit wars, are an indicator of conflicts. An old-pages overview can also indicate conflicts: pages not edited for a long time might indicate stakeholders silently withdrawing from the project to avoid conflicts. Information on stakeholders withdrawing from a project is also available in activity overviews for stakeholders (Decker et al., 2007).”

Techniques for using the features of a collaborative environment to provide solutions to the requirements conflict management problem may be of much use to the requirements engineer. This forms the basis of the proposed contribution described in the next section.

32

5 Proposed Contribution

In this section a PhD thesis contribution is proposed that follows from the critical review of the relevant work in the previous two sections.

Conflicts among requirements are commonplace and need to be managed carefully if a software project is going to stand a good chance of succeeding. Section 3 reviewed the relevant conflict management literature and it was argued that more still needs to be done in order to provide the requirements engineer with a complete conflict management solution. This is especially true at the resolution selection stage.

Section 4 surveyed the work on collaborative environments, and it was shown that a relatively small amount of work has been done to support requirements conflict management. Furthermore, it seems that the work done simply implements existing techniques in a collaborative setting, and almost no work has been done to use the features of a collaborative environment to directly address the problem. Awareness support is an example of such a feature, which could be used to provide the requirements engineer with awareness of the following:

Overall user interaction and participation levels. User participation in relation to particular artefacts. The status of a model, such as partially completed areas or missing

links. Frequently altered artefacts. Abstracted data on discussions held in a collaborative environment.

It is proposed that novel techniques are developed using the features of a collaborative environment to assist the requirements engineer with resolution selection, assuming that resolution generation has already taken place using any of the methods described in sections 3.2 though 3.5.

33

6 Approach

In this section a research approach is detailed for the development and validation of the contribution proposed in the previous section.

6.1 Scope

The contribution will focus on techniques to aid with the resolution selection stage of the requirements interaction lifecycle. It will therefore be assumed that the requirements partitioning, interaction identification, interaction focus and resolution generation stages have all taken place. As a result a set of resolutions to a particular conflict will have already been generated and the task remaining will be to choose from among them.

Techniques developed will make use of the collaborative setting, and therefore ‘offline’ use will be out of scope. It should be the case, however, that the techniques are transferable across a generic set of collaborative environments in order to be of use in as wide a range of applications as is possible.

Integration of the contribution into a tool, or with other methods will also be out of the core scope. It will be necessary, however, to demonstrate the validity of methods and it is therefore proposed that a prototype be developed with the new resolution selection methods fully integrated. Details of this tool and how it will be used are given in section 6.3.

6.2 Proposed Research

A study has been undertaken directed at requirements conflicts in the OpenOfficevii project – an open source project managed in a collaborative environment with a highly distributed development team. An analysis of the resolution selection strategies available to the requirements engineer has also been conductedviii, which has looked into which types of resolutions and strategies provide the most benefit.

Sample projects and case studies are available in the WikiWinWin (Yang et al., 2008) and the SOP project (Decker et al., 2007) websites, both of which contain a facility for requirements conflict management. An analysis of these projects is likely to provide further insight into how a collaborative setting can be used to perform resolution selection.

vii http://www.openoffice.org/viii http://camilofitzgerald.wordpress.com/

34

These studies will be used in combination with an in-depth problem analysis, supervisory sessions and conversations with other members of the research community to surface novel resolution selection techniques. The preliminary results of the validation process will serve to fine tune techniques developed at this stage.

Further reading into both new and seminal literature will take place in parallel. This will include conflict management and collaboration theory from other fields, such as artificial intelligence and psychology.

6.3 Validation of Research

It is proposed that a prototype should be developed that will implement GORE in web based collaborative environment for validation purposes. Specifically, a wiki will be constructed that allows users to collaboratively manage requirements using the KAOS method. The resulting tool will be similar to that developed in the SOP project (Decker et al., 2007). Pages will represent artefacts, to be developed collaboratively by both stakeholders and developers. Pages will also be available for discussions and overviews.

The tool will implement the conflict and resolution identification support detailed for KAOS (Lamsweerde et al., 1998), resulting in the generation of a set of possible fixes for a particular conflict. At this stage the novel resolution selection techniques will be used to assist users of the prototype with the selection of a resolution from the set.

Validation will primarily take place via an analysis of case studies recreated on the prototype, such as the NCH project outlined in section 2. A qualitative approach will be used here since it is our opinion that a critical, in-depth and honest analysis of the techniques developed will of greater significance than an empirical validation.

An empirical validation, however, will also be provided by offering the usage of the requirements management tool to those working on projects at University College London. The focus here will be on real projects, although student projects may be used as a secondary source.

Evidence showing the degree to which new techniques perform in other collaborative environments will need to be shown. Case studies will again be recreated, using the novel techniques to assist with resolution selection in a range of other collaborative tools and techniques, such as DealMaker (Robinson, 1999) and WikiWinWin (Yang et al., 2008).

35

6.4 Timetable

Figure 8 shows a timescale for carrying out the activities described in this section.

Figure 8: Timetable

* The write up of the thesis will take place iteratively throughout the duration of the degree**Student projects may be available as an external resource for the fine-tuning of the prototype.

36

References

37