UML, Lightweight requirements gathering, and User Stories

As described by Mike Cohn, a User Story has several components to it; and the Description should be written in following format.

As you can see, this format basically focuses on three parts: role, action, and value creation. You would be looking to collect the requirements while starting on a new project. And, you have an unlikely ally, a partner in the form of UML – the Unified Modelling Language that can help you with this. UML can help you in your quest for collecting meaningful user stories.

Anytime you start discussion of any application, you will start with Context diagram for the proposed solution. Context diagram, in essence is a diagram showing your proposed solution and all the players that will interact with this solution. I have found this (context diagram) to be extremely useful in getting the requirements gathering going.

Let’s look at an example. In my book, Agile Release Planning, I talk about an example project of creating a website www.nflFans.com to act as web portal where all football fans can buy and sell game tickets. As part of the lightweight requirements gathering, I would have my team start with the central idea; putting a box in the center to show the future proposed solution.

Now, start discussing the interactions and all the actors that would be interacting with this proposed application. There are several roles and actors, human as well as non-human, that will interact with app. Actors such as Football fans, our web portal as a system, credit card companies for credit card processing, Football teams for providing seat availability, etc. As you discuss various interactions, continue capturing the actors into this context diagram. Now, the context diagram looks like this.

If you overlay User story format on top of this diagram, you will realize that this context diagram give you the first part of your user story As a/an.

UML helps you keep the discussion at a high level, rather at the right level. In the next episode we will talk about extending this context diagram to get second part of the user story using this lightweight requirements gathering approach.