Resolving Conflicts in Requirements Engineering A Ph D

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

Overview • • • A Simple Example Scope of the Project Existing Work Problem Exploration Next Steps Summary

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

Scope of the Project • In Perspective: – – • Poor requirements management is the #1 reason for IT project failures 1. 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.

Existing Work Key Related Works Explored So Far: • • • Viewpoints Theory 2 KAOS - Goal Oriented Requirements Engineering 3 XLink. It - Repair Actions Paper 4 Win – Non-Functional Requirements negotiation 5 Egyed’s work on UML model inconsistencies 6 Features of these works:

Existing 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…

Problem Exploration: Case Study • Open. Office Project: – – • A qualitative analysis of requirement conflicts found in Open. Office. 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: http: //www. cs. ucl. ac. uk/staff/C. Fitzgerald

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: http: //www. cs. ucl. ac. uk/staff/C. Fitzgerald

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?

Next Steps • Looking into: – – • 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!

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: http: //www. cs. ucl. ac. uk/staff/C. Fitzgerald/

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. 25 th International Conference on Software Engineering 5 Boehm, B. , P. Bose, et al. (1995). Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach. 17 th International Conference on Software Engineering. 6 Egyed, A. (2007). Fixing Inconsistencies in UML Design Models. 29 th 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

Contact Information Camilo Fitzgerald University College London Dept. of Computer Science, MPEB London WC 1 E 6 BT Office: 7. 08 Tel: +44 (0)20 7679 3699 (Direct Dial) Fax: +44 (0)20 7387 1397 Email: C. Fitzgerald (at) cs. ucl. ac. uk Web: http: //www. cs. ucl. ac. uk/staff/C. Fitzgerald/ Supervisors: Emmanuel Letier & Anthony Finkelstein