From the course: Applying Agile MoSCoW Prioritization

How to document requirements

From the course: Applying Agile MoSCoW Prioritization

Start my 1-month free trial

How to document requirements

“

- There are many ways to capture requirements. I've certainly seen a few over the years. Some of very detailed specifications and some are very high-level and vague. In Agile project environments, it's becoming more common to use a user story format to capture requirements because they are outcome-based descriptions focused entirely the user's needs. Remember, that we start our requirements gathering pretty early in the project and during the feasibility stage we may only have a handful of high-level requirements. These are sometimes called epics or themes. As we then move into the definition and eventually incremental delivery stages and break these down further, they are likely to be called user stories. So what is a user story? It's a technique used to capture a description of a product feature from an end-user perspective. And we create these to keep everybody focused on the needs of the user. User stories keep us from introducing too much detail too early in the project, which might limit design options and force developers into one solution. User stories focus on outcomes, not specifications, and give the design team the flexibility to design the right solution. And user stories breakdown the requirements into smaller chunks and then, by prioritizing them, provide the project with negotiable requirements. User stories may be captured in a variety of formats including a spreadsheet. Personally, I prefer to begin by creating a user story card using an actual index card, or a Post-it note. On the front of the user story, we record the story number and title, the role, requirement, and expected value. An example of a user story could be, as a user of a website, I want to book tickets for attractions in advance so that I don't have to queue up on the day. The reverse side of a user story contains valuable information on the quality criteria for the requirement, including functional and non-functional requirements. You'll notice that these criteria have been written in the form of questions. The idea being that they should all answer yes when tested. These criteria will in fact help us to identify how to test the products to ensure that they pass and are ultimately accepted by the customer. Please remember that this is a great visible method used by very agile teams. Often these can even be recorded on Post-it notes and stuck up on a whiteboard. In other cases, teams that may be dispersed are using software like Jira or Trello to create and share user stories. Ultimately, it doesn't matter how formally or informally you document your requirements, as long as they're captured in some way. Have a go at writing some user stories for the sample project I provided in the Exercise Files. I filled in a couple to get you started.

Contents