Ian Alexander and Ljerka Beus-Dukic
Wiley, March 2009
ISBN 0470712406 (paper)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
Also by Ian Alexander:
Writing Better Requirements
Scenarios, Stories, Use Cases
ReviewsI can't review my own book, but here are some published reviews by distinguished colleagues and enthusiastic readers.
|
ResourcesThere are many free resources on the Scenario Plus website to help you apply the book in your work, or to use it for teaching.
|
I have never bothered reviewing a book on Amazon before, but for this I have
made an exception. I have over 20 books on requirements engineering, and I can
say without hesitation that this is one of the very best. This is an extremely
readable and useful book.
This book is well organised, practical and insightful. The authors propose a
matrix of "Elements" and "Contexts" for requirements discovery. Following this
model, the book is divided into two parts; Part 1 - Discovering Requirement
Elements (with chapters on Stakeholders; Goals; Context, Interfaces, Scope;
Scenarios; Qualities and Constraints; Rationale and Assumptions; Definitions;
Measurements, and; Priorities), and Part 2 - Discovery Contexts (with chapters
on Requirements from Individuals; Requirements from Groups; Requirements from
Things; Trade-offs, and; Putting it all Together). In the Introduction, the
authors state that requirements specification can be considered to be a network
of related elements, "...and indeed, the chapter structure of this book can be
seen as a customisable template for organising the requirements on your
project."
If pithy quotes are a good measure of the value of a book, then this is a great
book. I stopped scribbling down quotes by page 10 when I had amassed the
following:
In addition to the quotable quotes, the book is also crammed with well-crafted expressions and valid observations. A few that I liked are:
This book is unusually easy to read and extremely well structured. Each chapter begins with a couple of sentences defining the questions that the chapter will answer. Next is a paragraph summarising the chapter. The reader can therefore establish, in less than a minute, whether a chapter is likely to help them with their immediate problem. Following the main body of each chapter (all of which are also very well structured), there is a "Bare Minimum of..." which, as the heading suggests, defines the least you should do for this element or context. Each chapter also includes a small but valuable set of Exercises and suggested Further Reading.
Each chapter begins with a couple of sentences defining the questions it will answer
Many people involved in system development (still) talk about "users" as a homogeneous group. Increasingly, more enlightened people talk about "stakeholders" - but I am not convinced that stakeholder analysis is actually taken seriously in many developments. For this reason I'd argue that chapter 2 of this book ("Stakeholders") is essential reading for every systems engineer/business analyst/project manager. There is a strong emphasis in this chapter (and throughout the book) on the importance of stakeholders and consideration of stakeholder roles. As ever, Ian Alexander is quick to remind us that we should always consider negative stakeholders.
The book comfortably straddles what might loosely be called "theory" and "practice". The breadth and depth of the authors' experiences are woven throughout, with no awkward distinction between concept and application. The final chapter "Putting it all Together" does exactly what it claims. Included in this chapter is an essential table of "possible discovery context/requirement element approaches" and a set of case studies that illustrate how an element/context matrix may be populated for a specific project.
Having read the book and made some notes for this review, I tried an experiment. I randomly opened the book in half a dozen places. On each page I quickly found something interesting and useful. I tried the same experiment with a range of other requirements books, and not one of them was nearly as satisfying. I don't suppose this is how the authors intended the book to be used, but it does give a good indication of its quality and value. There is no filler in these 450 pages. I wholeheartedly recommend this book.
This book provides valuable and accessible techniques for anyone who is involved in the process of eliciting requirements. The authors have avoided organising the book in a procedural way; instead they have structured it using the intersection of nine “requirements elements” and five “discovery contexts”. Each chapter focuses on how to gather more information about one specific requirements element within each of the discovery contexts.
Chapter 6 for example is about a requirements element called “Qualities and Constraints”. Here the chapter focuses on techniques for discovering the non-functional requirements (qualities) and compliance issues (constraints) in a variety of discovery contexts. Contexts in this case can mean the individual stakeholders, relevant groups and so on. The strength of this organisation is the freedom it gives the reader to move around within the book (possibly a new non-functional requirements type) while at the same time providing the reader with an overall connective framework.
Each chapter focuses on techniques for one of the Requirement Elements or one of the Discovery Contexts
The combination of sociological, philosophical and technological themes provides a much needed emphasis that requirements are not just about software solutions. References to Peter Checkland’s work, among others, reminds readers that “system” does not necessarily mean “computer system” and that effective requirements discovery means looking at the wider world.
I am pleased to see techniques for goal modelling and structuring are covered in sufficient detail to enable practitioners unfamiliar with the notation to put it to good use.
Priorities is another requirements element for which the authors provide a number of alternative thinking approaches. I like the idea of thinking about “input priorities” as the priority assigned by stakeholders and “output priorities” as the priority assigned from the perspective of availability of a practical solution. Another interesting topic related to prioritisation is the inclusion of a statistical method called principal components analysis (PCA). A worked example illustrates how this technique can be used to provide input to (not replace) human decision-making about the inevitable trade-offs between requirements. At the other end of the formality scale a nursery rhyme (this year, next year, sometime, ...) is used to help to do triage and assign priorities to requirements.
From a practical point of view the authors have provided substantial worked examples of techniques to aid requirements discoverers in their tasks. Examples are drawn from fields as diverse as air traffic control, tram routing, video games and restaurant management. I would also have liked to see one complete example but recognise that space constraints impose a trade-off.
A theme that runs through the book is the need to communicate with diverse stakeholders who all have their own view of the world. The authors’ wise advice is that
“there is no point trying to force requirements language on people. When you’re interviewing a stakeholder, don’t start talking about ‘non-functional goals’ or “quality requirements’. Ask plain questions about what people want to achieve, and what performance they are seeking”.
This book is written in a way that you would enjoy reading it from cover to cover. It is also an excellent reference book and, no matter what techniques you are using, I am willing to bet that you will find additional insights and approaches to improve your requirements work. Keep this book on the shelf by your desk, you will find yourself referencing it often.
Ian Alexander's latest requirements book is a pleasure to read. He and his co-author have succeeded in producing a book that represents the latest thinking in requirements management.
The authors approach their task in a typically rigorous
manner by describing firstly different requirements elements, then different
discovery contexts, before combining both elements and contexts to suggest
approaches for different types of project.
Among the highlights of the book are:
A lucid explanation of Alexander's onion model for stakeholder analysis, put in context using goal diagrams, where stakeholders' aspirations are mapped to look for any conflict early in the project.
The use of the soft systems method to capture the soft boundaries of the project environment before formalising it using context diagrams and event tables.
Some simple but effective ways to capture high-level scenarios in a workshop environment.
Using goal analysis to capture constraints and qualities. There is a lot of material in this chapter, including some that will be increasingly important in coming years, such as sustainability.
The use of rationale models and goal structuring notation to document assumptions.
A large chapter on measurements, with a balanced approach to the debate on whether acceptance tests are a substitute for requirements statements (a view promulgated in the Agile world), leaving the reader to decide what is best for his or her circumstances. Recognising that many large projects now include a service element, there is a sizeable section on quality of service measures.
After a comprehensive section on contexts for discovering requirements, the section on trade-offs gives a number of methods, such as principal component analysis for formalising the often-unstructured way that design options are chosen.
One of the strengths of the book is that it is un-wedded to a particular method, tool or diagramming style; and the focus on systems engineering projects, with side-references to software-only projects, rather than the other way around as found in many texts.
I predict that this excellent book will become the standard requirements reference work for serious practitioners and one to be re-read frequently for new insights. Those coming from an Agile software background will find much to learn (and challenge!) from the more formal approaches presented, while those from a rigorous systems engineering background will find food for thought in options for a softer, collaborative approach and an emphasis on scenario-based structure.
Outstanding! Its construction reflects clearly the authors
are intimately acquainted with the real world and what is practicable in terms
of approach.
You readily grasp how their coherent approach avoids alienating your clients or
colleagues with methodologies and processes that don't "fit" or appeal to them.
Practical approach is not sacrificed to rigour but is underpinned by the
authors' comprehensive knowledge of the "full range" of methods and where they
do fit. Anyone who is involved in planning and design will recognise the issues
so clearly articulated and be able to grasp the straightforward, smart
approaches for making effective progress.
I'd love for the authors to make this book available as a series of video
lectures or on audio??
Ian Alexander and Ljerka Beus-Dukic have done a wonderful
job with this book. I have not found any other books so far that are focused
solely on the discovery phase of the systems and software requirements process,
and consequently no others cover the topic in so much depth. They really just
have exactly the right amount of details in order to understand and start using
the concepts covered. It's a book that is well designed for beginners in
requirements who want to understand how to elicit requirements, but it is also
full of useful ideas for the more experienced requirements practitioners. They
cover most of the possible requirements elicitation techniques with suggestions
on how to use them, as well as situational contexts in which you would need to
elicit requirements.
I like the overall organization of the book, as it is laid out in a very logical
manner making it easy to follow. In general it is very easy to read as well.
While maintaining a professional tone, they have made it quite enjoyable to
read. There are many stories (project specific and fun ones!) to put the
concepts in context and to me, those make the book. And if you complete the
exercises they have included in each chapter, you can ensure you really grasp
the concepts. What I like about the practice exercises is that the answers are
not simply "right or wrong" but include a discussion about them each.
Finally I'll comment that this book is extremely practical for someone in
industry trying to improve at discovering requirements. The authors have used
real-world experiences to build out the ideas written about and as you read it,
you can't help but understand how you'd do the same things on your projects.
This is one of the best requirements books I have read - both in content and
ease of reading!
In their book, Discovering Requirements, Ian Alexander and Ljerka Beus-Dukic combine their years of experience to produce a work that will be of value to the practitioner and the academic alike. It is a work that, as it says on the cover, is timely, practical and reliable.
The book starts from the earliest project, or even pre-project, stage, where context and scope are typically unclear. Stress is placed on the importance of understanding the real business need before attempting to satisfy that need; crucial advice in the present economic climate.
In Part 1 of the book, the reader is guided through a logical process in which the stakeholders and their goals are identified, analysed and progressively refined, leading to the creation of validated, verifiable and non conflicting requirements.
Although there is a logical flow to part 1, the book, wisely, does not define a prescriptive process. It does however contain all the ingredients and sufficient guidance to allow the reader to create their own recipes for ‘processes’ that can be intelligently applied to specific situations. The book’s two part structure directly supports this goal; part 2 describes the contexts in which the ingredients can be used and mixed in order to discover the requirements. The final chapter of this large work contains invaluable advice on ‘Putting It All Together’.
In short, this book provides a valuable addition to the literature on requirements. I can thoroughly recommend it.
If you pick up a book authored by Ian Alexander, you will not be disappointed. Alexander has a way of cutting through all the engineering hyperbole and getting to the heart of what really matters for practitioners when it comes to requirements engineering. His latest offering, “Discovering Requirements”, co-authored with Ljerka Beus-Dukic, is no exception. It actually appears to be a very welcome and expanded version of Alexander’s popular column article: “Ten Small Steps to Better Requirements” (IEEE Software, Volume 23, Number 2, Pages 19-21, March/April, 2006).
“Discovering Requirements” is split into two parts. Part 1 examines the different elements that you need to think about as part of any requirements engineering process. The authors suggest that these elements are: stakeholders, goals, context, interfaces, scope, scenarios, qualities, constraints, rationale, assumptions, definitions, measurements and priorities. Pragmatic techniques and numerous heuristics are provided, chapter by chapter, to help you discover each of these requirements elements on a project. The material is augmented by the effective use of “Guest Boxes”, which offer related advice from other respected practitioners in the field. Chapter 2 is noteworthy as it stands out as one of the most readable overviews to the critical topic of stakeholder identification and analysis. Personally, I have been using Alexander’s very simple “Onion Model” for some time now, and I can certainly recommend this as a fine way to discover hidden stakeholders and get your requirements engineering efforts off to a good start.
Part 2 of “Discovering Requirements” changes perspective somewhat and explores the various contexts in which these requirements elements can be discovered. The first three chapters describe the pros and cons of different discovery approaches that work with individuals, groups and things (i.e., other artifacts), respectively. Chapter 14 is yet another gem. As requirements engineers, we are always in the business of negotiating trade-offs between the wants and needs of multiple stakeholders as we explore potential design options. The authors provide a catalogue of very practical methods to help you through this delicate “Optioneering” process.
Throughout the entire text, the authors are careful to emphasize that they are not offering a prescription for discovering requirements. They discuss what they consider to be the essential requirements elements, and the various ways in which they can be discovered, but they demand that their readers think carefully when putting together “the simplest process that works for you”. Rather than leave the reader to join the dots for themselves however, as many texts do, the final chapter offers some guidelines as to how to do this and provides some small case studies.
“Discovering Requirements” is an attractive addition to any requirements engineering bookshelf, and I recommend it for any practitioner or student who is trying to give some structure to what may initially appear to be an ad-hoc task. Given its accessibility, it is a text that you WILL take off your bookshelf, and you will probably dip into regularly for guidance, hints and tips. While “Discovering Requirements” does not claim to provide all the tools you need to engineer your requirements fully on a project, it is pretty exhaustive in what you need to do and what you need to think about in their initial discovery. Let us hope that Alexander and Beus-Dukic’s next text demystifies the principles and practices of requirements management just as painlessly.
An excellent and practical book on requirements engineering (RE) that can be recommended for both novices and experience professionals. I cannot judge the value of this book in general, but from my experience, this book is very valuable for everybody engaged in software development. It has helped me to analyze some of our past projects and understand the drawbacks of our system development process, which we hopefully can correct in the future.
I like this book because it destroys many myths, some of which are obvious for professionals, but not all. The destruction of the most obvious myth is in the book title. The requirements cannot be just gathered but need to be discovered, and discovering them is a profession that may or may not mix with the experience in a specific application domain. A professional requirement engineer can do a better job in the previously unknown for him/her domain than an ordinary experienced professional in this domain. The discovering process can be compared with the one of a field linguist writing a grammar for a language that exists only in the spoken form. An experienced field linguist can do the job even when he/she cannot speak the language, but a native speaker unless he/she is also a field linguist cannot do it. This book presents a number of practical methods for what is in its title – discovering requirements.
One of the not so obvious myths is expressed by a phrase that can be found in many standard manuals: “You need to give a customer what they need not what they want”. The answer that indirectly follows from this book is that you cannot give a customer what they need unless they also want it. The book has a special focus at finding all stakeholders of the future product/service and make them agree on the common understanding of what they need/want. Missing an important stakeholder may put the whole project at risk. Converting the wants to needs requires special technique of finding rationales behind each “want”, and this technique is also in the focus of the book.
Other myths that the book destroys concern modern techniques, such as modeling languages, e.g. use cases, software tools, e.g. groupware, and scientific methods of choosing an optimal alternative, e.g. weighting. These techniques are often marketed as a solution for all possible problems, however, the book advices to use them with a great caution. Over relying on these techniques may result in the focus being moved from discovering requirements to something else, e.g. syntax of a specific modeling language, or details of the product, or user-interface design. Besides, using these techniques may consume too much valuable time from the requirement team. The book recommends using simple tools and techniques, and uses common sense rather than scientific methods.
This is a straightforward and engaging piece of work focused on the soft side
of requirements. Don't come here looking for a technical treatise on
requirements management tools, but do buy this book if you need a clear overview
of how to arrive at the requirements to manage.
I found it very well organized. There are dedicated chapters on types / levels
of requirements from stakeholder identification through goals, scenarios and
constraints, followed with clear examples of how to explore and document those
requirements, and techniques for use with individuals, groups and other systems.
Of necessity, in this kind of broad treatise your challenge will be to select
the tools and techniques to use among the many that are presented, but with this
book you will have no shortage of ideas.
I am only 70 pages into this book and my first impression is that its style
is very much in the tradition of 'teach yourself'
Its laid out well and instructs the reader, at a very basic and practical level
in the steps that it describes.
For anyone at the beginning of a 'requirements' centred career it seems an
ideal, solid and practical way to acquant yourself with the basic issues and
processes in requirements elicitation.
This review will be updated once I have read it all. But as so many reviewers
have done such a splendid job this brief perspective may suffice to communicate
its essence.
Hard to see how you could go wrong in buying this book.
I think this is currently the best book available on requirements engineering. The structure of the book is a little odd but the practical advice, quality of writing and explanation are unparalleled. It is particularly good if you are involved in developing products for style such as software package or an embedded system. Many business analysis courses and books take [an] approach of business improvement within the organisation; this takes approach which is more geared to identifying and specifying requirements for a product. This is very good value at £20
(c) Ian Alexander 2009-13
You may also like:
