The common wisdom is that Agile register requirements using the user stories format: “”As a , I want <goal/desire> so that “. In this article, Earl Beede explains why user stories are not requirements.
Agile doesn’t use the traditional requirements techniques because it tries to avoid doing work that will be wasted as users might change their needs during the evolution of the project. Earl Beede reminds that requirements come in two parts: functional and non-functional. Most requirements focuses on the functional part and the article says that the user story is “a reasonably good approximation-some may argue a substitution-for the functional part of a requirement.” But they are incomplete as the non-functional parts of a requirement are harder than functional parts to capture and define. Agile does however use the acceptance criteria to define the non-functional part before developing a user story. Thus Agile has a way to capture complete requirements with association of the two items: the user story and acceptance criteria.
Read the full article on http://www.construx.com/Practicing_Earl/User_Stories_Ain_t_Requirements/
