2 Overview A Simple Example Scope of the Project Existing Work Problem ExplorationNext StepsSummaryRemember: 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 Theory2KAOS - Goal Oriented Requirements Engineering3XLinkIt - Repair Actions Paper4WinWin – Non-Functional Requirements negotiation5Egyed’s work on UML model inconsistencies6Features 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 ProjectsMSc 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 Engineering5 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 InformationCamilo FitzgeraldUniversity College LondonDept. of Computer Science, MPEBLondon WC1E 6BTOffice: 7.08Tel: +44 (0) (Direct Dial)Fax: +44 (0)C.Fitzgerald (at) cs.ucl.ac.ukWeb:Supervisors: Emmanuel Letier & Anthony FinkelsteinIntroduce yourself, where you come from, what you are doing and how far into the project you are. Tell them what this presentation is.