Douglas Muir & Geoff Hewson, Software Productivity Center Inc.
Reprinted with permission from Software Productivity Center Inc.
Getting software requirements right is one of the toughest challenges in the IT industry. Harder still, is to keep on getting software requirements right project after project.
Software requirements are an intractable problem in industry. Much has been written by authors and experts on how to make them accurate and complete, and many tools have been offered as solutions. All valuable; however, many focus on Cinderella scenarios that validate the points being argued. Their application in the real world (no fairytales here!) comes up short. In the end, they’re less useful and just can’t do the job for us—our tasks are significantly more complex than those simplistic representations. They require a level of abstraction and analytical thinking that is just not obvious in the simpler view.
Why all the attention on software requirements? It’s consistently highlighted in study after study that having the right requirements is key to a successful project. That between 40% and 60% of software failures and defects are the result of poor software requirements definition and management is well known. That around 30% of features in custom software development are rarely or never used is less well known. In plain English, this means that lots of the problems we encounter could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. In other words, the developers did their job well—only they did a different job from what was needed.
Ineffective requirements practices not only deliver products that don’t meet business or customer expectations, it leads to frustration and mistrust amongst IT and business partners, and within the development organization itself, between business analysts and developers & testers. It’s time to step back and look at the process objectively, and more importantly, rethink how we get to the right requirements.
One key problem to address is that many not directly involved in requirements don’t adequately understand the purpose and intent of this activity. This often leads to a “don’t waste time on requirements” mentality. Whether you follow an Agile or a traditional development approach, making time for requirements is critically important. It takes time to fully grasp the needs of the customer. If you just build what the customer tells you first, likely the end product will be wrong and rework required. Time gives us the opportunity to have a disciplined approach (not bureaucratic) to getting the right requirements.
A frequent challenge in getting requirements that work is determining the level of detail required for the project. We know that less detail means less work up-front in the requirements phase—but is it less work in the long run? Ambiguity, the curse of good requirements, is a risk when there’s less detail. Let’s look at the flip-side of the argument; time spent on excessive requirements detail when its not needed is precious time wasted. We need to balance between the two, but too often we only consider the balance after the fact, when requirements turn out to contain mistakes, are unclear or poorly defined, or when the significant investments we’ve made in requirements seems questionable. Knowing when to go light and when to go deep on requirements is the hallmark of winning organizations. Flexibility of response gives us the agility our businesses need.
There’s a common theme that consistently runs through these and similar situations. As IT professionals, we’ve been trained to look for answers, to solve problems. And when we turn to educational resources, seminars, webinars, books, journal articles, etc., they too are quick to point to an answer. But, what if these quick-fix answers were actually part of the problem? What if the answer is actually knowing the right questions to ask? It sounds counter-intuitive—spend more time determining the questions to ask before looking for answers. But it works.
Think about it—when we get sick and go see the doctor, does this professional walk in with all the answers and a prescription in hand? No, they sit down with us and do a full diagnostic and balance the outcomes before coming to any conclusion. While we may never be in a life and death situation in our projects (though some late nights at the office can feel like it), we can learn a lot from the protocol these professionals follow. Ask, ask, and ask again … you’ll be in a powerful place to choose the right level of detail for your requirements projects when you balance flexibility against discipline in your approach to the situation.
Mastering the balance between discipline and agility needed in software requirements, and knowing when to apply just the ‘right amount’, becomes less challenging when you bring expert knowledge and relevant insights to bear on the situation.
SPC has really useful information on software requirements development and management practices. Visit our software requirements development and management section where you’ll find top tips, advice on how to get better at requirements, skills development courses, and a resource area with articles, white papers, and other recommended reading. With time and practice your projects will greatly benefit by having a solid requirements approach.