In the traditional way of developing software, analysts create an artefact called the “Requirements Document” or “Software Requirements Specification document (SRS).

The content and style of a requirements document varies enormously from organization to organization. Every time I work with a new company, I notice that the way they document requirements drastically differs from the manner the previous company I worked for, does their requirements documentation. Some requirements documents include pure requirement statements, while others include several of the UML diagrams (including domain classes and activity diagrams). Some of these documents were upwards of 400 pages in volume, making them very unattractive for anybody to really read and study.
Requirements Documentation in Agile

In Agile and in particular Scrum requirements must to be collected as well. After all, how would one be able to develop a solution, if they did not know what to develop? In Scrum however, the way requirements are documented, differ completely from the way it is being done in the traditional methods. Scrum advocates the creation of an artefact called the “Product Backlog”. A product backlog is nothing more than a prioritized list of the requirements (User Stories).
Sample Product Backlog

Some Scrum practitioners would disagree with me when I equate a user story to a requirement, but given the fact that I have seen so many ways of documenting requirements, I would argue that it does not really matter if a user story is the same as a requirement.  Fact is that they both attempt to convey the capability the system must be able to render.

A product backlog is a living artefact. It must be constantly updated. New items are discovered and added to the backlog based on feedback.  The priorities of user stories change regularly and if the backlog does not reflect that reality, developers will not build the software based on the priority set by the customer.

Requirements discovery is therefore a continuous process in Scrum.  That means that there is no such thing as having “ALL” the requirements available before development can start.

The product backlog items must also be estimated. The estimates are at this stage very rough and are usually done in terms of story points. A story point represent the relative level of efforts that will be required to materialize that requirement, compared to a requirement completed in past.

Product backlog items must be detailed appropriately. This means that higher priority requirements are described in more detail than lower-priority requirements. This is where the concept of an “Epic” comes into play. An epic is a user story that is described at a very high level (a high level requirement).

Requirements discovery, refinement, estimation and prioritization occur throughout the entire project.

This constant process of maintaining of the product backlog is often referred to as “Backlog Grooming”.
A more detailed description of the grooming process is beyond  the scope of this post.