Goal: Learn why to describe requirements in the form of a test design.
A past ideal of development was a staged one, where each phase would finish before the next started. Just like a waterfall, with water flowing from one level to the other. From requirements gathering to analyses, to design, coding, testing, and finally, operation and maintenance, each phase would have its deadlines, and documented deliverables handed off to the next phase. One of the major drawbacks of this system is its responsiveness to changing insights, resulting in changing requirements. Another is the significant overhead of documents produced. In the recent decade or two, agile methodologies have become a general practice for tackling these drawbacks.
Introducing a test design, an extra document, to your development practice is maybe not what you have been waiting for...
