Ask yourself these questions. Have you ever produced software that met all of the product specs but none of the customer’s expectations? Have you ever had to guess what information developers need from you to understand what you want? Without formal, verifiable requirements and AN EFFECTIVE WAY TO MANAGE THEM the result is usually a gap between what developers think they are supposed to build and what customers think they are going to get. (Karl Wiegers, Software Requirements, 1999)
I was reading this paragraph and what struck me was the portion you see in bold in the previous paragraph. For years we have been beating the drum about quality requirements. Everyone wants training on how to write them, how to structure them, how to test them, how to elicit them, how to make sure they are clear, complete concise…. and on and on. I’ve delivered a lot of these courses over the years. Students in the class nod and take copious notes about methods for ensuring requirements are clear and concise. But as I continue to teach these classes I have to ask the question. If you don’t manage those requirements after they are written, aren’t we missing some of the benefits of good requirements?
I look back at the reports we see from groups like Standish and Gartner. We are still seeing that nearly half of all projects are late and over budget, and that these are almost always tied to some kind of requirements issue. Yes, it is very important to elicit and specify clear and concise requirements that accurately reflect the user’s needs and wants. But that is just the first step in the requirements engineering process. The real work and effort comes in managing these requirements as development continues. In my experience there are very few organizations that really manage requirements. There is little or no traceability in these organizations. After all these years of knowing the importance of requirements management, why is there so little of it going on?
If you are in an organization where requirements are managed, then you probably snicker at these comments. I worked on a very complex weapon control system for many years. During that time I thought we were so behind in our requirements work. Actually, we were light years ahead of most organizations. We had full traceability from user requirements to code, a change management process, requirements were constantly updated as change requests were reviewed. We were doing this manually for a while until our customer insisted we had to implement a requirements tool.
I often hear excuses for not managing requirements – our project is so small it doesn’t matter, we don’t have time for those activities, we don’t have a tool. I’m beginning to think the management of the requirements is even more critical to project success and that it is time to focus on the requirements management activities. Requirements management must be an essential part of any project, no matter the size.