Do requirements matter?
For the last decade, I've met in my life hundreds of French programmers, developers, leads and CTOs. None of them knew the difference between functional and non-functional requirements.
This wouldn't be so disturbing if it were limited to France: indeed, in countries like France, India or Algeria, the lack of formal, high quality education in IT sector, and the lag of most companies makes it difficult to expect a bit of formalism from IT staff. The problem is that it's not.
The revelation was this question on Programmers.SE:
I'm wondering about functional or non-functional requirements. I have found lot of different definitions for those terms and I can't assign some of my requirement to proper category.
I'm wondering about requirements that aren't connected with some action or have some additional conditions, for example:
- On the list of selected devices, device can be repeated.
- Database must contain at least 100 items
- Currency of some value must be in USD dollar.
- Device must have a name and power consumption value in Watts.
are those requirements functional or non-functional ?
The question received 10 answers (some were deleted and can be seen only by users with enough reputation):
- 2 answers (mine and the accepted one) are the right ones.
- 1 answer is a (relevant and somehow useful) comment.
- 7 answers show a complete misunderstanding of the subject. Among those answers, some are posted by a highly respected members of Programmers.SE who are very skillful and experienced developers.
Now that's a real problem. Not because those people were answering questions on a subject they know nothing about—Stack Exchange is a Q&A website, not an encyclopedia—but because they, with their broad experience in software development, are unaware of the answer in the first place.
Why would it matter?
The lack of proper requirements is one of the causes why IT projects fail. Other causes include but are not limited to hiring unskilled personnel, not managing software projects, not ensuring decent working conditions and permanently lying to coworkers and customers.
I've done dozens of projects, and I've never seen one with at least a readable spec.
Generally, things happen this way in a corporate environment:
A customer meets a representative (often a salesman) of the company to discuss the project. Great, two persons who know nothing about software development are discussing the major aspects of the future product.
A representative of the customer meets the project manager—often a former programmer with no formal education in architecture, design or requirements gathering—to draft the details. Parkinson's Law of Triviality ensures that the draft contains useless and annoying elements such as the color of the hyperlinks, but lacks the most important aspects of the product.
The draft becomes de facto “The Spec”.
Programmers attempt to read this draft (most courageous ones even try to understand it) and ask questions.
The manager answers the questions, based on his own understanding (or the lack of understanding) of the project.
The customer requests hundreds of changes which never find their way in the spec. If the spec is changed, either it becomes obsolete few days later (and not changed then) or, more often, it is already obsolete once the changes are written.
Such “spec”—if we are allowed to use this term—is not just useless; it is particularly harmful. It blocks creativity. It wastes money. It makes it possible for the company to have an excuse for being late: “We couldn't deliver on time, because we are actually working on additional features which are not in the spec”.
Every spec I've seen is a complete waste of resources, with no benefits whatsoever.
Once we understand that, we have a choice. We can create a real specification, or we can skip this step and do something else. The choice is easy to make:
If the project is Agile, the spec is not particularly useful—there are valid cases were I actually wrote a complete specification for an Agile project and it would have been a mistake of not doing it, but it's better to work without a spec than to have an ersatz of a spec constantly harming the project and the team.
If the project is not Agile (and superior to one man month), you absolutely want to have a decent spec, and you absolutely want to do it correctly.
Imagine you're building a house. In Agile world, you don't know yet what do you need exactly: you might need a pool in the backyard, but you're not sure. You might need a garage for two cars, but you're not sure if your wife will actually decide to buy the car she wanted. If construction were similar to software development, you could be taking (and changing) those decisions during the construction with only minor impact on the overall cost of your house.
In non-Agile world, you have to know everything in advance. If your wife buys a car once the garage is built, it would be extremely expensive to make the garage larger—very probably, you'd have to destroy the one which was built, and build another one. Now imagine that the house is built on the following spec:
Well, I want a house with... I don't know... five or six rooms, but I'm really not sure. Remember to make the bedroom large enough. There should be a garage as well. And a pool somewhere. Just don't forget, this is very important, I want the walls be painted in light blue, and please make a few large windows.
Will you get the house of your dreams based on a spec like this? I don't think so, and that's also why most customers don't get the products they want.
Once you understand that you need a real spec, the next thing to understand is that a spec should be written by a person who knows her job. This is not a simple writing task, but a task which also requires a lot of rigor, precision, thinking, understanding. To do this task correctly, formal approach helps a lot.
The mandatory formalism also means that one should clearly understand some aspects of:
Requirements elucidation—the task of (1) extracting the relevant requirements from the input given by the customer and the end users and (2) filtering the elements which are irrelevant to the project or should be made by experts: UX designers, security experts, analysts, etc.,
Requirements writing—the task of writing down the requirements in a format which makes them usable by the developers. The requirements need to be sorted, grouped, and formulated in a non-ambiguous way which makes no room for interpretation.
This second task is as, if not more important as requirements elucidation, and this task requires a clear understanding of the difference between functional and non-functional requirements. At this level, it is essential to understand that all requirements are objective, that all should be expressed in a way which makes it possible to write a test which either passes or fails.
Screwing at this level is a good way to fail the project.
This is why I'm so disappointed when I see on Programmers.SE answers such as:
They're functional, because you could write a simple function or read the documentation to test whether or not this was the case.
Non-functional requirements are inherently subjective, like, "Must be fast, must be user-friendly, etc."
Every requirement should be written in a way that it can be translated into a test. Something which is inherently subjective has nothing to do among the requirements.
The best way to check if the requirement is written correctly is to ask yourself:
Can I write a test which checks for this requirement?
If the answer is “No”, this is not a requirement.
Can I write a fail-pass test which checks for this requirement?
Some requirements are reluctant to fail-pass (red-green) TDD style tests. If too many requirements are in this case, this is a bad sign, but don't worry if some are.
Note that this is very different from unit tests. In unit tests, fail-pass should be possible for every test. In a case of functional and non-functional requirements, system tests of functional tests may be extremely complicated, which means that you will be able to implement a test which only passes, but can't make it fail deliberately easily enough.
May other persons interpret this requirement differently?
If yes, it is badly written. A correctly written requirement is not subject for interpretation.