Skip to main content
Log in

Task descriptions versus use cases

  • REFSQ 2011
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

Use cases are widely used as a substantial part of requirements, also when little programming is expected (COTS-based systems, Commercial-Off-The-Shelf). Are use cases effective as requirements? To answer this question, we invited professionals and researchers to specify requirements for the same project: Acquire a new system to support a hotline. Among the 15 replies, eight used traditional use cases that specified a dialog between user and system. Seven used a related technique, task description, which specified the customer’s needs without specifying a dialog. It also allowed the analyst to specify problem requirements—problems to be handled by the new system. It turned out that the traditional use cases covered the customer’s needs poorly in areas where improvement was important but difficult. Use cases also restricted the solution space severely. Tasks did not have these problems and allowed an easy comparison of solutions.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6

Similar content being viewed by others

References

  1. Achour CB, Rolland C, Maiden NAM, Souveyet C (1999) Guiding use case authoring: results of an empirical study. In: Proceedings of the 4th IEEE international symposium

  2. Alexander I, Beus-Dukic L (2009) Discovering requirements. Wiley, New York

    Google Scholar 

  3. Armour F, Miller G (2001) Advanced use case modeling. Addison-Wesley, Reading

    Google Scholar 

  4. Checkland PB (1981) Systems thinking, systems practice. Wiley, Chichester

    Google Scholar 

  5. Cockburn A (1997, 2000) Writing effective use cases. Addison-Wesley

  6. Constantine LL, Lockwood LAD (1999) Software for use: a practical guide to the models and methods of usage-centered design. Addison-Wesley, New York

    Google Scholar 

  7. Cox K, Phalp K (2000) Replicating the CREWS use case authoring guidelines. Empir Softw Eng J 5(3):245–268

    Article  MATH  Google Scholar 

  8. IEEE Recommended Practice for Software Requirements Specification, ANSI/IEEE Std. 830 (1998)

  9. Jacobson I, Christerson M, Johnsson P, Övergaard G (1992) Object-oriented software engineering—a use case driven approach. Addison-Wesley, Reading

    MATH  Google Scholar 

  10. Jacobson I (2003) Use cases: yesterday, today, and tomorrow. IBM Technical Library

  11. Kulak D, Guiney E (2000) Use cases: requirements in context. Addison-Wesley, Reading

    Google Scholar 

  12. Lauesen S (2002) Software requirements—styles and techniques. Addison-Wesley, Reading

    Google Scholar 

  13. Lauesen S (2003) Task descriptions as functional requirements. IEEE Softw 20(2):58–65

    Article  Google Scholar 

  14. Lauesen S (2005) User interface design—a software engineering perspective. Addison-Wesley, Reading

    Google Scholar 

  15. Lauesen S (2011) Guide to requirements SL-07—Template with examples. ISBN: 978-87-992344-1-7, also on: http://www.itu.dk/people/slauesen/SorenReqs.html#SL-07

  16. Lauesen S, Kuhail MA (2009) The use case experiment and the replies, http://www.itu.dk/people/slauesen/

  17. Lauesen S, Kuhail M (2011) Use cases versus task descriptions. In: Berry D, Franch X (eds) REFSQ 2011, LNCS 6606. Springer, Berlin, pp 106–120

    Google Scholar 

  18. Lauesen S, Soren Lauesen’s website: http://www.itu.dk/people/slauesen/ Contains examples of requirements and user interfaces developed with tasks

  19. Lilly S (1999) Use case pitfalls: top 10 problems from real projects using use cases. IEEE Computer Society, Washington

    Google Scholar 

  20. Lim KY (1996) Structured task analysis: an instantiation of the MUSE method for usability engineering. Interact Comput 8(1):31–50

    Article  Google Scholar 

  21. Maiden NA, Ncube C (1998) Acquiring COTS software selection requirements. IEEE Softw 15(2):46–56

    Article  Google Scholar 

  22. Polson PG, Lewis CH (1990) Theory-based design for easily learned user interfaces. Hum Comput Interact 5:191–220

    Article  Google Scholar 

  23. Preece J, Rogers Y, Sharp H (2002) Interaction design—beyond human–computer interaction. Wiley, New York

    Google Scholar 

  24. Robertson S, Robertson J (1999) Mastering the requirements process. Addison-Wesley, Reading

    Google Scholar 

  25. Rogers EM (1962, 1983) Diffusion of innovations. Free Press, New York

  26. Rosenberg D, Scott K (2001) Top ten use case mistakes. Softw Dev. http://www.drdobbs.com/184414701

  27. Sigurðardóttir, Hrönn Kold (2010) Project manager for the electronic health record system at the Capital Hospital Association (H: S): draft of PhD thesis

  28. Wiegers KE (2003) Software requirements. Microsoft Press, US

    Google Scholar 

  29. Wirfs-Brock R (1993) Designing scenarios: making the case for a use case framework, Smalltalk report, Nov/Dec, also: http://www.wirfs-brock.com/PDFs/Designing%20Scenarios.pdf

  30. Yourdon E (1989) Modern structured analysis. Prentice Hall, New Jersey

    Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Soren Lauesen.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Lauesen, S., Kuhail, M.A. Task descriptions versus use cases. Requirements Eng 17, 3–18 (2012). https://doi.org/10.1007/s00766-011-0140-1

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-011-0140-1

Keywords

Navigation