As anyone who has ever worked with me will know, I’m somewhat of an advocate of Non-Functional Requirements (NFR) Analysis.  I’ve found that in some projects, sadly, the NFRs are left unexamined, with the Functional Requirements taking the lime-light.  This is understandable, after all it’s far easier to talk about what needs to change, and far harder to talk about the quality attributes and other non-functional elements of that same change.  Yet get the NFRs wrong, and you end up building a very shiny and expensive system that nobody actually uses.  If you are in the UK and have been to a Post Office recently you may have experienced the ‘self-service’ booths.  As Roland Hesz observed on Twitter, these are so complicated to use that they have a member of staff guiding people through the process….

For a whole variety of reasons, I’ve been thinking about NFRs a lot recently, and I came across three articles that really resonated with me, and made me think it’s about time we revisited the ‘standard lists’ of NFRs that we use.  In particular, I think there are two sets of categories that we ought to add. 

Imagine the scene: You’re just about to start the analysis for a project which involves a large contact centre employing hundreds of people.  The call centre manager hands you a dusty folder marked Procedure Guide.  “Here you go, this is exactly how we do things here.” says the manager, “this will save you interviewing our busy front-line workers!”. 

I suspect many of us have experienced this situation (although it’s far more likely to be some kind of electronic repository rather than a dusty manual) and when it happens we try and hold back a wry smile.  Procedure guides are extremely useful artefacts, but so often they are not properly managed and maintained and they quickly fall into disrepair. In some cases, the work that is conducted on the shop floor often bares only a passing resemblance to the ‘official’ processes, and in many cases there are unofficial ‘enhancements’, ‘interpretations’ and ‘workarounds’ that have crept in over the years.

With this in mind, when we are carrying out business analysis and improvement work it’s important that we understand how the work really works.  Elicitation techniques such as observation, apprenticing, scenario analysis and many others can help here.  If the process hasn’t been well-managed and well-maintained it’s highly likely that we’ll find variation.  Differences between teams, and even individual workers may have emerged.  There may be entire new ‘steps’ in the process that have been created, or steps might have been removed, re-ordered or changed in some other way.

Standardisation Isn’t (Always) Our Friend

Like most folks I know, I have a whole range of mixed memories from my years at school.  Some fantastically ecstatic, others scary and traumatic, but I suppose the sum of those experiences were all ‘character building’.  If you had met me as a school-age child, you would have found someone who had very strong ideological views, but who so often lacked the ability to express them clearly.  Some would argue that little has changed 🙂

I did fairly well at school, but was also seen as a bit feisty at times—my strong views and beliefs weren’t always compatible with the power structures that existed in schools (those power structures, by the way, extend way beyond the teachers and well into the playground).  One phrase that I remember people who perceived that they had power over me told me time and time again was:

“You’ll think differently when you’re older“