Karl Wiegers' post Agile Requirements: What's the Big Deal? has triggered an interesting debate in the comments section. Since I have just finished presenting an Agile Business Analysis course, it seemed a good time to wade into the debate. Sadly LinkedIn tells me my thoughts are 'too long' for a comment so I have collected them in this article.
These days much our thinking seems to have been reduced to simple binary choices. In reality, most problems worth our attention are multi-dimensional by nature.
The agile vs. traditional requirements debate is no exception.
For me, the most important questions to ask about an approach to software requirements is:
How will the requirements be communicated to the developers of the software?
The answer can be in the form of requirements documents, face-to-face discussions (conversations) or as diagrams and models.
My follow-up question would be:
When will the requirements be defined?
The agile vs. traditional debate tends to revolve around the two extremes of 'up-front' definition before development starts, or 'just-in-time' definition while development is in progress.
My next question would be:
Who will communicate the requirements to the developers?
Here the choices are the person that has the requirement (customer, user, subject matter expert), or a third party such as a requirements or business analyst.
While these three questions define the essence of the agile vs. traditional requirements debate, there are two more questions that we should answer before fully understanding a requirements approach.
Where will the requirements be communicated?
Teams can be co-located or geographically distributed.
What format will be used to communicate the requirement?
There are many possibilities here, narrative prose, formal requirements statements, use cases, user stories and prototypes.
In the past, we have favoured business analysts communicating requirements to software developers in the form of documents that have been 'signed off' well before development begins.
The agile approach favours just-in-time, face-to-face communication of requirements between co-located teams of developers and their customers.
The more astute will have noticed that there is one more question that I should have asked:
Why communicate requirements?
For the answer to this question, I would direct you to Karl's book Software Requirements, 3rd Edition (Microsoft Press, 2013).
We can answer the 'how', 'when', 'who', 'where' and 'what' of requirements in many ways. Each way we answer will result in a unique set of challenges. But the answer to 'why' will always be the same.