Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality. Without a clear idea of how to set requirements, most software development projects will face either significant rework or fail altogether.  Over the past few years,  Agile methodologies appear to be helping reduce this problem.  This whitepaper will explore techniques of capturing requirements within Agile teams.

Wikipedia says that, “The term Agile Software Development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.”

So, if we apply a sports analogy, using Agile methods to develop software is like a series of sprint races. Developers are focused solely on successfully completing the next iteration, which is often due within a matter of weeks, and they zero in on defining their requirements to achieve that short-term goal.

In other words,  Agile teams don’t produce any requirements specifications that are not absolutely critical to making it clear to the team what is expected of them in the short term. So, the question becomes: How do you decide what requirements are “just enough” to complete the next iteration? 

There are a number of factors that need to be considered, when deciding what techniques and how much level of detail to provide when defining requirements for an Agile team.  These considerations should include: 

• Team size and the proximity of team members
• Skill and experience of the team
• Has the team worked together before?
• Complexity of the requirements
• Complexity of the software.

Keeping the above considerations in mind, you will need to decide which techniques you will want to use and how much detail you will want to provide while using these techniques.

Common techniques include:

Verbal Communications. Verbal communications, perhaps using a whiteboard to capture key thoughts, is typically the fastest way to define a requirement.  However, what this approach makes up for in initial speed, it doesn’t ensure that all stakeholders are in the loop. Plus, participants may not all remember exactly what was decided after the meeting breaks up.  It is all too easy to have a different recollection of details that were discussed two weeks ago.  This can lead to misunderstanding of requirements during development and testing, and will be reflected in inaccurate product user guides and training material. So you may have saved time initially, but wasted more time in the long run.

So when is verbal better than written communication?  Agile methods promote face-to-face interactions, but that can be impractical in cases where teams are scattered across the globe or even across a city.  Relying only on verbal communications is a last resort, to be used only when short-term time gains are worth more than the longer term problems this approach can create. 

Story Cards.  A popular and valuable technique within Agile development teams is to create a story card.  These story cards tend to provide a text-based description of who wants to do what and why, along with perhaps a picture of the screen and some test scenarios.  This technique works well for very small features but may not scale well for larger or more complex features that integrate and depend on other features. 

Requirements Lists. Often a common place to start from a product scoping point of view is to create a hierarchical “Requirements List” which captures in text form an organized and grouped list of functional requirements, technical requirements, business drivers etc.  Often these text descriptions can be enough to clearly articulate what the requirement is  For example a technical requirement such as, “The application must support IE 6 and IE 7,” does not really need any additional explanation.  However a requirement such as “The application must be able to define which users can have access to specific functionality and data” will need much more detail.  The point is to only expand on requirements that truly need more details. 

Use-Case Flows. Sometimes to truly understand the overall flow of a more complex requirement use-case flows or simulations are required to capture “just enough” requirements.  However from my point of view it typically is not a good idea to use “use cases” to document complex logic or business rules such as authorization logic. These types of requirements are often better documented in text or tabular formats. For example, a simple 2×2 table showing the roles on one axis and what they can do on the other axis is a much more efficient way to convey authorization business rules than embedding alternate flows into use cases.

Simulations. Simulations can add great value to really bring a concept to life, but adding every single detail into the simulation can take too much time. And, frankly, it is sometimes difficult for developers to reverse-engineer a simulation and extract a discrete set of requirements.  It is much easier for an Agile team member to read a simple table showing who can do what, than to run through a simulation and reverse-engineer the same information. Also, it is possible to spend too much time doing elaborate simulations that don’t add enough value for the time and effort they can take to develop. 

Everyone will have their personal preference as to when to use what technique for communicating requirements, but the key is for the team to work together and agree upon when it makes sense to use different techniques and not “force” a technique when it clearly can be done more easily another way.

General Repository. No matter what techniques you decide to use to document requirements, keeping these requirements details/artifacts in a central repository and linking them to each other in an organized manner is critical to the collective success of your Agile team.  Relying on people to keep track of endless email trails and simple document repositories with manually maintained links is not the answer.  People are too busy to do it, and, most likely, the data repositories will not be kept up-to-date.  Because of that, any repository needs to do whenever possible to automatically create and maintain these links based on how the artifacts are organized. For example, if a use case refers to a screen on a given step, then that screen should be automatically linked to that step in the repository.

So how do you know what is enough detail?  Your team will let you know when things require more details.  Part of working within an Agile team is to expect the need for requirements clarification throughout the project.  In traditional waterfall, this was almost discouraged and under the good intentions of change management.  However, within Agile, it is expected and embraced, which takes some getting used to for Agile newbies.

Recap

This topic is much deeper than can be covered with this small article, but the key points are

• Make a conscious decision on the level of detail you want but expect to tweak that during development.
• Choose the right technique for the requirement you are trying to describe.  
• Make sure you keep an integrated central repository that links together the multiple requirements artifacts.