by Karen L. McGraw and Karan Harbison
Lawrence Erlbaum Associates, 1997
ISBN 0805820655
by Karen L. McGraw and Karan Harbison
Lawrence Erlbaum Associates, 1997
ISBN 0805820655
Buy it from Amazon.com
Buy it from Amazon.co.uk
Have you ever wondered whether there was more to requirements than just lining them up neatly in a good requirements tool, prioritising them, and tracing them to your design and tests? Does anyone know how to get hold of them in the first place, to make sure they are right, that they are what the users want, and reasonably complete? Should you interview department heads or hold a workshop of ordinary users? How much detail should you capture? What should you do if interviews go on too long?
The good news is that there are well-worked-out answers to these practical questions, and to many others. This book very sensibly combines the expertise of an academic (Harbison) and an industrialist (McGraw) to explain how to make your requirements tell the story of what results your users really want to have. The book therefore has some industrial features, like big, simple pictures based on clip-art, clearly illustrated examples, and step-by-step procedures, as for instance an 8-step account of how to document a requirements elicitation session. It also shows the careful hand of an academic, giving details of many techniques that might be used for each purpose rather than just recommending one that's tried and trusted.
As a result, this book is probably most useful as a reference when you are, say, preparing a workshop and are wondering if you should try out a different technique or two from your normal repertoire. The alternatives – or at least a good many of them – are plainly set out, and once you have chosen one (perhaps that is the difficult step) you will find a straightforward recipe for doing it in the appropriate section.
For example, to analyse existing or 'as-is' scenarios, the authors suggest making event traces (we'd say swimlanes or sequence diagrams), graphics such as storyboards, matrices (tables) showing events, activities, information, performers, and key issues for each scenario - what we might call an Actors & Activities table - or building an object model showing the human or system roles, the information each maintains, and the activities that each carries out.
A different set of techniques is suggested for desired or 'to-be' scenarios. The book suggests using a topological or geographical map to show where events occur in relation to each other; a flowchart to depict the major scenes or events, and then running facilitated brainstorming and consensus decision-making sessions to expand each scenario into more detail. These techniques are more exploratory and able to deal with ideas and speculation about the best way to do things, whereas the 'as-is' techniques suggested are more definitive and analytic, as you need when documenting the way things are actually done.
Part I introduces 'the Scenario-based Engineering Process' and the activities and 'artifacts' of knowledge elicitation and analysis. These terms hark back to the days of Expert Systems, and indeed authors like Anna Hart and Doug Lenat are referred to.
Part II presents a thorough and wide-ranging set of processes and techniques: planning requirements activities, selecting techniques, elicitation, interactive observation, interviewing, identifying work processes and task analysis, domain concepts, using process tracing to analyze the problem-solving process (i.e. decision-making, expertise), group sessions, evaluating and refining requirements.
Group techniques are perhaps especially well covered. Techniques include walkthroughs, decision process tracing combined with protocol (transcript) analysis, goal-oriented brainstorming by traditional 'shout and post', brainstorming by round robin - everyone gets a turn, making a problem tree or herringbone diagram, consensus decision-making, the nominal group (no arguments, comments are written down and passed to the facilitator who lists them and organizes a vote), focus groups, computer-aided brainstorming (as with Barry Boehm's Win-Win), or video conferencing. In other words, far from there being no obvious ways to gather requirements, the real problem is choosing the most appropriate ways for a given situation.
The authors have a background in Knowledge Acquisition and Participative Design, rather than Requirements Engineering as such. They are also very familiar with techniques from psychology, such as Kelly's repertory grid, and man-machine interaction. This means that the authors say 'performers' where we might expect 'actors' or 'roles'; 'shareholders' where we might say 'stakeholders', 'defining work processes' rather than 'business process modelling', 'task analysis' instead of 'scenario (or use case) analysis', 'group sessions' not 'workshops'. These little differences shouldn't matter to any reasonably well-informed reader, but they do indicate that people come to the requirements field from many different directions.
There are a few other good books on gathering requirements, notably Ellen Gottesdiener's Requirements by Collaboration; there are some that provide practical advice on scenario-based requirements, such as Alexander & Stevens' Writing Better Requirements or Alistair Cockburn's Writing Effective Use Cases, but perhaps none that cover so many techniques so clearly.
If you gather requirements and would like to have a practical and well-read pair of experts at your elbow, you could do a lot worse than to search out a copy of this book. It is detailed, accurate, careful, and well-organized.
Students may also find it helpful; there are no exercises or glossary, but the book introduces its topics separately and the references and index are good. For the same reasons it would make a solid basis for a lecture-course.
User-Centered Requirements is full of good sense, so let us give the authors the last word:
"Common problems that lead to defective requirements include:
- Developer assumptions that the requirements are 'obvious'.
- Failure to do enough requirements elicitation and analysis.
- Failure to include appropriate personnel in requirements elicitation and analysis activities."
© Ian Alexander 2003