According to the Standish Group’s Chaos Report (2001) more than 70% of software projects fail. In addition to this overall statistic, the report lists the most frequent reasons projects fail. Similar studies were conducted by the International Council of Systems Engineers (2000) and the IT consulting firm Keane (Munson, 2002) with startlingly similar results. All three studies focus project failure on requirements. The top three reasons for project failure follow.
- incomplete requirements
- lack of customer involvement in defining requirements
- poor management of changing requirements
The Problem with Requirements
While there are several reasons these studies point the finger at requirements, the problem may actually stem from the way humans learn and think. To explain my point, imagine you have never been to nor seen any pictures of China, and are asked to provide a description of the place to an artist who wishes to draw a picture of the Chinese people and their country. Would you be capable of describing China? Perhaps you could discuss China at a high level, based on information you had read or heard, but you would find it impossible to accurately provide the details the artist needs.
Requirements are quite similar. We ask people all the time to define requirements for software that they have never seen, touched, or experienced before. To develop software, requirements must have a level of detail similar to what an artist needs to draw.
This leads us to Requirements Myth #1:
Requirements Myth #1 – “The customer knows the requirements.”
A customer doesn’t know what he wants until he has experience with the software. He may be able to provide some high-level requirements, but will surely fall short when asked for the details. Its no wonder so many projects fall short on requirements. Steve McConnell wrestled with this issue in his work Software Project Survival Guide, when he wrote, “The most difficult part of requirements gathering is . . . the exploratory, developmental activity of helping users figure out what they want.” (1998) In addition to not knowing the specifics, there are other problems with requirements. Going back to the China example, even if you had seen pictures of China, you still would struggle with providing the details on paper. Translating something abstract like the abundant colors and fast-pace of an urban Chinese market is difficult even for the most experienced writer. So, Requirements Myth #2 is:
Requirements Myth #2 – “The customer can easily capture the requirements.”
Requirements are often very abstract. If you attempted to describe the look and feel of a new piece of software, having never before seen it, you would find it frustrating describing the requirements in the necessary detail.
We as humans struggle with details. One example of this struggle is a fact stated repeatedly by police detectives investigating crime. Investigators say that one of the biggest problems eyewitnesses to a crime have is recalling specific details. We aren’t programmed to recall the specifics. Gathering the specific details for requirements is no different.
Types of Requirements
The degree of difficulty customers have in identifying and capturing requirements is dependent on the type of requirements they are working with.
There are three basic types of requirements that the customer is asked to specify: business requirements, user requirements, and functional requirements (Wiegers, 1999). Business requirements describe the underlying business problem in need of software. This type of requirement poses little problem for the average customer. They understand the problem because they are experiencing it themselves. Business requirements are usually captured at a high level, thus they don’t have the details customers consistently struggle with.
User requirements are more detailed and abstract than business requirements, but usually can be captured by the customer. User requirements focus on the tasks the customer would like to perform with software. With some thought and a lot of patience, these requirements can be documented to the required detail. This isn’t to suggest that user requirements are easy to gather, but the tasks and processes defined in the user requirements are available if the customer is willing to spend the time identifying and collecting them.
It is really the functional requirements that cause the most problems for customers. Functional requirements are the solution to the business problem from a customer perspective. They define the software that will be created to meet the customer’s needs. Unlike the user requirements, the functional requirements are very often new. That is, they aren’t available for the simple gathering because the solution is a new one even if the problem is the same. Functional requirements must be defined in excruciating detail so that they can be passed on to the development staff for designed. Holes in the functional requirements will be filled by the creative minds of the developers. It is these holes or more often than not, these craters in the functional requirements that create the disconnection between the needs of the customer and the good-intentioned ideas of the development staff.
Our discussion to this point doesn’t suggest that functional requirements are impossible to obtain, and certainly doesn’t infer that they should be avoided. Functional requirements must be gathered, and they must be gathered in great detail. A little change in thinking is what is needed to mitigate the requirements problem.
Looking Back
To change our thinking we must look back at the way software projects have been managed for the last 40 years. More than 80% of software projects use some form of the Waterfall Methodology. The Waterfall Method is a sequential process that a project team goes through to develop a software product. The process begins with defining requirements and proceeds through design, development, and ultimately to delivery of the software. While this approach is very methodical and easy to manage, it magnifies the inherent problems with requirements and disregards the way that we learn.
- The first problem with the Waterfall Method is that it mandates all requirements be defined at the beginning of the effort. While this may seem like a sensible request, we often find ourselves describing China without any experience, pictures, or words. This is, in essence, a form of the chicken and the egg mantra—how can you describe something that’s never been built, and how can you build something you can’t describe (McConnell, 1996, pp. 137)?
- Another important drawback of the Waterfall Method is its inability to adapt to change. This problem provides the chance to introduce you to Natural Law of Software # 1.
Natural Law of Software # 1– “In successful software, the requirements are constantly changing.”
If during development, a new feature is identified, the team has only two choices with the Waterfall Method—start the process over or push the feature to the next release. While this may be a good idea in some settings, building innovative products requires more room for change (McConnell, 1996, pp. 138).
- The third problem with the Waterfall Method is that the product is delivered at the end of the project. As explained earlier, customers learn requirements through experience. With the Waterfall Method customers don’t see and use the software until it’s too late.
A New Method
New methods of managing projects have been developed to counteract the inherent requirements weaknesses of the Waterfall Method. These methods are grouped under the heading Agile Methodologies. Agile Methods operate under a very different set of principles than the Waterfall Method. With the Agile Method, a project begins the effort with a set of requirements that encompass “What we know today.” The software continues through the standard stages of design, development, and delivery, but when the software is delivered, it becomes the input to a whole new iteration of the same process. This circular process continues until the software meets the customer’s needs.
While on the surface, such an approach seems redundant and even lengthier than the Waterfall Method, in reality it is faster. Many of the advantages of this approach are directly related to the way it manages requirements.
- The first advantage of the Agile Method is that it doesn’t mandate we know all the requirements at the start. We aren’t being asked to describe China without the necessary experience. Instead, we begin a journey to that end. Because of the quickness of the iterations, we rapidly gain the necessary experience to determine all the requirements.
- The second important benefit is how the Agile Method adapts to change. Because the stage for defining requirements (Define) occurs with every iteration, new requirements can be quickly gathered and applied. The faster the iterations, the better the project’s ability to adapt to a changing landscape.
- The third improvement over the Waterfall Method is how quickly the team sees results. It typically only takes a few iterations and the team and customer begin to catch a glimpse at what the software will look like, how it will interact with the customer, and how it will perform. This knowledge provides the customer the experience to identify course corrections and additional features and functions that will make the software useful and effective. Over time, the requirements and the software evolve as experience is accrued, and the software is developed. The picture of China will gain the necessary details the artist requires.
The Agile Method is not perfect. Many find it harder to manage and more chaotic than the Waterfall Method. In an environment where structure and discipline are lacking, the Agile Method requires meticulous management of iterations and changing requirements. This detailed managed is required because of the second natural law.
Natural Law of Software # 2 – “Successful software is never complete.”
Conclusion
While software failure is a consistent problem today, solutions like the Agile Method exist to turn the tide. To make this substantial change we must recognize our misconceptions about how requirements are identified and captured as exposed in the discussed myths and natural laws of software. As we take what is known about human nature and learning and apply it to better methods and approaches to gathering and managing requirements, we are sure to see the trend turn to more software project success in the future.
References
International Council of Systems Engineers. 2000 Report
McConnell, Steve (1996). Rapid Development (pp. 137 - 138). Microsoft Press
McConnell, Steve (1998). Software Project Survival Guide (pp. 117). Microsoft Press
Munson, Bill (2002). Keane, LTD, UK
The Standish Group International, Inc. CHAOS Research. 2001
Wiegers, Karl E. (1999). Software Requirements (pp. 7 – 8). Microsoft Press
