Kurzbeschreibung
Synopsis
Buchrückseite
"A comprehensive solution to the requirements challenges faced by every development team. Full of insight and ideas all developers can learn from." --Ivar Jacobson
"Many projects fail for the simple reason that the developers fail to build the right thing: They either deliver a system that does not meet the expectations of its intended users, or they deliver a system that focuses on secondary functions at the expense of its primary use. Drawing on their extensive experience, Dean and Don demonstrate how to employ an industrial-strength requirements process, one that helps ensure you will build the right thing. Developers of any kind of application should read this book." --Grady Booch
Despite the wealth of development knowledge, experience, and tools generally available today, a substantial percentage of software projects continue to fail, often because requirements are not correctly determined and defined at the outset, or are not managed correctly as the project unfolds. Clients do not always know or express their needs precisely, and too often designers and developers do not ask the right questions at the right times. As a result, projects often spin out of control as "feature bloat" and shifting priorities cause budgets and schedules to exceed expectations. Managing Software Requirements focuses on this critical cause of failure and offers a practical, proven approach to building systems that meet customers' needs--on time and within budget.
The authors are skilled practitioners who have spent their careers in the trenches building high-quality applications, including safety-critical, real-time systems. Using an informal, approachable style, their own war stories, and a comprehensive case study they show how designers and developers can effectively identify requirements by employing the power of use cases and more traditional forms of requirements expression. The book illustrates proven techniques for determining, implementing, verifying, and validating requirements. It describes six vital Team Skills for managing requirements throughout the lifecycle of a project: Analyzing the Problem, Understanding User Needs, Defining the System, Managing Scope, Refining the System Definition, and Building the Right System. Managing Software Requirements specifically addresses the ongoing challenge of managing change and describes a process for assuring that project scope is successfully defined and agreed upon by all stakeholders.
Topics covered include:
- The five steps in problem analysis
- Business modeling and system engineering
- Techniques for eliciting requirements from clients, users, developers, and other stakeholders
- Applying and refining use cases
- Prototyping
- Organizing and managing requirements information
- Establishing project scope and managing customers
- Using both informal and technical methods for specifying requirements
- How to measure and improve the quality of your product's requirements
- Moving from requirements to implementation
- Verifying and validating the system
- Managing change
The book concludes with a step-by-step guide to incorporating these powerful techniques into future projects.
0201615932B04062001
Über den Autor
Prolog. Abdruck erfolgt mit freundlicher Genehmigung der Rechteinhaber. Alle Rechte vorbehalten.
Context and Acknowledgments
The knowledge delivered in this book represents the cumulative experience of a number of individuals who have spent their careers defining, developing, and delivering world-class software systems. This book is not an academic treatment of requirements management. During the 1980s, Don Widrig and I were executives in a small company producing software solutions for customers. When we developed many of the requirements management practices described in this book, our perspective was of those accountable for both the outcomes of the software systems we developed and the results that had to be delivered to shareholders. As the performance of the delivered software was critical to the success of the business venture itself, we tended to discourage petty biases, personal preferences, and experimentation with unproven techniques.
Over the past decade, the techniques have evolved and have been enhanced by new experiences, extended with the help of additional expertise, in different companies and in different circumstances. But all of the techniques presented are "real-world" proven and have withstood the test of time. Perhaps even more important, they have withstood the technological change that has occurred in the industry during this period. Indeed, most of the principles in this book are independent of changing trends in software technology. We can therefore at least hope that the knowledge expressed herein can deliver some lasting value.
Requirements Lessons from Building Software for Others
At first, I just hated computers. ("What? I stayed here all night and I have to submit this batch job again because I left out a 'space'? Are you crazy? Let me in that room....") My first "real computer" was a minicomputer, which, although incredibly limited in performance by today's standards, was unique in that I could touch it, program it, and make it do what I wanted. It was mine.
My early research applied the computer to analyze physiological signals from the human body, primarily EKGs, and the dedicated computer was a wonderful tool for this job. Out of this experience, I began to apply my programming skills and experience with real time software systems to the needs of the industry.
Eventually, I incorporated RELA, Inc., and began a long, and perhaps unusually difficult, career as CEO of a contract software development business. My coauthor, Don Widrig, joined me at RELA in the early years as Vice President of Research and Development. He had the primary accountability for the success of the many systems that we developed.
Over the years, the company grew rapidly. Today, the company employs many hundreds of people and has diversified beyond providing just software to providing complete medical devices and systems that encompass software, as well as mechanical, electronic, optical, and fluidics-handling subsystems. However, at the heart of each and every machine, including the latest DNA fingerprinting in vitro diagnostic clinical laboratory, lies one or more computers, reliably and routinely delivering its steady heartbeat through the rhythm of a real-time multitasking system.
Initially, we would program anything for anybody, from antenna positioning software to such games as laser tag, automated guided vehicles for amusement parks, educational products, welding robots, and automated machine controls. We even developed a large distributed computer system that auto-matically detected and counted the presence of commercials on television. (Our motto then was "We make computers to watch commercials so you don't have to!") Perhaps the only thing the software we developed was that we developed it for others--we were not domain experts in the field, and we couldn't cover our own paychecks if we had to. We were completely dependent on the cus-tomer's satisfaction as the final determination of outcome. In many ways, such an environment was very conducive to effective requirements management. Here's why:
- We knew little about the domain, so we were dependent on customers for the requirements. There was little temptation to simply make them up; we had to ask, and we had to learn how to ask the right questions the right way, at the right time.
- Our customers often knew little about computers, so they were dependent on us to translate their needs and wishes into technical requirements.
- The fact that money changed hands created a rigorous interface between the developer and the customer.
- Quality was easy to measure: We either got paid or didn't.
It was in this environment that we discovered the first of two fundamental questions that face software developers on each and every project. This question dominated our behavior for many years and remains today as perhaps the toughest question to answer in any software project. And the Big Question is:
Big Question 1: "Exactly what is this software supposed to do?"
The principles and techniques presented in Team Skill 1, Analyzing, the Problem; Team Skill 2, Understanding User Needs; and Team Skill 3, Defining the System, were developed over more than a decade as a means to discover the answer to this question. Each of these techniques has proved its worth and has demonstrated its effectiveness in many real-world projects. It was also during this period that I first became aware of the work of Donald Gause, and Jerry Weinberg especially their book Exploring Requirements: Quality Before Design, (1989). Because their book heavily influenced our work, we have borrowed a few key concepts from it for this book, both because the concepts work and because we thought it only fair that you share the Gause and Weinberg experience.
Lessons from Building High Assurance Systems
Over time, RELA began to specialize in the development of various types of computer-based medical devices and systems: portable ventilators (breathing machines), infusion pumps, pacemaker programmers, clinical diagnostic systems, blood pumps, patient-monitoring equipment, and a plethora of other diagnostic and therapeutic devices.
It was early during the ventilator development project that the ultimate accountability for what we were doing really hit us: Whoa, if we screw this up, somebody could die! Our primary concern was for the patient and for the family of the patient who was tethered to the device, a device on which we were executing some of the earliest, most time-critical, resource-limited software the world had yet seen. (Imagine the challenge of alpha and beta testing. You go first!)
Clearly, this high-stakes endeavor caused us to take software very seriously at a fairly early time in the evolution of the embedded-systems industry. It became clear very quickly that sustainable success would require a combination of
- A pragmatic process for defining and managing the requirements for the software
- A solid methodology for the design and development of software
- The application of various proven, innovative, techniques for verifying and validating that the software was safe and effective, and
- Extraordinary skills and commitment on the part of both the software development and software quality assurance teams.
I strongly believed at that time, and I am even more convinced today, that all of those elements are required to deliver any reasonably reliable software system of any significant scope. At RELA, Inc., this was to be the only way we could possibly ensure each patient's safety, the very survival of our company, and the economic futures of the employees and their families who depended on the company.
Given our earlier success in the development and application of the various techniques...
