Managing Software Requirements[c] A Use Case Approach
Hereafter, however, the game changes dramatically as the team size increases significantly. Each of these additional team members must participate in a coordinated team effort, and everyone must communicate effectively with one another. In addition, the investment, or "burn rate," of the project increases dramatically. We create test plans, build design models, refine requirements, elaborate the use cases, develop the code, and create momentum and a larger body of work that must be changed if the definition is not well understood or if the external requirements environment changes. The requirements pyramid, by its very shape ”wider at the bottom ”correctly suggests that much more work is ahead of us. The team skill discussed in this section of the book develops a strategy for a most crucial activity: scope management. According to the Standish Group [1994] data, " 53% of the projects will cost 189% of estimates ." Data from our own experience is even worse : Almost all software projects will be late by a factor of 50% to 100%. Assuming that the other root causes in software development will not be solved overnight, it seems clear that our industry is either incompetent or trying to do too much with too few resources, skills, and tools. We are trying to stuff ten pounds of desired functionality into a five- pound bag. Although the physics of software development are not clear, it should be obvious that this element of our strategy is heading for trouble and that the quality of both our work products and our reputation is about to suffer. So, before we increase the team size, before we develop the more detailed specifications, before we commit our technology ideas to designs, and before we build the test scripts, we must pause and learn how to manage the scope of the project . Part psychology, part technology, and part just good project management, mastery of this team skill will dramatically improve the probability of a successful project.
|