Are Requirements Required?
Are requirements required? Steve McConnell discusses a Barry Boehm study that shows that requirement defects found in the field are 50-200 times as expensive to fix then if the defect was fixed during requirements definition. So the answer is yes - requirements are required unless you want to pay a lot more money then necessary to build your software. The one exception may be if you are writing some small piece of software only for yourself, but even then it is still probably a good idea to at least scribble a few notes about requirements.
Lately, I have been discussing requirements with various developers and I’m amazed at the number of developers that say that get no or poorly written requirements. What’s happening? Why don’t the requirements get properly written?
I have heard and personally experienced many excuses about why requirements are unwritten or poorly written. Here are the major excuses:
- No time. We didn’t have time to write requirements.
- No clarity. We couldn’t make up our mind about what to build.
- No usefulness. We tried writing requirements and they weren’t very useful.
- No reviews. We wrote requirements but we couldn’t get any users to review them.
- Hungry dog. My dog ate the requirements.
Except for the fifth excuse, I will dispute and make suggestions for overcoming each excuse.
No Time
This is the most common excuse. I once worked on a product that helps insurance agents create insurance proposals. The company was small and the president of the company was “visionary”. The problem for the product was that his “vision” changed every day and sometimes several times per day. He refused to write down any requirements because there was “no time”. We needed to “get the product out”. Of course, there was no way to complete the product because nobody could define what the product was. I left the project before it was completed because I found the situation hopeless. I don’t know if they ever finished it or not.
Saying that you have no time to write requirements is like saying you don’t have time to create blueprints for a house before you starting building it. How many rooms? How many square feet? How many bathrooms? Can you imagine starting the construction of a house without a basic blueprint? I can’t.
If you find yourself in this situation, try getting commitment from management to at least create a mini-requirements specification of a few pages. Reviewing the mini-requirements specification may make management realize that something more complete needs to be written.
No Clarity
We couldn’t clarify what to build so we didn’t write requirements. I once worked on a 401K management system. The project suffered from “analysis paralysis”. We documented requirements religiously, but we never actually started any real development because requirements were never complete. One year and $3 million later, the project was cancelled. A wise friend on the project said “If you don’t see any signs of a visible system after 3 months, investigate the project. If you don’t see any signs of a visible system after 6 months, cancel the project because the team will never produce anything.” I agree and, in fact, the timeframes should probably be even shorter.
If you find yourself in this situation, then try a more agile methodology like Scrum. Define some small set of requirements, implement the requirements, test the implementation, and then start again. Another possibility is to create a prototype to clarify requirements.
No Usefulness
We created the requirements, but they were not useful. I once worked on a Cable Monitoring system. We were working with an Indian outsourcing firm that was CMM level 5. Like all good CMM level 5 organizations, they had a really long requirements template that all projects should use. Unfortunately, most of the sections were not relevant to our project and could be filled in with boilerplate or pro-forma information. This made the document really long and it looked good but it actually contained very little useful information.
Let’s go back to the house blueprint analogy. What if I created a blueprint that consisted of the square footage of the house, the color of the carpet, and the brand of windows to install? It contained no information about room configuration and window and door placement. Would you build the house? I wouldn’t.
If you find yourself in this situation, sit down, identify the most important aspects of requirements to capture, and then create a document template that captures those aspects. After you fill in the template, you will have pretty good requirements.
No Reviews
We wrote the requirements, but we couldn’t get the right people to review the requirements. I worked on a Shop Floor Control system once. (The advantage of being an old timer like me is that you worked on everything at least once.) We created requirements documents that were over 100 pages long and really boring. We used to have a single, all day long, requirements review meeting. After the first couple of hours, I watched the product manager’s eyes glaze over. Participants started finding good excuses (like my pen ran out of ink, my car needs an oil change, or my glasses are dirty) to leave the room. Sometimes a participant never came back.
If you were build a house and created a very detailed blueprint that you never showed to the owners of the house, would you build the house? I wouldn’t.
There are a couple of several ways to resolve this problem. First, you can create a prototype to show users and other stakeholders. They generally like looking at prototypes a lot more than they like looking at requirements. You can then focus on things that aren’t part of the prototype in the requirements specification. Second, create a small portion of the requirements specification, review that small portion, and then move on to the next portion. Third, try to make the requirements specification a little amusing. Throw in a few small jokes. This is an idea from Joel Spolsky and I think it is good.
