The 6+1 Essential Questions that define a Requirements Approach
Also published in a revised form on LinkedIn October 24th, 2018
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 first question 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 three 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.
How will the understanding of requirements be checked?
The answer to this question depends on who will be communicating requirements to the developers. If it’s the person that has the requirement, we need only check the developer’s understanding of requirements. But if requirements are communicated by a third party, we will need to check the third party’s understanding in addition to the developers.
Verification and Validation (V&V) is the traditional approach for checking developer and third party understanding. Test Driven Requirements (TDR) techniques such as Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD) are the agile approaches for checking developer understanding.
Providing the person with the requirement with frequent opportunities to review and comment on working software based on their requirements also provides a way to check developer understanding.
Comparing approaches
In the past, the traditional approach has favoured:
- business analysts communicating requirements to software developers;
- in the form of documents; that
- have been ‘signed off’ well before development begins; with
- extensive V&V activities that check both business analyst and developer understanding of requirements.
The agile approach favours:
- just-in-time definition of requirements;
- face-to-face communication of requirements; between
- co-located teams of developers and their customers; employing
- TDR techniques to check developer understanding of requirements.
Many readers will have noticed that there is still one more question to be asked:
Why communicate requirements?
While we can answer the how, when, who, where and what of a requirements approach in many ways, each way resulting in a unique set of challenges, the answer to why will always be the same:
To create shared understanding between the person that has the requirement and the developers that will implement the requirement.
Shared understanding is difficult to create in geographically distributed teams that rely on documents, written by third parties to communicate requirements. In contrast, shared understanding thrives in co-located teams using face-to-face communication to communicate requirements.
The 6+1 Essential Questions that define a Requirements Approach