Niwot Ridge Resources

A Source of Information for Mission Critical Systems, Management Processes, and Strategies

Publications

Requirements Engineering

This is an area of intense research and activity. It is also an area that I actually know something about in detail. The problem in the requirements gathering business, is to determine the success criteria for the project, before (or at least while) the requirements are being defined. This means determining who actually holds the requirements, it may not be the people you're talking to.

Many times the requirements gathering process will discover requirements that appear to be vital to the project, when in fact they are irrelevant. The result, at best, is a perfect solution to the wrong problem and at worst is a complete disaster.

This is called a type 3 statistical error. Here are some resources I use for keeping my clients focused on the requirements issues. The concept behind these Type 3 errors can be found in Smart Thinks for Crazy Times: The Art of Solving the Right Problems, Ian Mitroff, Berrett–Koehler, 1997.

Requirements by Collaboration: Workshops for Defining Needs, Ellen Gottesdiener, Addison Wesley, 2002
Requirements Engineering and Rapid Development, Ian Graham, Addison Wesley, 1998.
Customer-Centered Products: Creating successful products through smart Requirements Management, Ivy Hooks and Kristin Farry, Amacom, 2001.
Software Requirements, Karl Eugene Wiegers, Microsoft Press, 1999. This is one of those must read books, along with all the others on this list.
Managing Software Requirements: A Unified Approach, Dean Leffingwell and Don Widrig, Addison Wesley, 1999. Any book with "Unified" in the title is likely to been seen as part of the Rational Unified Process (RUP). Since RUP is now the whipping boy for XP and Agile processes, this may turn of some readers. This book presents a traditional approach to software requirements elicitation and management. Following the processes laid out here can provide good guidance as well as keep you out of trouble. In the end experience, common sense (which is not all that common thee days), and some luck are also required.
Managing Software Requirements: A Unified Approach, Dean Leffingwell and Don Widrig, Addison Wesley, 2001. This book discussed the causes of "the failure of requirements elicitation," and provides guidance to avoid these causes
"Issues in Requirements Elicitation," CMU/SEI-92-TR-012, Software Engineering Institute. This is a very useful set of guidelines for capturing requirements in the software domain. It can be adapted for other domains as well. There are many other requirements resources at the SEI, which should be read by anyone calling themselves a requirements engineer. See Software Engineering Institute for the starting point.
"Four Dark Corners of Requirements Engineering," Pamela Zave and Michael Jackson, ACM Transactions on Software Engineering and Methodology, 6(1), January 1997, pp. 1–30.
Software Requirements: Analysis & Specification, Alan Davis, Prentice Hall. This is good text book for traditional requirements gathering processes. Although it is software centric it provides a good foundation for many other disciplines.
Software Requirements & Specifications, Michael Jackson, Addison Wesley. This is a "practice" book, with many good concepts. It is object oriented before objects became the vogue, so some of the examples appear dated.
Requirements Engineering: A Good Practice Guide, Ian Sommerville, John Wiley & Sons. This is a true practitioners guide to requirements gathering for ANY computer based discipline. It is more general purpose than the title suggests, and can be used in other disciplines.
The Art of Systems Architecture, Eberhardt Rechtin, CRC Press. This is a pure "architecture" and "systems engineering" book about aerospace products. Rechtin has written several other books, but they're a bit dated. This book should be read and reread, since the ideas are universal.
Software Projects: Evolutionary vs. Big Bang, Felix Redmill, John Wiley & Sons. This is a good (and easy) book for sorting out the project method issues.
Software Requirements Engineering, 2nd Edition, IEEE Computer Society. This is a compendium of papers and articles on requirements engineering. Some are dated but all are readable and useful.
System and Software Requirements Engineering, Richard Thayer, IEEE Computer Society. This is a tutorial on requirements engineering, with a wealth of information, some dated. Thayer has another book on requirements engineering gathering but it is very DoD – centric.