Task descriptions versus use cases.

Saved in:
Bibliographic Details
Title: Task descriptions versus use cases.
Authors: Lauesen, Soren1 slauesen@itu.dk, Kuhail, Mohammad1 moak@itu.dk
Source: Requirements Engineering. Mar2012, Vol. 17 Issue 1, p3-18. 16p. 7 Charts.
Subjects: Use cases (Systems engineering), Requirements engineering, Technical specifications, Task analysis, Task assessment, Task performance
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. [ABSTRACT FROM AUTHOR]
Copyright of Requirements Engineering is the property of Springer Nature and its content may not be copied or emailed to multiple sites without the copyright holder's express written permission. Additionally, content may not be used with any artificial intelligence tools or machine learning technologies. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)
Database: Engineering Source
Description
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. [ABSTRACT FROM AUTHOR]
ISSN:09473602
DOI:10.1007/s00766-011-0140-1