Six Requirements Models For Agile Projects

ArgonDigital - enterprise automation experts

Share This Post

When working on any agile project, most people will agree there is still a need to understand requirements. With the quick iterations of these projects, it’s more important than ever, to use visual models to capture the requirements. When done correctly, they are easier and quicker to create and understand than a list of written requirements. Selecting the appropriate models will vary by project; however, we can suggest a few common choices that work well.

High Level Models
At the beginning of the project, it is important to get a quick picture of the breadth of the project. This picture will help the team determine where to dive for depth. It is really important that these models are done as broad strokes, with just the bare minimum information. To get a sketch of that big picture, consider these models:

  • Context diagram – This diagram simply sets the landscape of the project, clearly indicating the scope boundaries.
  • Data flow diagram – This is a quick sketch of the key pieces of data flowing through the system, including where it is created, changed and deleted. The data in this diagram should only be data that is important to the users of the system. They will help to identify the most important data and systems to work with.
  • High-level process flow – Let’s start by saying this is nothing fancy or complex. The flow diagram should describe the major obvious steps. Again, the purpose is to sketch it simply, to give the big picture. In no way is it meant to be comprehensive or detailed.

Imagine one of your iterations requires bringing in new users to the team. These four models will give them an opportunity to quickly see the big picture of what this project is and where it is going, without having to read a 200 page spec (since there isn’t one!). You can also use them with your users to prioritize the most important pieces of the system for the iterations.

Models in the Iterations
Once you have prioritized the work for the first iteration, the two most popular models are likely to be:

  • User stories – You can write these for the most important parts of the flow. They will be less detailed than the traditional use cases, supplying just enough depth to be developed.
  • Wireframes – These will be connected to high-risk user stories, when sketching an interface might be a good aid to help the users explain what they need. These should be done in a quick modeling tool, or just by hand.

There will be other models. Sometimes you won’t even use these. The common theme in all of them is to create a visual representation of the requirements because it is faster to create and read. And with them all, only do the bare minimum necessary.

More To Explore