Expressing Non-Functional Requirements

NFRs have recently been a topic of debate in our hallowed halls and, as usually happens in most good technical teams, there isn't any shortage of ideas, good patterns, and approaches to quality - just a lingering feeling that life would somehow be better if we had a more consistent and explicit definition of done.

A few years ago I wrote a short series on what I called The 6 Principles of Webscale Computing and, now that I revisit them older and [depending on whom you ask] wiser, I can see a little room for a bit of a brush up. Those key elements which I hold most dear are:

1 - Scalability
2 - Maintainability
3 - Quality
4 - Security
5 - Availability
6 - Usability

What I found particularly effective was documenting NFRs as user stories; this let us express them in a format that developers are already familiar with and make them a bit more specific and actionable than just 'do a good job'. Using the as-proven-by story clauses allowed that extra degree of flexibility which good engineers will use to make interpretations appropriate to the project they're working on - deftly sidestepping the joint pitfalls of waste (gold plating little used or less critical components) and undercooking (not putting enough in where it counts most). And, after all, a non-functional requirement is still just a requirement and if you want something done in software development there is no better way than to 'require' it.

Over the coming few weeks I'll be dusting those old stories off, giving them a bit of a polish, putting them back up here and - to strike terror into the hearts of my team - turning up to their demos to see them implemented in practice!