Lonsdale Systems

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:

The agile approach favours:

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

Courses Resources Blog Portfolio About Contact Search Feed
Lonsdale Systems