Book Review: Effective Requirements Practices

Ralph R. Young
Addison-Wesley, 2001.

ISBN 0201709120 (paper; with CD of some artefacts)

Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)

Other Reviews

See also Ralph Young's Requirements Engineering Handbook (2004)

Any book that has Effective in its title and Pragmatic in the cover blurb is likely to be stronger on established practices than on excitingly revolutionary techniques, and this one is no exception. Young treads the familiar ground of the Standish Group's reasons why projects fail, the need for requirements practices that work, the system engineering life-cycle, and a template-and-checklist approach to projects. Novelty and risk are specifically discouraged.

As it happens, copies of Young and of Jackson have arrived at the same time, and the comparison is interesting. Where Jackson looks at the conceptual picture, its theoretical weaknesses, and what should be done about it, Young looks at the specific (large) project, and the approaches most likely to succeed from those available now. Jackson wants you to become a better thinker; Young just wants you to do a better engineering job today. Something that they both agree on is that the waterfall model is inadequate: engineering development certainly does not follow a straight line path.

Trade-off Loops in the System Engineering Life-Cycle

The book is sensibly divided into chapters that directly reflect the ten recommended practices:

1. Commit to the approach.
2. Establish and utilize a Joint Team responsible for the requirements.
3. Define the real customer needs.
4. Use and continually improve a requirements process.
5. Iterate the system requirements and architecture repeatedly.
6. Use a mechanism to maintain project communication.
7. Select familiar methods and maintain a set of work products.
8. Perform requirements verification and validation.
9. Provide an effective mechanism to accommodate requirements changes.
10. Perform the development effort using known, familiar proven industry, organizational, and project best practices.

The final chapter is entitled 'How to Proceed' and contains a list of key issues, a five-page checklist for the requirements-related activities on your project, and tips on prioritization and the CMM.

Each practice is described in about twenty pages (twice that for defining the real customer needs - a wise emphasis on a crucial topic; techniques mentioned approvingly include workshops, use cases, and prototyping). Each chapter begins with a short summary. Then it introduces its key themes and defines its terms. Young is not afraid to draw on best practice, whether described by industrial colleagues or in market or academic research. For example, on Joint Teams he quotes Telelogic's Writing Better Requirements course approvingly, borrowing the illustration of Customer and Supplier Roles Throughout the System Life Cycle - a diagram that makes clear that requirements are not something that happens at the start of a project and then disappear. The chapter ends with a 200-word summary and a couple of pages of key references and suggested readings. Each book mentioned is described in a paragraph of descriptive praise, giving the reader a clear idea of what they would get if they purchased and read it.

This is a book "dedicated to the systems and software engineering professionals who have devoted their life's work to serving others" - a daunting sentiment. Young braves a blizzard of acronyms to guide the reader in a plain and readable style through CMM and MOEs and TQM, though his rendering of SWAT Team as 'strategic weapons attack team' is perhaps a little too close to Armageddon: Special Weapons and Tactics (police) Team may be what was intended. Young is always clear and practical, and provides plenty of supporting evidence for claims and suggested approaches.

The book has up-to-date lists of tool vendors, good books on each of the ten practices, and efficient indexes. It is solidly aimed at decision-making practitioners, and given the stress on systems engineering this means both project managers and chief engineers on large system projects. As the author says,

It is my sincere hope that one use of this book will be to provide practitioners [with] the experience and data to encourage P[roject] M[anager]s to provide adequate funding for requirements-related activities... This is obviously an issue that needs to be addressed in corporate and organizational training programs for PMs.

Amen to that, though there is only so much experience one can gain from reading books.

Such people will find this book plain, practical, and useful, and they may well benefit from the simple artefacts on the supplied CD. Students of software engineering may find the book too industrial, and they certainly won't find details of the latest and most exotic techniques here. Students of systems engineering will find it a worthwhile and systematic overview, though without exercises. In summary, this is a solid guide to the requirements aspects of systems engineering.

© Ian Alexander 2001