Simon is a hands-on software architect and has a BSc (Hons) in Computer Science from the University of Reading. Over the past 12 years, he’s been involved in projects ranging from rich desktop clients and web applications through to highly scalable distributed systems and service-oriented architectures; predominantly within the finance industry. He's also undertaken consulting and training roles with a broader focus on people, process and technology.
Separating the non-functionals
Start by focussing on one thing at a time
I was recently involved in a discussion where we were talking about the best way to increase the scalability of a software system, which is essentially a Java EE web application. The most obvious way to do this is to horizontally scale-out the application across multiple web servers (Tomcat, in this case), although I found it really interesting that the conversation soon turned towards topics such as the performance impact that session replication would have. Important as this is, we had moved on to talk about performance, availability, reliability and failover before finishing the scalability discussion. After all, there are some other options that are available.
My experience indicates that it's really easy to get sidetracked when dealing with non-functional requirements and this is just one such example. Yes, you do need to take a holistic view of your non-functional requirements, but you do also need to take each in turn and look at all of the available options. In this particular example, I had a very clear idea of the scalability requirements but not the availability and reliability requirements. For all I know, it might be okay if a user is forced to log back into the application in the event of a Tomcat node going down.
My advice is this - start by focussing on one thing at a time. On a related note, Think you know what scalability is? is a timely article that provides a good overview of what scalability is all about.
Re: Separating the non-functionals
The particular combination of NFRs you mention (scalability and performance, or scalability and availability) seem to often become mangled together into one unidentifiable meta-NFR. The same thing can easily happen with some of the other "ilities" such as extensibility and flexibility. I don't think that they weakly defined, but maybe their real meanings are not well understood outside of the architecture community.
I also often see a similllar blurring of terminology with security-related requirements, especially authorisation and authentication.
Re: Separating the non-functionals
Take, for example, your example of trying to scale a Tomcat web application - in having session state replication you've also introduced an additional NFR of ensuring that there's consistency of state in the event of a Tomcat failure. By satisfying both the scalability and consistency requirements, you're having some effect on the performance. You could have scalability and only marginally affect performance if you ditched the consistency requirement (e.g. by switching off the session state replication and ensuring that users are tied to a particular instance).
I think it's important to ask 'If I'm going to meet this particular NFR, what am I going to affect and is that going to be acceptable?'
