1. Camilo Fitzgerald PhD Student UCL Computer Science
Resolving Conflicts in Requirements Engineering: A PhD Project
Camilo Fitzgerald
PhD Student
UCL Computer Science
8th January, 2008

2. Overview A Simple Example Scope of the Project Existing Work
Problem Exploration
Next Steps
Summary
Remember: Tell them, Tell them, Tell them

3. A Simple Example Consider a ‘new mobile phone’ project:
Requirement A: Phone must provide GPS.
Requirement B: Phone must weigh less than 10g.
Domain Property: The lightest GPS device weighs 12g.
Possible resolutions include:
Elimination? Forget about the GPS (Requirement A).
Weakening? The phone may weigh 20g (Requirement B).
Live with Conflict? A GPS device could be available next week that weighs less. …
Can be hard to spot in a large RE document

4. Scope of the Project In Perspective:
Poor requirements management is the #1 reason for IT project failures1.
Management of conflicts plays a big part in this.
Conflicts between requirements are commonplace:
Only a handful of computer aided detection methods exist.
Almost no work done on automated resolution methods.
Conclusion:
We need better conflict detection/resolution methods and tools.
Ultimately, we need a ‘complete’ requirements conflict management tool that covers every stage of a projects lifecycle.

5. Existing Work Key Related Works Explored So Far:
Viewpoints Theory2
KAOS - Goal Oriented Requirements Engineering3
XLinkIt - Repair Actions Paper4
WinWin – Non-Functional Requirements negotiation5
Egyed’s work on UML model inconsistencies6
Features of these works:
Mention that it is a very new area. Little done in the way of detection and even less in the way of resolution

6. Existing Work Work I will be looking into next:
Goal modeling with i*7.
Conflicting merges in configuration management.
Models for collaborative elicitation.
The economic approach to conflicts.
I’m very interested in more suggestions…
Mention that it is a very new area. Little done in the way of detection and even less in the way of resolution

7. Problem Exploration: Case Study
OpenOffice Project:
A qualitative analysis of requirement conflicts found in OpenOffice.org’s spreadsheet application.
Modeling of conflicts, and their resolution strategies.
Main points of interest:
Resolutions were usually chosen based upon the level of authority of the actor that proposed them.
Conflicts were frequently raised more than once, after a resolution had been chosen.
Many examples where the resolution chosen was to ‘live with the conflict’.
Full analysis available on weblog:
More details available on the blog

8. Problem Exploration: Other Studies
UCL ‘Research Information Systems’ Project:
Project Aim: To keep complete and up-to-date data on all research projects at UCL.
Underlying Conflict: Time & effort of academic staff vs. accuracy of records.
A Study of Student Projects
MSc students formed groups of ‘Developers’ and ‘Clients’ to produce a requirements document collaboratively.
A Wiki will be used next year to produce the requirements document. Editing pages collaboratively could be a useful tool for recording and resolving conflicts.
More details on weblog:
More details available on the blog

9. Problem Exploration: Ideas
Possible criteria for choosing alternative resolution strategies:
Stakeholder satisfaction.
Stakeholder importance.
Pick a resolution that increases the probability of subsequent resolutions.
Project development stage.
Artefacts altered by a resolution.
Analyse resolutions in terms of other conflicts that may arise from them:
How can we handle dependencies between conflicts?
In what order should conflicts be resolved?
At what stage of the project should a conflict be resolved?
Most of these ideas are not your own!

10. Next Steps Looking into: Future Plans:
Characterisation of real world resolution strategies.
Dependencies between conflicts.
Future Plans:
Continue with the projects and related work.
Find methods for computer aided conflict detection and/or resolution.
Implement these methods in a simple tool that is of use to the software engineering community.
Produce a thesis!
Virtually no work done on first two points

11. Summary Conflicts exist and need to be managed effectively.
Lots of interesting work out there, but we are a long off from a complete conflict management solution.
I’m looking into characterisations of the way conflicts are detected and resolved.
By the end of three years, I aim to have a tool that will be useful to software engineers.
For more information:

12. References 1 Survey of US software project by Standish Group
2 Finkelstein, A. S., I. (1996). "The Viewpoints FAQ: Editorial - Viewpoints in Requirements Engineering." Software Engineering Journal.
3 Lamsweerde, A. v. and R. Darimont (1998 ). "Managing conflicts in goal-driven requirements engineering " IEEE Transactions on Software Engineering.
4 Nentwich, C., W. Emmerich, et al. (2003 ). Consistency Management with Repair Actions. 25th International Conference on Software Engineering
5 Boehm, B., P. Bose, et al. (1995). Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach. 17th International Conference on Software Engineering.
6 Egyed, A. (2007). Fixing Inconsistencies in UML Design Models. 29th International Conference on Software Engineering, ICSE.
7 Yu, E. S. K. (1997). Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. IEEE International Symposium on Requirements Engineering

13. Contact Information
Camilo Fitzgerald
University College London
Dept. of Computer Science, MPEB
London WC1E 6BT
Office: 7.08
Tel: +44 (0) (Direct Dial)
Fax: +44 (0)
C.Fitzgerald (at) cs.ucl.ac.uk
Web:
Supervisors: Emmanuel Letier & Anthony Finkelstein
Introduce yourself, where you come from, what you are doing and how far into the project you are. Tell them what this presentation is.