It Doesn't Seem Like It Should Be This Hard
Sit down with the customer. Figure out what the customer wants the system to do. Use cool new software languages and tools that didn't even exist two years ago. Craft the application, using the latest languages and tools. Simulate and debug with efficiency and aplomb. Download the new client application remotely. Sit back and wait for awards to come in. Take the entire holiday off. Watch for that bonus check!
Reality Seems Entirely Different
However, for most of us, much of the time, reality seems entirely different. Our lives are dominated by late nights, changing requirements, fickle customers, serious software quality issues, significant project delays, technology that obsolesces before we deploy it for the first time, and missed commitments. In the best cases, our customers are thrilled and we are well rewarded. But even then it comes at a personal cost, and we know we could have done better. In the worst cases, we encounter canceled projects and complete frustration. Bring on the next project! Goodness gracious, we love this business!
Background
In Chapter 1, we summarize some of the ongoing challenges and problems associated with software development and the causes of project successes and failures. The chapter also provides a rationale for investing time and resources in doing a better job of managing application requirements. If you're a veteran software developer, a veteran project manager, or any other kind of software veteran with lots of scars from complex projects gone awry, you may be tempted to skip this discussion and turn directly to Chapter 2.
But if you are new to the industry or spend most of your time outside the software development department of your company ”if you're in the marketing department, perhaps, and you're charged with defining a new software product, or if you're in the quality assurance department chartered to acquire an ISO 9000 accreditation for the entire company, or if you're in a " user department" that needs to have information systems developed to support its activities ”you should read Chapter 1, as well as the rest of the book!
You are most likely aware that systems development projects tend to be difficult, expensive, risky, and prone to failure, but you may not know why this is a common situation in most organizations. Indeed, if you think that no other organization on Earth could be as screwed up as yours, you'll be relieved to discover, from the statistics in Chapter 1, that almost every organization suffers from the same kinds of problems. Knowing why these problems exist and where they tend to be the most severe and expensive is a crucial first step for improvement.
In Chapter 2, we introduce the concepts of requirements management that we'll be discussing throughout the remainder of the book. Even if you think you know what "requirement" means ”and after all, who doesn't? ” we urge you to read this material, for it provides some definitions and foundation-level assumptions that we depend on in subsequent chapters.
In Chapter 3, we present various software lifecycle models, both past and present, and discuss how these models relate to the overall problem of managing requirements during the development process.
Finally, in Chapter 4, we introduce the software team. The software team is part of the case study that will help us understand the challenges of requirements management as we work our way through the six team skills that follow.
This is not a book about teams, however, and the important topics of building high-performance teams , motivating them, and even managing them within the context of software development are outside the scope of this book. This is a book on managing software requirements, and to accomplish this challenge, we need the support of the entire software team. The reason is that, perhaps more than with any other specific software development activity, requirements management is a process that touches every team member, both in the core team and in the extended team of the customer and stakeholders. Indeed, it is a premise of this book that in all but the most trivial projects, effective requirements management can be applied only via an effective software team . Further, to achieve success, every member of the team must participate in the process, albeit in different ways, and each team member will need to be knowledgeable about his or her role in requirements management.
| Effective requirements management can be accomplished only via an effective software team. |
![Managing Software Requirements[c] A Use Case Approach](/icons/blank_book.jpg "Managing Software Requirements[c] A Use Case Approach"){kind=icon}