Analysis of Requirements Conflicts in the Open Office ‘Calc’ Project Analysis

This document attempts to describe and analyse 8 examples of requirements conflicts found in the open source project ‘Calc’. This project is the OpenOffice project responsible for production, maintenance and updating of the spreadsheet application. The project can be found at http://sc.openoffice.org/

The following information is given for each of the 8 conflicts:- Issue # - The unique id assigned to the issue by the Issue Tracker- Description – A short description of the conflict and the classification is has been given

in the Issue Tracker.- Model – A visual model of the conflict. It is important to note that these were inferred,

and thus should not be considered as an original data source.- History - A fine grain typology of the conversations and actions relating to the conflict.- Points of interest: Observations relating to the conflict.

Then follows a table of classifications, in which the characteristics of the conflicts found are listed for comparative purposes. Lastly, there is a section on final observations.

This study compliments the start of a PhD research project on conflict detection/resolution strategies in software requirements engineering. The perspective taken during analysis will reflect this.

The examples were found by using their “Issue Tracker”: A tracking mechanism available through the project’s website that allows developers to raise issues, and keeps a record of how each issue is subsequently handled. Requirements conflicts were found by trawling through the issue lists searching for examples. Filters were also used to try and narrow down the search using the words: ‘Conflict’, ‘Usability’ and ‘Requirement’; as such, it is important to note that the data sample cannot be described as random. The source for each issue can be found by inputting its corresponding issue # at http://sc.openoffice.org/servlets/ProjectIssues

Issue #11343

Description:

A requirement has been added to make “Full Debug” mode the default mode for debuggers. A user objects to this because he claims that the drains on disk space and RAM needed to debug now are unacceptable.

Status: CLOSED Resolution: WONTFIX Type: DEFECT Priority: P1 (as of 09/10/2007)

Model:

History:

- Actor A (lead developer): 10/02/2003 – Issue raised, suggestion made to remove requirement Achieve [Use full debug mode as default for debugging].

- Actor B (lead developer): 10/02/2004 – Actor B that it is not possible to remove this requirement because of the new higher level goals that it relates to, which have to be satisfied in his view.

- Actor C (developer): 10/02/2004 – Agrees with Actor A’s viewpoint. Suggests a compromise by weakening the requirement “Achieve [Use full debug mode as default for debugging]” to full debug mode default in only some cases rather than all cases.

Achieve [Use full debug mode as default for

debugging]

Achieve [More efficient debugging]

Achieve [Any developer can debug the program with their home

machine]

Achieve [RAM needed below 2GB]

Achieve [More meaningful crash dumps]

Achieve [Disk space needed below 4GB]

- Actor D (lead developer): 10/02/2004 – Agrees with Actor A’s viewpoint. Suggests a substitution for the requirement “Achieve [Use full debug mode as default for debugging]” whereby another method is used to achieve its parent goal.

- Actor E (lead developer): 12/02/2004 – Agrees with Actor A’s viewpoint, and also suggests a substitution for the requirement “Achieve [Use full debug mode as default for debugging]” whereby another method is used to achieve its parent goal. He then goes on to say he and his development team will not be adhering to this requirement.

- Actor F (lead developer): 13/02/2004 – Enforces that the goal “Achieve [More meaningful crash dumps]” needs to be addressed. Try’s to encourage discussion around compromises and possible weakening of the requirement: “Achieve [Use full debug mode as default for debugging]”.

- Actor B (lead developer): 05/03/2004 – States that the requirement “Achieve [Use full debug mode as default for debugging]”will be eliminated.

Points of interest:

- Example of how it can be especially hard to find a resolution if two or more “master” viewpoints conflict (in this case a heated discussion amongst lead developers).

- What was stated as a vital goal to fulfil by Actor B is later disregarded (or so it seems from the data available in this issue).

- This raises a question about divergences in conflicts: Are “RAM needed below 2GB” and “Disk space needed below XGB” boundary conditions or requirements. Could any boundary condition simply be modelled as a requirement? For example:

a) “Achieve [Any developer can debug the program with their home machine] is a requirement” and “developer has less than 2GB RAM or XGB hard disk space free” is the boundary condition.

b) “RAM needed below 2GB” and “Disk space needed below XGB” are requirements in their own right.

Issue #39140

Description:

The new addition of a pop during an auto-save causes the application to be brought to the foreground. This causes undesired effects when another application is in use.

Status CLOSED Resolution FIXED Type DEFECT Priority P3 (as of 09/10/2007)

Model:

History:

- Actor A (project observer): 16/12/2004 – Issue raised as a ‘defect’.

- Actor B (developer): 17/12/2004 – Actor B states that the issue is not a defect since it results of the requirements for the current version. He then reassigns the issue to the requirements team to decide how to fix it in the next version.

- Actor C (requirements engineer): 16/08/2005 – States that the requirement “Achieve [Always inform user when saving under the filename ‘Untitled’]” has been eliminated and that the pop-up window resulting from the requirement no longer appears.

Achieve [Mimic Microsoft Office’s new features]

Avoid [The user is annoyed by an Open Office application]

Achieve [Include an auto-save feature]

Avoid [Open Office applications come into focus while the user is

using another application]

Achieve [Always inform user when saving under the filename ‘Untitled’]

Points of interest:

- It took 8 months to resolve the conflict because it the requirements did not change the requirement accordingly until the next version. A more flexible approach to requirements evolution could maybe have resolved this conflict earlier (especially since it seems that everyone was in agreement of the resolution). Emphasis the need for a flexible requirements management system.

- Same question as in the last issue: is “Avoid [Open Office applications come into focus while the user is using another application]” a boundary condition or a requirement in its own right?

Issue #40565

Description:

New features have been implemented, and the new shortcuts associated with them have left the toolbars unorganised and cluttered.

Status: CLOSED Resolution: FIXED Type: DEFECT Priority: P3 (as of 09/10/2007)

Model:

History:

- Actor A (developer): 13/01/2005 – Conflict raised.

- Actor B (lead developer): 18/01/2005 – Reassigns the conflict’s priority from P4 to P3 developer assigned to the task reassigns it to Actor C.

- Actor A (developer): 13/03/2005 – Conflict resolved by re-implementing the toolbar structures.

Achieve [Mimic Microsoft Office’s new features]

Achieve [Easy of use of the application]

Achieve [Include additional toolbars]

Avoid [Cluttered, poorly ordered menus]

Implementation of ‘Achieve [Include additional toolbars]’ leaves the menus cluttered and poorly ordered

Requirements/Goal Level

Design Level

Points of interest:

- Maybe worth investigating priority reassignment.

- More of a poor implementation than a real requirements conflict.

Issue #43249

Description:

Two different terms are used for the same concept within differing OpenOffice applications: In Writer & Calc “Measurement Unit” is used for a concept that is described as “Unit of Measurement” in Impress and Draw.

Status: STARTED Resolution: NA Type: DEFECT Priority: P3 (as of 09/10/2007)

Model:

Achieve [Include an OpenOffice-wide feature allowing the user to select the default unit of measure]

Achieve [Include a feature in the calc application to allow the user to select a unit of measure]

Implementation of ‘Achieve [Include a feature in the calc application to allow the user to select a unit of measure]’ uses the term “Measurement Unit”

Requirements/Goal Level

Design Level

Achieve [Consistency of terminology across all Open Office applications]

Achieve [Mimic Microsoft Office’s new features]

Achieve [Include a feature in the draw application to allow the user to select a unit of measure]

Implementation of ‘Achieve [Include a feature in the draw application to allow the user to select a unit of measure]’ uses the term “Unit of Measurement”

History:

- Actor A (developer): 21/02/2005 – Conflict raised.

- Actor B (developer): 21/02/2005 – Developer assigned to the task reassigns it to Actor C.

- Actor C (developer): 20/05/2005 – Actor C reassigns the task to Actor D.

- Actor D (developer): 20/05/2005 – Investigates the issue and discovers that “Unit of Measurement” and “Measurement Unit” are both incorrect. The correct term according to the dictionary is “Unit of Measure”.

- Actor A (Developer): 20/10/2005 – States that the conflict “goes deep into the code itself” and will take a while to fix.

- Actor E (Developer): 23/01/2206 – ‘Retargets’ the issue to the next development iteration.

Points of interest:

- The conflict was reassigned twice, and took 3 months to reach the person who would deal with it. Maybe more efficient conflict fixes could be achieved if this was done automatically. (Possibly out of the scope of my project).

- No fix in 2 years as of the time of writing (November 2007) even though the priority is set to P3, which is the same priority of conflicts discussed in this document that were fixed within weeks or months. This raises the question of what exactly lead to this conflict being ignored if it was not its priority level. A further study of this could reveal techniques for automatically identifying situations where we can simply “live with the inconsistency”.

Issue #73320

Description:

An error message appears saying “Error: Unable to paste” when a user purposefully cancels a paste.

Status: CLOSED Resolution: FIXED Type: DEFECT Priority: P3 (as of 09/10/2007)

Model:

History:

- Actor A (project observer): 10/01/2007 – Conflict raised.

- Actor B (developer): 10/01/2007 – Agrees with issue and goes a step further to say that he thinks that the goal: “Achieve [Include extra options when pasting text (including an option to cancel the paste operation)]” should be excluded all together because it affects usability.

- Actor C (lead developer): 10/01/2007 – Fixes original conflict by weakening of the goal: “Achieve [Always inform when an initiated paste is unsuccessful]” and reimplementation of code to fix this. He also points out that the extra conflict raised by Actor B already exists in issue #15509 and points him to this issue to express his views on the matter.

- Actor C (lead developer): 18/01/2007 – Reassigns the issue to a quality assurance team to check to see if it has been fixed properly.

- Actor D (QA team member): 09/02/2007 – Confirms that the fix was successful.

Points of interest:

Achieve [Mimic Microsoft Office’s features]

Avoid [The user is annoyed by an Open Office application]

Achieve [Include extra options when pasting text (including an option to cancel the paste operation)]

Avoid [Unnecessary pop-ups appear that annoy the

user]

Achieve [Always inform when an initiated paste is unsuccessful]

- The extra conflict raised by Actor B is another example of duplication. They failed to realise that this was not only a duplication of issue #15509, but also of #2540 (described below). Duplication of conflicts seems to occur often in this project. How many conflicts have been addressed multiple times because of a failure to recognise that it had been addressed before? It might be useful to find efficient/automated ways of finding duplications? (Possible ways of automated duplication detection are discussed further below in issue #2540).

- Interesting use of reassignment of responsibility for the conflict to a QA team in order to check that it had been fixed. Is this out of scope of conflict detection/resolution, or could this technique be included somehow in resolution methods to provide greater assurance that fixes are correct?

Issue #21196Description:

Legal statements not included in code borrowed from Mozilla.

Status: CLOSED Resolution: FIXED Type: DEFECT Priority: P2 (as of 09/10/2007)

Model:

History: - Actor A (developer): 14/10/2003 – Conflict raised.- Actor B (developer): 15/10/2003 – Points out that this relies on another conflict (issue

11424) where the use of Mozilla code is questioned. Issue 11424 raises a conflict between the use of Mozilla code, and the resulting efficiency problems.

- Actor A (developer): 25/10/2003 – Marks issue 21676 as a duplicate of this one.

- Actor C (lead developer): 21/11/2003 – Priority changed from P1 to P2 since this issue “does not make it impossible to work with this version”.

- Actor C (lead developer): 08/04/2004 – Conflict fixed by including Mozilla licences with the builds.

Achieve [Mimic Microsoft Office’s new features]

Avoid [Legal actions against Open Office]

Achieve [Include an ‘Address Book integration’ feature]

Achieve [All licence conditions of borrowed software are adhered to]

Implementation of ‘Achieve [Include an ‘Address Book integration’ feature]’ borrows code from Mozilla, which does not have the relevant legal documents attached to it.

Requirements/Goal Level

Design Level

Points of interest:

- Another example of duplicate conflicts. See issue 2540 for more on this.

- The conflict “relies” on another conflict (issue 11424), in that the outcome of the resolution for issue 11424 may have rendered this conflict irrelevant. The developers chose to wait until issue 11424 was resolved to see if they needed to worry about this conflict or not. When it was decided to keep the Mozilla code (as a fix to issue 11424) then this conflict was addressed. Could this “reliance” have been detected automatically? The only similarities between the two issues on first sight seem to in the natural language used to describe them. An efficient goal/requirement/conflict graphing mechanism would have caught the reliance.

- Given that the ‘reliance’ described above has been identified, how could it be detected that a particular outcome of issue 11424 would cause this conflict to disappear? One idea is to describe the use of Mozilla source code as an ‘entity’. This conflict would be dependent on the existence of this entity, and issue 11424 could have a possible resolution that would remove the existence of this entity.

- The use of Mozilla code was described as implementation decision in the inferred model above, however in another model it could have been described as a requirement. This raises the question of what exactly is a requirements conflict and what is an implementation conflict?

- The conflict’s priority was changed at one point. This was an example of a re-assessment of a conflict’s impact on the project, and thus the urgency of its resolution. Could there be something in the automatic prioritisation of conflicts? Maybe according to the number of inconsistencies they cause or the easy of resolution (via the size of the set of possible resolutions available, or otherwise).

Issue #2540

Description:

An options window appears when opening a new ASCII text file, affecting usability.

Status: CLOSED Resolution: INVALID Type: DEFECT Priority: P3 (as of 09/10/2007)

Model:

History:

- Actor A (project observer): 14/12/2001 – Conflict raised for the Windows 2000 platform.

- Actor A (project observer): 19/12/2001 – Conflict raised again under a different issue ID (#2589) for the Solaris platform.

- Actor B (lead developer): 27/02/2002 – Disagrees with Actor A’s separation of the conflict into two issues and marks the second issue as a duplicate of the first.

- Actor B (lead developer): 27/02/2002 – Disagrees with Actor A’s viewpoint, and does not believe that the conflict exists. The issue is marked as INVALID and is CLOSED.

Achieve [Mimic Microsoft Office’s features]

Avoid [The user is annoyed by an Open Office application]

Achieve [Include extra options when opening an ASCII text file]

Avoid [Unnecessary pop-ups appear that annoy the

user]

Points of interest:

- What is really one conflict here generates two different issues.

- How did Actor B spot the duplicate? Presumably by remembering that the conflict had already been raised when reading it for the second time.

- Might the duplication have been automatically found? Pointers towards the existence of the duplication were:

o Similar natural language text was used in describing both conflicts.

o The same user raised both conflicts.

o The two conflicts were raised 5 days apart.

o Similarities between the meta-data attached to both conflicts.

Issue #4348

Description:

The calc Open Office web site crashes when opened with a particular version of Opera Internet browser.

Status: CLOSED Resolution: WONTFIX Type: DEFECT Priority: P4 (as of 09/10/2007)

Model:

History:

- Actor A (project observer): 01/05/2002 – Raises issue and suggests a detailed fix.

- Actor B (lead developer): 05/05/2002 – Agrees with Actor A’s viewpoint and suggests that he becomes a developer and fixes the problem. Resolution set to WONTFIX as it is hoped that Actor A will resolve the conflict in his own time.

- Actor C (lead developer): 11/05/2003 – Issue closed due to inactivity.

Achieve [Compatibility of all aspects of Open Office across all platforms]

Achieve [Website conformance to HTML 3.2 spec] Achieve [Website compatibility with

all browsers]

Implementation of ‘Achieve [Website conformance to HTML 3.2 spec]’ causes the website to crash when viewed in Opera browser version 6.01.

Requirements/Goal Level

Design Level

Points of interest:

- The notion: “If a particular actor’s viewpoint creates a conflict, then they can provide the resolution to the conflict themselves”.

- Final resolution was to simply live with the inconsistency due to inactivity on the issue: suggesting that the issue could not have been that critical in the first place

Classifications:

Final Observations:

- It should be noted that the tendency of the conflicts found is to have an anchor in the design/coding/QA levels of the project. A theory for this phenomenon is that higher level conflicts and issues were probably discussed in more of an ad-hoc way since the team dealing with them was probably a lot smaller. Thus less data is available on higher level conflicts. This may be especially true because of the Open Source, and therefore agile, nature of this project. It may be worth trying to find another project to study that has will yield more requirements engineering level conflict examples.

- Many of the conflicts found were with “unwritten” requirements that were not previously documented. Maybe this is a result of the issues discussed in the previous point.

- Interesting examples of conflicts which were ignored or set to WONTFIX. Can anything be learnt from these as when to ignore a conflict and simply ‘live with the inconsistency’?

- Issue 21196 contains the concept of one conflict relying on the outcome of the resolution of another one. This is quite interesting and worth further consideration.

- Could anything be a requirements conflict? Could all of these examples be described as petty disagreements, or bugs, or poor implementations.

- These examples, in the main, demonstrate a bottom-up approach to conflict resolution (probably resulting from the issues discussed in the first point above).

- Issues 73320, 21196 and 2540 all have interesting information related to duplicated conflicts. Much time could have been saved in this project by automatic/early detection of duplicated conflicts.

- I have not yet analysed the information contained in the ‘classifications’ table. Maybe there could be some interesting observations resulting from it.

- Issue 4348 has the notion: “If a particular actor’s viewpoint creates a conflict, then they can provide the resolution to the conflict themselves”.

- There were some questions raised on exactly how to model conflicts. Especially in issue 11343 where the question of exactly what is a divergence is raised.