The importance of proper requirements management has been discussed repeatedly for years. Traditional engineering disciplines, such as civil engineering, learned the importance of requirements management very early. Failure to properly define and analyze the requirements for a building can result in having to tear down and rebuild walls or, worse yet, risk the collapse of a building, resulting in lost time and materials, and even loss of life. It is obvious that if the requirements for a building's foundation are not adequately determined, the cost of rework is extremely high. For various reasons, this has only recently been recognized in the software industry. Because software can easily be changed, it is often assumed that requirements can easily be changed and are not as important as in the more traditional engineering disciplines. Fortunately, this perception is changing. The conventional Waterfall lifecycle model of software development places great emphasis on creating requirements documents that must be frozen prior to design and implementation. Modern lifecycle processes such as the RUP recognize that requirements cannot be completely frozen and emphasize the importance of working directly with stakeholders to uncover a system's true requirements. In the book Managing Software Requirements, authors Leffingwell and Widrig quote a Standish Group survey listing the three most commonly cited factors that cause projects to be challenged:
In addition, Leffingwell and Widrig state, "Requirements errors are likely to be the most expensive errors to fix."[1] Robert L. Glass, author of Facts and Fallacies of Software Engineering, confirms that "Requirements errors are the most expensive to fix during production" and "Missing requirements are the hardest requirements errors to correct." Finally, Glass states, "One of the two most common causes of runaway projects is unstable requirements."[2]
It is important to properly elicit, manage, and track requirements. But it is less obvious how to understand the circumstances that can ultimately lead to these failures and how to avoid them. This can be difficult when the stakeholders belong to an entirely different organization than the group performing the software development. This is the situation you are in when managing an outsourced project. This chapter discusses how to identify stakeholders. It also identifies and discusses the attributes common to a successful requirements management effort. It explains the added challenges offshore projects face. Finally, it covers the consequences of failure in the requirements management process. |