A Multi-Case Study of Agile Requirements Engineering and the Use of Test Cases as Requirements

[Context] It is an enigma that agile projects can succeed ‘without requirements’ when weak requirementsengineering is a known cause for project failures. While agile development projects often manage well withoutextensive requirements test cases are commonly viewed as requirements and detailed requirements are documented astest cases.[Objective] We have investigated this agile practice of using test cases as requirements to understand how test casescan 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 2focus 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 ofthe test-cases-as-requirements practice, namely de facto, behaviour-driven, story-test driven, stand-alone strict andstand-alone manual for which the application of the practice varies concerning the time frame of requirementsdocumentation, the requirements format, the extent to which the test cases are a machine executable specification andthe 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 andcommunicate requirements. The identified variants of the practice of using test cases as requirements can be used toperform in-depth investigations into agile requirements engineering. Practitioners can use the providedrecommendations as a guide in designing and improving their agile requirements practices based on projectcharacteristics such as number of stakeholders and rate of change.EAS