It is certainly a conceptual error, as Nick explains, to define an engineering concept in negative terms, in other words in terms of what it isn't. But in addition to being a conceptual error, it is also a psychological error, because it makes us believe that the concept is somehow unimportant. Here's what I said in my 2001 book on the Component-Based Business (page 105).
In some cases, some technical requirements of a component can be explicitly derived from the overall solution requirements. In other cases, they are left implicit or delegated to "technical" personnel. These requirements may include such factors as availability, reliability and performance.
These requirements are often regarded as second-class ones, deserving less respect and attention. Much time and energy is typically devoted to getting them right, but this is often grudging and carries less status and reward. Businessmen often call these "hygiene factors", as if to say that they're about the same level as cleaning the office toilets. And software engineers convey a similar attitude when they refer to requirements as "non-functional" - they might as well call them dysfunctional and be done with it.
When I wrote that book, I objected to the term "non-functional requirements" because I believed that such requirements were as important as so-called "functional requirements", but I have since changed my mind. What I now believe is that such requirements are very much more important, at least from an architectural perspective, than the so-called "functional requirements".
This is because it is generally easier to plug in or mash in extra functionality, with fewer architectural implications, than to plug in extra performance. Plugging in a bit of extra functionality is like adding a satellite navigation device or an entertainment console to your automobile. But if you want to carry double the passengers at twice the speed, you have to totally reengineer the vehicle and the engine. Let me quote myself again, this time from last year [Blueprints]
In a traditional waterfall development, many people thought it was a good idea to address the functional requirements first (logical design), and then tweak the design (physical design) until you satisfied the non-functional requirements as well. But when you are composing solutions from prebuilt enterprise services, this approach just doesn't wash. Indeed, it may now be the other way around: if a service assembly fails some functional requirement, you may be able to plug/mash in some additional service to fill the gap; but if it fails the non-functional requirements you may have to throw the whole thing away and start again.
In my opinion, therefore, the architect needs to worry about those requirements that have major structural implications, and can mostly leave the functional requirements to the business analysts and developers.
In general, these structural requirements can't be defined or managed at the level of the individual service, but need attention to the overall geometry of the solution. So a better name for them might be "holistic".
Meanwhile, another extremely important class of requirements arises from the commercial constraints. Someone once told me that when an IKEA designer is given a design task, the starting point for the design is the intended retail price of the finished item. "Design a lamp we can sell for 20 Euros". An SOA equivalent would be to tell the service designer "build me an invoicing service that will operate for less than x dollars per thousand". This aspect of requirements engineering is completely ignored in most design methods, which assume that the price is tacked on at the end.
So I guess anyone who thinks the quality requirements are non-functional probably thinks the commercial requirements are non-non-functional.