Hitchhikers Guide to NFRs - the System Quality Attributes Map

Okay, so here’s something which I think is helpful – it’s something I’ve looked for online but haven’t seen before, so if you know of something similar I’d be keen to know about it (and I bet others would too).

 Click on the thumbnail for a full-sized copy, or if you have a tool that can import XMI you can work on the model directly (174KB).

Basically it’s a map of System Quality Attributes (SQA).  Don’t know what those are?  Wikipedia has volumes of information on them – they are the characteristics that we use to define and measure how a system will evolve and perform.  There’s a whole raft of these (availability, configurability, and so on) and you’ll find them sometimes referred to as “The ‘Illities”.

This map has only a fraction of those listed on Wikipedia – but it has all the ones that I’ve found to be essential or of practical value.

When we (the royal we, which primarily includes Solution Architects – but also Business Analysts and other roles as well) define Non-Functional Requirements (NFRs) we are defining how much of these SQAs we want, preferably in terms that can be measured and tested.

(…and by the way – by preferably I really mean “not optional”, “on pain of death”).

The idea of this map is to act as a tool – a sort of cheat sheet, a mechanism to help stimulate analysis and discussion.  I’m not saying that the relationships defined here are “it” – you might have improvements you can make.

It’s also to help NFR / SQA newbies (and old-hands) think about some of the conflicts that naturally exist between certain SQAs so that everyone’s a bit clearer on the road-blocks and holes in the road that need to be avoided.

So when the business owner says “ok, we need the system to be higher user friendly and really secure” – you know you have an issue.  I suggest you take this map and evolve the relationships as you see fit.

Let’s take some examples.

Interoperability, Compatibility and Standards Compliance are all related: if you’re talking about compatibility you might want to think about what standards you need to be complying with.  If you need to interoperate with something else the same thing will apply – and it also brings up questions around what you are and aren’t compatible with.  For example: adhering to W3C spec’s on HTML is generally good, but if you want to appeal to a segment of the market that values being on the bleeding edge of HTML5 you only need to be compatible with the browsers they’re using.  We could argue that these SQAs support each other to some extent – I’ll leave that up to you to evolve.

In my opinion, Scalability supports Availability: any work you do on scalability (both in analysis and implementation) is bound to have a positive contribution to availability.  If a system is easier to scale-out it’s probably going to be more available as you have more instances deployed – maybe they’re load balanced, maybe they aren’t.

Security often opposes Usability.  Jakob Nielsen (the well known usability researcher) has made a number of observations regarding the impacts of security on usability, and visa-versa.  For example, in Security & Human Factors he points out that:

• Usability advocates favor making it easy to use a system, ideally requiring no special access procedures at all, whereas
• security people favor making it hard to access a system, at least for unauthorized users.

You might also want to have a look at Stop Password Masking and The Human Factors of Password Security.

A final word: when specifying NFRs you need to think in terms of a hierarchy, “The system shall be secure” isn’t worth the paper it’s written on.  Have a look at this article on Security Guidance - Practical Non-Functional Requirements to see what I mean; also the Architecture Tradeoff Analysis Method (ATAM) talks about a utility tree - "a hierarchic model of the driving architectural requirements.  This would seem to me to be thinking along the sames lines.

Stay tuned, NFRs are the Solution Architects bread and butter and I intend on contributing much more on this topic in the future.