  Context: It is an enigma that agile projects can succeed 'without
requirements' when weak requirements engineering is a known cause for project
failures. While agile development projects often manage well without extensive
requirements test cases are commonly viewed as requirements and detailed
requirements are documented as test cases. Objective: We have investigated this
agile practice of using test cases as requirements to understand how test cases
can support the main requirements activities, and how this practice varies.
Method: We performed an iterative case study at three companies and collected
data through 14 interviews and two focus groups. Results: The use of test cases
as requirements poses both benefits and challenges when eliciting, validating,
verifying, and managing requirements, and when used as a documented agreement.
We have identified five variants of the test-cases-as-requirements practice,
namely de facto, behaviour-driven, story-test driven, stand-alone strict and
stand-alone manual for which the application of the practice varies concerning
the time frame of requirements documentation, the requirements format, the
extent to which the test cases are a machine executable specification and the
use of tools which provide specific support for the practice of using test
cases as requirements. Conclusions: The findings provide empirical insight into
how agile development projects manage and communicate requirements. The
identified variants of the practice of using test cases as requirements can be
used to perform in-depth investigations into agile requirements engineering.
Practitioners can use the provided recommendations as a guide in designing and
improving their agile requirements practices based on project characteristics
such as number of stakeholders and rate of change.
