First a quote from a recent comment.

The architect might not be responsible for defining the non-functional requirements, but they're definitely responsible for fulfilling them.

I agree, typically the architect will fulfil the requirements rather than define them, although sometimes you need to define them too.

I've been burnt by non-functional requirements before, either because they've been ambiguously defined (e.g. "the system must be fast") or because they simply haven't been defined. Both are fairly common occurrences. When specifying a software system, it's much easier to think about exactly what it should do. The features of a system are tangible and, ultimately, demonstrable. The non-functional qualities, on the other hand, are much harder to define and people often have problems quantifying them. If somebody says, "the web application must be fast", how fast is that? Do you want response times of less than a second or less than a minute?

As an architect, I've learnt the hard way that you must try to quantify the non-functional qualities. If somebody says, "the web application must be fast", you need to ask them exactly how fast it should be. Get specific, ask about response times for key use cases and how many concurrent users this applies to.

More often than not you'll be able to ask the right questions and use your exploratory skills to figure out what the non-functional requirements are. When this isn't the case, sometimes you just have to put a stake in the ground and define the requirements yourself. This either results in a general agreement or it forces people to think through it further and provide the numbers you are looking for. The non-functional requirements need to be defined and somebody has to do it.

Responses[5]

Posted by Simon Brown on 13 June 2007 12:14:00 BST #