Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
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
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!
Published at DZone with permission of Dave Rooney , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.