Functionality Is Cheap
- Posted on July 16, 2008 2:54:PM by Earl Beede to Practicing Earl
- Technique, humor, requirements, scope
Well, I better rephrase that. The functional part of a requirement is cheap. I can deliver the functional part of a requirement in as little time and in as small of a cost as you like if you let me control the non-functional parts of the requirement.
That is a heck of a claim.
So how do I back that up? First, we need to look into what is a requirement. This is a well covered territory but I have a slightly different spin on it. I maintain that a requirement has two main parts: a functional statement and the non-functional qualifiers of the functional statement.
For example, in the statement, "The system shall deliver the message within three minutes," the "deliver the message" is the functional statement and "within three minutes" is the non-functional qualifier.
In a statement such as "The system shall update the record," the only requirement bit–"update the record"–is the functional part. The non-functional part is assumed, such as "in my lifetime".
It is these non-functional qualifiers that determine the cost and duration of a task or a project. Without at least the critical non-functional qualifiers for a functional statement identified, I really have no idea how long something will take to build or how much it will cost.
Does somebody want a fast solution that consumes large amounts of memory or do they want us to spend time and money to make something that is more elegant and uses less memory?
In fact, you can think of any non-functional qualifier/attribute/quality as being on an abstracted scale that looks like this.
How much I constrain memory use is a choice. I can choose an aggressive point (B) or a more relaxed point (A). The issue is that since non-functional attributes are seldom specified, a project can base its early estimates on a point A assumption only to discover late in the project that the client had a point B desire.
This discovery, while impacting the cost and schedule of the project in a negative way, is NOT product scope creep. The product scope (function) is exactly the same, just how well that function performs has changed. This understanding of the difference between functional (scope) and non-functional (cost & duration) parts can help shed light on a lot of arguments in projects (Project: "It is scope creep!" Customer: "No it is not!"). It can be project scope creep but the word "scope" is usually used for product scope, not project.
The other interesting thing that you can start to see is that there is constant movement toward the more aggressive end of the scale (we all want the more aggressive stuff, don't we?). This movement to more aggressive qualities drives innovation and technology. Functionality doesn't drive technology, non-functionality does.
For example, we have had ways to communicate before smart phones. The function "send a message" has been the same since personal runners and smoke signals. To make the "send a message" function "easier", "more friendly", "more convenient", "more accurate", and perhaps to combine a bunch of other existing functions into a "more portable" package–all of which are attributes that are non-functionals getting more aggressive–is what has driven communication innovation and given us smart phones. The function is basically the same.
This use of the word function is more precise than some popular use. I often hear teams talk about "adding functionality" when, in truth, they are not; they are just making some non-functional attribute of an existing function more aggressive. Is adding a camera to my cell phone adding functionality or merely changing the packaging of two existing functions to make it more "convenient", more "portable"?
I really don't think we invent new functions very often. Mostly we just repackage them to improve the non-functional attributes.
Because the scope (functionality) is often the only part that is specified, project teams faced with impossible schedules often fall back on the same trick. Instead of cutting scope which is highly visible to the customer (and all the non-functional attributes attached to each scope cut), the team will instead cut back on the rarely specified and somewhat hidden non-functional attributes of the specified functionality.
That is, instead of delivering at point B as planned, the project team slides the non-functional attribute toward the relaxed side of the scale. This movement toward a relaxed value will decrease the cost and schedule without changing the claim to deliver the function. The typical sacrificial non-functionals attributes are "maintainability", "reliability", "serviceability", and "portability".
So, back to my claim that I can deliver any functionality (the functional part of a requirement) in as little time as you like IF you allow me to relax the non-functional attributes. It really is not such a bold claim after all since the functionality probably exists today in some form and I can just grab that off the self.
Worse case is that I can say that the output time (a non-functional attribute) will take three million years (a very relaxed value). Just be patient.
Now, about my payment . . .