Chapter 9. Navigating the Requirements Management Process


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:

  • Lack of user input: 13% of all projects

  • Incomplete requirements and specifications: 12% of all projects

  • Changing requirements and specifications: 12% of all projects

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]

[1] From Managing Software Requirements: A Unified Approach by Dean Leffingwell and Don Widrig. Reused with permission.

[2] From Facts and Fallacies of Software Engineering by Robert L. Glass. Reused with permission.

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.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net