Agile requirements
Old-fashioned structured development approaches tried to do a complete requirements analysis of the whole system before starting development. This does not work in practice because the development team learns as it goes along. They develop an understanding of the business area which means that they are better able to make design decisions later on. Getting started with development as soon as possible also means less of a delay at the start of the project.
However, the requirements analysis still needs to start somewhere, and there needs to be an overview of what the project is trying to achieve. This is essential for estimating the overall duration of the project, and for prioritising requirements. Most agile methodologies attempt to see the system from the user's point of view. The analysis therefore starts with a set of scenarios in which the user interacts with the system in order to complete some task. In Universal Modelling Language (UML), these are called use cases, and the summary diagram for representing them is shown below.
A use case diagram is a simple way to capture the overview requirements of a system. To get a better understanding of the user's requirements though, a little more detail is required. Extreme Programming (XP) uses the term user story for a more involved description of a specific requirement.
User stories
At a basic level, a user story captures similar information to the UML use case. It is often given using the structure
As a <type of user>,I want <some goal> so that <some reason>
An example would be As a customer, I want to update my profile so that my currency preferences are saved
The user story identifies the actor (customer) and the action (update profile) but also adds the motivation (saving currency preferences). XP recommends that every user story is captured on a card so that the collection of cards represents the entire scope of the project. Before starting work on a user story, the developer needs to have a conversation with the user to find out whether there is further detail that needs to be captured. If there is, it may be necessary to split the user story in smaller sub-stories, or by adding criteria that must be satisfied before the system task can be considered successful.
The procedure for preparing to work on a user story is sometimes called the 3 Cs method:
- Card
- Conversation
- Confirmation
Use cases
User stories
The three Cs
User stories: an agile introduction
10 tips for writing good user stories