I am thinking of going on a crusade against functional requirements. Why? Functional requirements are overblown, over-specified, over-referenced, over-exampled, and we need to get over them. By the over-focus on functional requirements by tools, books, and pundits, we cajole our customers to attempt to detail and confirm the functional requirements down to the gnat's eye.
And this is just wrong, wrong, wrong.
As you know, a functional requirement is a requirement that describes the thing the system must do, action to take, rules to enforce, information to remember. Not necessarily a bad thing and certainty not worthy of a crusade. To see where we go over-the-top, we should look at an example.
"I want to be paid."
We can translate that to the functional requirement, "the system must pay the employee." So far, so good. I am cool with this. I like getting paid. Then we development folk will whip out our models (class, activity, use cases, state diagrams), hold massive interviews, and try to get the customer to state functional requirements to capture in big specifications (or tiny stories) like:
- The system will collect the hours worked
- The system will calculate the gross pay
- The system will calculate the deductions
- The system will calculate the net pay
- The system will transfer the funds into the employee's personal account
Boring!
Maybe the last one needs a bit more of a look but the others didn't really surprise anyone. That is the thing about functional requirements: for the most part, they are pretty darn obvious. So instead of stopping there, down we drill until we get things like:
- The system will set the paid flag on the employee periodic transaction
From bored to disengaged.
We have moved from the nice stuff that is obvious to the stuff the customer really doesn't care about. All the customers care about is that the software does those obvious functional things in a correct and useful way with minimal effort on their part. These requirements—requirements beyond the functional—are not obvious.
I always cringe at the image of those early smart software development folks who were looking at all the requirements that were NOT functional and said, "What should we call these? We know they are not functional. They are.. are... NON-FUNCTIONAL!" So if functional requirements are important (if obvious), non-functional requirements must be non-important! This is backed-up by the fact we don't have many models, tools, or techniques to explicitly elicit these non-important requirements.
Sigh.
Since these are not obvious and we do not have great means of eliciting them, they tend to be ignored. This is to the peril of most of our projects since it is these non-functional requirements that determine the cost and duration of the project. Contrary to popular belief (and many books), functional requirements do not determine how long a project will take. They only identify the sets of non-functional requirements that need to be scaled and goals defined.
Yes, I can, in a gross way, control scope by taking sets of non-functional requirements (tied to a functional) in and out of the project. But I can meet any arbitrary set of functional requirements in any amount of time if you let me dictate the non-functional requirements. Heck, we do it all the time when management requires us to put an unachievable amount in of functionality in a unrealistic short time frame. We just relax the non-functionals; especially maintainability, serviceability, interoperability, usability, and reliability.
Think Zune.
You too can take up this Don Quixote charge against the windmills of functional requirements. The next time you are tempted to create another functional "story", think instead of how-well that boring story should work. What would make a customer *like* that story. If you do that, you have will have served your team well.
Unfortunately, you probably also damaged a source of green power. Sigh.