Monday, 11 May 2015

Using Agile for Essential Requirements instead of NFR (Non-Functional Requirements)

This article will present the reasons why optional NFR (Non-Functional Requirements) [1] are myth in Agile and should instead be replaced by the terminology of Essential Requirements.

Often Business stake holders and even IT can on occasion consider NFR's as being optional. Such as Security, Quality, Automation, Performance, Scalability and so on.

However when such functions are removed it becomes apparent that they were needed features after all. This can have negative consequences in incurring technical debt or even complete delivery failure.

The reason that this problem exists is I believe the NFR label that the underlying has been given to is wrong. If we look at the Wikipedia view of a Functional and NFR:

Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system.

However I think it would be hard for anyone to say that technical architecture of any system is not a required and should also not function. Yet that is what the “Non-” part is implying. Therefore the naming convention is clearly wrong.

Then there are many interpretations of requirements labels as per the diagram below:

We can make this problem go away if we distil most requirements down to two types of requirements that are of Value:

  • Economic: Makes Money and Saves Money as to Net Present Value [2].
  • Essential: Cost Avoidance [3].

Once you have Economic and Essential Requirements the option of disregarding Essential ones disappears fast, as people then have a much harder time of trying to explain why something that is Essential should be dropped.

If they do drop it and of course there is a failure then they have an even harder time of explaining why they dropped something that was clearly Essential and was identified as such. After such a revelation they probably won't be dropping anything Essential ever again.

Agile Link:
Essential Requirements are often stated as a quality mandate via the Scrum practice of the DoD (Definition of Done) [4]. Any feature cannot make it into Production without the Essential Requirements of the DoD being completed.

Also using the INVEST mnemonic [5] Essential Requirements are often teased out to update the DoD via the Value. Where if it is of Value and Repeatable then no doubt it may end up as an Essential Requirement within the DoD long term.

Using this Essential terminology and existing approaches we can see that optional NFR are a myth in Agile. Scrum and INVEST are of course represented within my Agile Poster too [6].