I have (to the best of my ability) written the book I would have liked to have had with me when planning workshops and interviews, and choosing the right mix of requirement discovery techniques for a project.
My aim throughout is to be simple and practical. For example, the references are almost entirely to books that also give practical advice; where no such book existed, I have referred to articles available on the Web, or have given warning that a reference is academic.
The requirements discovery process consists of a wide choice of many simple activities (and a few more complex ones, such as prioritisation and trade-offs). Organising these into a book is a challenge, as the right mixture is different for every project. Some books take you on a grand tour of hundreds of techniques - and you have no idea which to choose. Other books decide on your behalf which set of techniques you must choose - say, workshops, use cases, and voting on priorities - and pretend these will be suitable for your project.
I suggest a middle way. There is more than one technique to choose from in every part of requirements work: but there need not be too many alternatives. And, your choices are driven by your project's situation.
There are just a few contexts for requirements discovery: working with individuals (e.g. interviewing); working with groups (e.g. workshops); working with artefacts (e.g. prototypes and existing documentation); and exploring trade-offs (e.g. what requirements would be feasible, given the existing design constraints). These 4 broad contexts form the chapters in Part II of the book.
Similarly, there are just a few basic elements that make up any requirements description: things like lists of stakeholders, of goals, of scenarios (or stories, or use cases), of interfaces and business events (the system context), of definitions of terms and data, of qualities and constraints (so-called non-functional requirements), of assumptions and other justifications for decisions, of measurements and priorities. These elements pop up in every requirements method and process in some form or other. They form the chapters in Part I of the book.
I realized that I could present a clear account of these techniques, without excessive complexity and without over-simplifying, by showing that Discovery Contexts and Requirement Elements form the columns and rows of a matrix. Any actual use of a technique is in one cell of that matrix. For example, interviewing a stakeholder for their goals is a combination of the "Individual" context with the "Goals" element. So, the book just needs to describe interviewing once, and goals once.
There is a danger with any such analysis of ending up with a lot of little bits and no big picture. I have carefully built up the "big picture" by providing:
I expect you will find many things in this book that are very familiar; some that are new; some that you find obvious, and some that you find controversial. Someone commented on one of my earlier books "This is mostly just common sense", as if that was a defect. Such things may be simple, but are often not easy to write down, or to do, so I was both pleased and amused by the comment.
What I hope, though, is that you will find it quick and convenient to refer to; direct and practical in its guidance; and broad enough in its scope, thinking, and if necessary its Further Reading (in each chapter) to help you in your work, whatever kind of project you are involved in.
There are many free resources on my website (www.scenarioplus.org.uk) related to the book, which I hope you will find useful.
May I wish you every success on your projects.
(c) Ian Alexander