A popular and valuable technique within Agile development teams is to create a “story card“, to capture requirements. Although initially created for iteration and release planning purposes, you can sometimes get away with using the story card as the requirement spec, as it may provide “just enough” details.

These story cards, which are typically captured on one piece of paper (a small one at that) and stuck on a wall (the planning board) with many other story cards, tend to provide a text-based description of who wants to do what and why, along with perhaps a GUI mockup and some test scenarios. This technique works well for very small requirements, but it may not scale well for larger or more complex requirements and software projects, in my experience.

I recently posted a small article discussing some of the approaches to consider when defining requirements within Agile teams over on SearchSoftwareQuality.com that you may find of interest. Read it here.