220 likes | 387 Views
Resolving Conflicts in Requirements Engineering: A PhD Project. Camilo Fitzgerald PhD Student UCL Computer Science. 8 th January, 2008. Overview. A Simple Example Scope of the Project Existing Work Problem Exploration Next Steps Summary. A Simple Example.
E N D
Resolving Conflicts in Requirements Engineering: A PhD Project Camilo Fitzgerald PhD Student UCL Computer Science 8th January, 2008
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 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. • …
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.
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:
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…
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: 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. 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
Contact Information University College London Dept. of Computer Science, MPEB London WC1E 6BT 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 Camilo Fitzgerald