Do you really *need* that?

I've been reviewing some software architecture documents as part of a training course today, where the authors had restated the non-functional requirements. Given that the non-functional requirements are some of the key architectural drivers, restating them in the architecture document is something that I recommend and like to see, so I was pleased that this had been done here. The thing that really struck me, though, was how nobody had seemed to question the requirements that they had been given. While most were okay, the availability requirement really stuck out as being extreme, for what is basically a desktop-based CRUD application.

The system must be available for 99.99% of the time, from 9am to 6pm London time.

With a duration of 9 working hours, this availability requirement means that only about 3 seconds of downtime can be tolerated. As a general guide, I'd say that availability figures of 99% and above mean that you have to start thinking about different types of architectures that include characteristics such as automatic (or very fast manual) failover, clustering, no single points of failure and so on. Clearly, a change in the architecture has a knock-on effect to the cost, potentially turning a £100,000 project into a £1,000,000 project. Whenever you're given non-functional requirements, always be prepared to ask the stakeholders whether they really *need* them and remember to emphasise that added complexity doesn't come for free.

About the author

Simon lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, helping teams to build better software. His client list spans over 20 countries and includes organisations ranging from small technology startups through to global household names. Simon is an award-winning speaker and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. He still codes too. You can tweet Simon at @simonbrown.

Re: Nines

Surely the purpose of the architecture document is not merely to list the requirements again, but to demonstrate that they're being met? The consequences of the non-functional requirements should therefore be fairly evident. The real problem arises, as you point out, when nothing is questioned.

Similarly I've been working on a project that seemed to cover all bases in its NFRs: "24x7", "365 days a year" and "always available during working hours". Naturally this was pushed back and it turned out noone had asked for it; it was simply someone filling in the boxes on the NFR template.

Re: Nines

Oh yes, those requirements must be justified in the software architecture document.

Re: Nines

Sorry, I meant, it must be justified that those requirements are *satisifed*.

Re: Nines

Interesting, I think a common problem is that NFRs are fall between two stools- two technical for the business people to write and too businessy for the architects to write. This implies that you often see two anti-patterns... The first is NFRs that are wildly over stringent, and presumably made up by business people who can't see why they should ever have any downtime ever (after all, Google is always up 'init). The second is NFRs, written by technical people, which actually just state the limitations of the system "The system shall not support the back button", "The system will only fail when there is a problem somewhere" etc etc

Does that chime with anyone else's experiences?


Re: Nines

The idea that the NFRs are often really the "Non-Functional Consequences" of a prescribed architecture definitely resonates with my experience.

Another consequence of doing your architecture at the wrong time perhaps?

Re: Nines

Agreed and see my comment below - we're trying to figure out NFRs (limitations) for an existing architecture! :-)

Re: Nines

As somebody performance testing a trading platform at the moment, I would agree with you, Tom. One of our biggest struggles has been trying to get the non-functional requirements from the key business stakeholders. We're asking questions such as "how many concurrent users do you want to support over the next X months?" and "how many trades per day are you expecting over the next X months?", but we're still finding it hard to get definitive answers. I can make the NFRs up, but that might not represent the reality of the business. From their perspective, where's the business benefit in specifying upper limits?

Re: Nines

Yes, I see over stringent NFRs very often. Rather than allowing the business people to compare to another IT system (google's budget is HUGE) I tend to compare to a car. A basic car from a mass producer is quite cheap and pretty reliable these days. How expensive would the car be if it could be guaranteed to have no faults for 10 years? No flat tyres, leaking coolant or even a replaced windscreen wiper? We all top up the coolant on our cars and replace the wipers so why is an IT system different?

Re: Nines

Recently I’ve dealt with two different managed hosting providers on behalf of my client and they both guarantee (through money back clauses) 100% uptime. Which is nonsense. They are basically hiding their real service levels. They know they can't be 100%. They know they can't even be 5 nines probably - they certainly can't beat pacemakers and air traffic control systems. So they'll take a small financial hit when they drop their service (if the customer notices...) just so they can splash the 100% sales pitch on their home page. This sort of woolly apologetic approach to availability encourages the business to expect unrealistic NFRs. "If the hosting provider can be 100% then why can't this new application?". It also begs the question, when you ask for a specific availability NFR how are you actually going to measure it in production?

Add a comment Send a TrackBack