Task descriptions versus use cases

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.