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.
Update
Words matter. But if we toss "requirements" in favor of *design*, we defenestrate "NFR" in the same motion!https://t.co/ndQeo3YS4e— VisArch (@ruthmalan) October 20, 2016
References
Ruth Malan, Non-Functional Words - Tricky Beasties (January 2014)
Nick Malik, Non-Functional Requirements (October 2008)
I agree with you Richard, and Nick. The term "non-functional" can cause a snag in understanding as to their purpose.
ReplyDeleteWhen I teach the fundamentals of requirement types, I feel forced to do a little joke about the non-functionals - "these are the ones that don't work".
And then I tell the class, these are the ones that don't necessarily drive forward the original business objective for the project, but they must be done.
They are the rules and regulations, sometimes "just" the standards our company has decided on - Microsoft vs. Apple, buy vs. build, suites of products vs. best of breed.
But I like your thought, Richard, that these requirements can affect the overall geometry of the solution - they can impose fundamental design choices. And as Nick said, they should be challenge-able - or at least we analysts should let the customer know the constraint has profound, sometimes costly, implications.
I believe I'll try to work your ideas into my teaching material. Thanks to you both.
I think a better example would be a house.
ReplyDeleteIf I decided I needed to add a formal dining room to entertain clients at home, this would be a functional requirement. It would be relatively simple to add the room to most houses.
Consider the exterior construction of a house. This used to be 2x4 construction with 4in insulation. Now most building codes require 2x6 with 6in insulation. This would be a "non-functional" requirement.
Switching from 2x4 to 2x6 exterior walls, to correct a building code violation, would essentially require me to demolish the house and start over. That is because I have to replace all of the exterior walls, and these are the primary load-bearing structures.
Software may be "soft," but the "non-functional" requirements are typically replicated throughout the structure of the code, just as studs and insulation are replicated throughout the structure of a house.
Of course, addressing this is one of the goals of component-based and aspect-oriented development techniques. However, you reach a certain point where you have to have the structural framing to support everything, and introducing flexibility costs too much in terms of cost, performance, maintenance and understandability. "Standard plumbing components" work well, but rely on the studs and joists for support. The studs and joists may be formed from standard lumber sizes, but they are individually cut to size and lose their adaptability. (Every carpenter wants a board stretcher!)
I'd like to add something to David's example.
ReplyDeleteIn my view, it is not the job of the architect to design every tiny detail of the building. Surely the electrician can be trusted to design the wiring, and the plumber to design the plumbing. But it is the responsibility of the architect to make sure that the wiring and the plumbing can be maintained and extended without ripping up the floorboards.
Architecture is not just about coming up with the concept (the floor plan, we're gonna have a bathroom just here) but also thinking about how the building is going to work as a whole, over time. Maybe building architects aren't always very good at that (as Stewart Brand complains in How Buildings Learn), but system architects have to be.
In other words, architecting for change. Adaptability is of course usually classified as one of the so-called non-functional requirements. (Even though we already know that wiring and plumbing should be replaced every 15 years, so why isn't it classified as a functional requirement?)
Systems adaptability is achieved with a layered architecture, which separates the layers according to the expected pace of change. You cannot derive this layering from the functional requirements alone. However, you might be able to derive this layering from the functional requirements together with some standard architectural patterns that make some broad assumptions about adaptability, as well as the other so-called non-functional requirements.
A lazy or inexperienced architect might just make a load of assumptions and hope for the best, but a good architect faced with a reasonably interesting set of requirements, will pay careful attention to this kind of thing.