Nines
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.
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
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?
Tom
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
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
