Project Requirements: A Guide to Best Practice: A Guide to Best Practices [Hardcover]

A book search on "requirements" gets 10,000 hits; "project management" gets 3,000 more. So why this one? I used Young's previous requirements books - Effective Requirements Practices (what to do) and Requirements Engineering Handbook (how to do it) - to good effect earlier in my career as a software developer, so I was interested to see what he has to offer me now in my role as a Project Manager. I was pleased to find this book gives practical, actionable guidance across the spectrum of things a PM must worry about (mostly requirements related, but even a bit beyond) in a complete yet concise way. A key "take-away" from the book is steps to mitigate my two biggest requirements issues: having the REAL requirements identified early on, and maintaining control on requirements changes/additions during the life of my projects.

Compared against the Robertsons' popular "Requirements-Led Project Management," I found this book easier to read & to apply - with specific stuff you can use directly, things like a requirements-related project start-up checklist, requirements products to plan for, and a skills matrix to help you select (or grow) competent requirements manager/analysts for your project. This book manages to cover the waterfront while remaining concise (200 pp plus appendices). Wieger's "Software Requirements" is a classic reference, for example, but it's 500 pages that I don't have time to wade through; the best of Wieger's PM stuff is included here in an appendix. I particularly like the way key ideas are set off in boldface with distinctive dividers - you can get the jist of the book just by flipping pages and reading the callouts, and it helps when you go back to look for something, too.

Like Young's ERP & REH books, this one includes a couple of sections and many sidebars contributed by other luminaries, from both the US and the UK. Appendix A is Palmer's excellent paper on how to do Traceability; Appendix B is a humorous and compelling piece by Neal Whitten on "minimum requirements." Some of the best practices take a broad view of what is related to "requirements" -- the chapter on the PM's role in Quality by Dan Baker provides the best succinct description I've read of what "quality" should be on a project and how QA can make a real contribution; Stephen Waddell adds a terrific summation of Risk Management best practices in a chapter on Requirements and Risk.

The included Index isn't as comprehensive as I'd like, but the very thorough Table of Contents makes up for that somewhat -- and there's a very extensive list of references and links. In addition to the topics mentioned above, there are chapters on Key Requirements Success Factors, Partnering, Teamwork, Coaching, Communication, Process Discipline vs. Agility, Continuous Improvement, and Suggested Implementation Steps.

All in all, this is a very pithy, self-contained book to increase your effectiveness as PM and improve the management of your project. If you have the time (you must not be a PM :-), there are lots of other good, specific requirements books. If you're busy, spending just a little time with this one helps to ensure you're doing the things that are known to foster project success.

Our advances in hardware and software technology have not helped us write better software specifications. A recent popular comic strip shows a software engineer asking the customer about what he wants to accomplish with the software. The customer states that he does not know what he wants to accomplish because he does not know what the software can do. The engineer then explains that she can design the software to do whatever he wants, but first she needs to know his requirements. The frustrated customer finally asks the engineer if she can design the software to tell what his requirements are. In my opinion requirements elicitation on many projects has not matured much farther than the level of this comic.

The buzzword for systems development in today's competitive environment is "Faster, Better, and Cheaper." Yet many software projects struggle just to complete development period, forget completing "Faster, Better, and Cheaper." Well-known failures such as the FBI's Virtual Case File (VCF) make the news while many more failures go unreported. The VCF failure was due to several factors including scope creep and ill-defined requirements. The sad truth is that no software project is ever completed "Faster, Better, and Cheaper" with significant scope creep and ill-defined requirements. In fact, Capers Jones (CrossTalk, June 2006, Social and Technical Reasons for Software Project Failure) lists new and changing requirements during development as one of the five root causes of software project failure.

The problem is not a lack of technology. The problem is not a shortage of qualified people. The problem certainly is not a lack of software development methodologies to follow. We have an abundance of all three. The problem is a lack of leadership in the basics of project management. Leadership on basic issues is what Dr. Ralph Young's latest book (Project Requirements, A Guide to Best Practices, Management Concepts, 2006) is all about. Dr. Young has hit the trifecta with his latest book. His first two books focused on "what" to do (Effective Requirements Practices, Addison-Wesley, 2001) and "how" to do it (Requirements Engineering Handbook, Artech House, 2004). In this book, he describes the basic project management practices needed to prepare the ground for performing the tasks described in the first two books. However, why stress requirements in a book aimed at the project manager? The answer is simple: requirements underlie every other process of the software project. You have to get your requirements right. If you don't, what hope do you have of ever creating a product that meets the customers' needs, let alone creating it "Better, Faster, and Cheaper?"

A quick review of the Table of Contents in Project Requirements shows that the book is not for those who want to learn about the latest fad, or what tools to use, or even how to write a requirement. This book is for those who want to build a sound foundation for their software project to rest on. The real strength of this book lies in how easily it integrates requirements tasks with the Software Quality Engineer Body of Knowledge. The first two chapters focus on prevention of requirements errors early in the life cycle, before they become software errors. [I.A.2 - Prevention vs. Detection]. Chapters three through five address the all-important aspects of leadership, team building, and partnering. [I.C.2-4 - Team Management, Team tools, and Facilitation skills] There are chapters for improving project communications [I.C.5 - Communications Skills], coaching team members in sound requirements practices [I.C.1 - Organizational leadership] and setting goals and objectives [II.A - Goals and Objectives].

The book contains chapter after chapter of good solid advice, based on Dr. Young's real-world experience. However, parts of the book contain exceptional advice. The section on using a QA audit, not as a reporting tool but as a coaching tool, is a good example [II.C.1-3 - Program Development and Administration, Audit preparation and execution, and Audit reporting and follow-up]. The section on risk management [IV.C.1-2 - Risk Management planning methods and Risk probability] is another area that needs more attention in requirements management. We often treat requirements as being equal to each other. Although this approach makes measuring progress easier, requirements are not all created equal. Each requirement has a different potential cost, schedule, and technical risk impact to a project. The biggest risk a project can have is not recognizing this fact. Dr. Young provides a sound systematic approach to integrating risk management with requirements management and mitigating this often-overlooked problem.

I recommend this book to anyone who is interested in how project management basics apply to requirements management. To ignore the basics Dr. Young covers in his book is to make the same mistake that many projects make, but do not easily recover from. To ignore these basics is the best way to see your project cancelled, written up in the newspaper, and maybe even portrayed in a comic strip.

Ralph has done a wonderful job describing the criticality of clear requirements as well as the reality that they never will really be clear. I found this book pragmatic and thorough. It triggered some new ideas for managing complexity and provided me with new tools and techniques to be more resilient. Thanks, Ralph!

› Go to Amazon.com to see all 4 reviews  5.0 out of 5 stars