How much detail and how close to a specification?

How much detail and how close to a specification?

User stories describe the behavior of the application.  Like user stories (and all other Agile mechanisms for identifying work), traditional requirements and use cases are means to the same end. Each technique is more or less granular and more or less like a specification.

A specification is a description of the intended purpose and environment for the software being developed or enhanced. The IEEE defines software requirements specifications in IEEE Std 830-1998.  The standard defines the characteristics of a good software requirement specification[1] (SRS) as:

  • Correct;
  • Unambiguous;
  • Complete;
  • Consistent;
  • Ranked for importance and/or stability;
  • Verifiable;
  • Modifiable, and
  • Traceable.

Based on the attributes outlined above, a use case would most closely match the definition followed closely by classic text-based requirements documents. While the requirement specification can be built iteratively, completion of the SRS (generally at the beginning of the overall project) marks the compilation of the complete set of requirements.  Agile frameworks do not seek to define a complete set of requirements early in the project. Rather, most Agile techniques require you to gather only the stories that you needed to get started and then add stories to the backlog as the project progresses.  Agile techniques accept changes and new requirements even late in delivery.  How the changes and new stories are prioritized is a matter for the Product Owner.

In classic development techniques the use case or text-based requirement represents a repository of all of the information about the requirement. While I was cleaning a filing cabinet recently I came across several use cases that were in excess of fifty pages. Classic requirements definition methods strive to capture all of the known information, not to ensure that the specific requirement is complete, but that it is unambiguous.  Agile techniques, and therefore user stories, take a different tack.  The user story marks the beginning a conversation that will culminate with the delivery of software that reflects the user’s actual needs, therefore delivering the maximum value.

Standard requirement techniques, such as use cases and text-based requirements, are tools to capture the complete set of requirements early in a project and at the maximum level of detail.  Agile assumes that the user story is a starting point and that conversation, acceptance criteria and the demonstration of functional code will be needed to truly define what is needed and what will ultimately be developed.

[1] IEEE Std 830-1998 p4