Whither Requirements?

We accomplish what we understand. If we are to accomplish something together, we need to understand it together.

Signature from Ron Jeffries e-mail, circa 2005.

A common issue I've encountered with teams starting to use an Agile approach such as Scrum is that they feel they must abandon all existing methods of requirements gathering and start writing nothing but User Stories.

Requirements for a system can be expressed in a multitude of ways, including but not limited to:

• Traditional "the system shall" type of system requirements
• Use Cases
• User Stories
• People sitting beside each other discussing what needs to be done

These approaches have some significant differences.  Traditional requirements tend to focus on very specific system functionality without a direct view to the ultimate goals of the people who will be using the system.  Use Cases can also have the same problem if they focus on the "how" as opposed to the "what" of a system, although they do represent an improvement.  They also tend towards verbosity with early expression of detail that can lock in specific implementations.  User Stories explicitly focus on the outcomes from a customer value perspective, and intentionally avoid details until they are required.  Sitting with the person or people for whom you are building a system and just talking and showing the work as it progresses avoids all confusion about the work and the need for any formal documentation.

In each of these cases, it's quite possible to change each point from a weakness to a strength and vice versa!  When you get right down to it, all of these forms of requirements and the process of using them have a single underlying goal.

That goal is the achievement of a SHARED UNDERSTANDING of the work to be done.

As Ron's e-mail signature above suggests, it doesn't matter if you use smoke signals, crystal balls or Vulcan mind melds as long as everyone has the same shared understanding of what must be done!  How you achieve that understanding is up to you, although a collaborative approach is almost always the easiest way to get there.  The closer together the people who need the system and those who implement it work, the higher the probability that a shared understanding will occur.  The more frequent the opportunities for feedback, the higher the probability of a shared understanding.  The more you can defer the expression of details in the requirements until they are really needed, the higher the probability.

So, the form in which the requirements are recorded is a secondary consideration to achieving the shared understanding.  You need to be cognizant, though, of the inherent strengths and weaknesses of each approach.  An unrecorded discussion between two people may be the most efficient and lightweight approach, but if that understanding needs to be shared with a larger group then it falls short.  A detailed requirements document may achieve the goal when it was written, but as time passes the understanding erodes and the requirements that were recorded may become obsolete.

Regardless of the context and the choice of requirements approach, you need to keep the overall goal in mind and use it as a test:

Does everyone have the same understanding of what this work means?

How you get there is up to you!