Advertisement

Empirical Software Engineering

, Volume 5, Issue 3, pp 215–228 | Cite as

Picking the Right Problem Frame—An Empirical Study

  • Keith Phalp
  • Karl Cox
Article

Abstract

Problemframes are a relatively new approach to requirements engineering,promising benefits not only in elicitation but also in subsequentdesign, by allowing their users to select methods and techniquesappropriate to their given problem domain. In order to be effectivethis approach relies upon the correct identification of relevantproblem frames for a given problem or scenario. Hence, we examinewhether people are able to identify the correct (relevant) framesfor a given set of problem descriptions, and whether they cancorrectly gauge the relative contribution of each identifiedframe to the given problem. We note the Euclidean distance of(individual and group) answers from an expert solution, consideringeach problem frame as a separate dimension. Examination of thisdistance (or magnitude of error) allows us to gauge the accuracywith which people can assign problem frames. We compare the performanceof individuals within groups, and the performance where groupswork together to provide a collective solution, comparing bothof these with a fair-distribution strategy. We found that peoplecan choose the relevant frames with a reasonable degree of accuracy,but that this is improved where they work to provide a collectivesolution. We also note differences among groups, for example,that experience appears to improve the accuracy with which groupscan collectively choose relevant frames.

requirements problem frame problem domain 

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. Boehm, B. 1981. Software Engineering Economics. Prentice Hall.Google Scholar
  2. Booch, G., Rumbaugh, J. and Jacobson, I. 1999. The Unified Modeling Language User Guide. Addison Wesley.Google Scholar
  3. Bray, I. K. 2000. Introduction to Requirements Engineering. In draft form.Google Scholar
  4. Budgen, D. 1994. Software Design. Addison-Wesley.Google Scholar
  5. Coad, P. and Yourdon, E. 1991. Object Oriented Analysis. Prentice Hall.Google Scholar
  6. Connolly, T., Begg, C. and Strachan, A. 1999. Database Systems: A Practical Approach to Design, Implementation and Management—Second Edition. Addison-Wesley.Google Scholar
  7. Cox, K. and Phalp, K. 1999. Semantic and Structural Difficulties with the Unified Modeling Language Use-Case Notation version 1.3, OOPSLA workshop on Rigorous Modeling and Analysis of the UML: Challenges and Limitations. Denver, Colorado, USA, 2 November 1999.Google Scholar
  8. CREWS. 2000. Co-operative Requirements Engineering with Scenarios. Homepage at: http://sunsite.informatik.rwth-aachen.de/CREWS/Google Scholar
  9. Glass, R. 1998. Software Runaways. Prentice Hall.Google Scholar
  10. Jacobson, I. 1994. Basic use-case modelling (continued). Report on Object Analysis and Design, volume 1.Google Scholar
  11. Jackson, M. A. 1995. Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices. Addison-Wesley.Google Scholar
  12. Jackson, M. A. 1999. Re: Predicate logic. Personal communication.Google Scholar
  13. Kovitz, B. L. 1995. Practical Software Requirements: A Manual of Content and Style. Manning.Google Scholar
  14. Mair, C. and Shepperd, M. 1999. An investigation of rule induction based prediction systems. ICSE '99 Workshop on Empirical Studies of Software Development and Evolution. Los Angeles, USA, 18 May 1999.Google Scholar
  15. Rolland, C., Souveyet, C. and Ben Achour, C. 1998. Guiding goal modelling using scenarios. IEEE Transactions on Software Engineering: Special Issue on Scenario Management 24(12).Google Scholar
  16. Weidenhaupt, K., Pohl, K., Jarke, M. and Haumer, P. 1998. Scenarios in system development: Current practice. IEEE Software March/April: 34-45.Google Scholar
  17. Yourdon, E. 1989. Modern Structured Analysis. Prentice Hall.Google Scholar

Copyright information

© Kluwer Academic Publishers 2000

Authors and Affiliations

  • Keith Phalp
    • 1
  • Karl Cox
    • 1
  1. 1.Empirical Software Engineering Research Group, School of Design, Engineering & ComputingBournemouth UniversityDorsetUK

Personalised recommendations