1 / 13

Camilo Fitzgerald PhD Student UCL Computer Science

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.

mort
Download Presentation

Camilo Fitzgerald PhD Student UCL Computer Science

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  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. • …

  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:

  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…

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

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

  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?

  10. 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!

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

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

More Related