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
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,
- Requirements by Collaboration: Workshops
for Defining Needs, Ellen Gottesdiener, Addison Wesley, 2002
- Requirements Engineering and Rapid Development, Ian Graham, Addison
- 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
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.
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
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.
Corners of Requirements Engineering," Pamela Zave and Michael Jackson, ACM
Transactions on Software Engineering and Methodology, 6(1), January
1997, pp. 1–30.
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
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
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
Projects: Evolutionary vs. Big Bang, Felix Redmill, John Wiley &
Sons. This is a good (and easy) book for sorting out the project method
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.
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.