"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 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 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 * 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.
This is THE book on managing requirements in Unified Process.This is certainly not the book of choice about how to manage requirements as a business analyst, for instance. However, this text presents a very broad range of tools and practices in this field. It's even probably the most comprehensive one that I know. Of course each topic can't be handled in depth, but each one is pretty well presented and it's abious that the author master his subject very well. It would be not my book of choice on requirements management, but it's a very good introduction to each and every practice. The reading is relevant even outside the context of Unified Process.
Lefingwell describes requirements analysis and specification in great detail in this book. He tackles the process of understanding the problem, stakeholders, and coming up with a solution in a step by step guide (more or less), while addressing some of the common issues of eliciting and specifying requirements.
The author did tackle the issue of choosing the correct requirement methodology, and he did address the agile method. However, I do not believe that they were given justice. The book spends most of its chapters explaining the steps to produce an SRS document but this does not reflect most of the current industry standards, as most of them follow one of the agile methodologies and have left the traditional methods behind.
In the end, I would recommend this book to someone who is new to the software engineering field. But I don't think it holds a lot of information for a veteran.
The was one textbook I actually read completely in college. It was absolutely terrible. Its points were obvious. Its case study was imaginary so it wasn't really a case study. This is a poor model for a textbook.