on 17 March 2009
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:
* "Requirements are discovered by the use of appropriate inquiry techniques. They are not sitting about, waiting to be `captured'."
* "Discovery, however surprising and delightful the actual moment of realisation, comes as a result of a deliberate search."
* "Projects need to pay attention to discovering their requirements, using a battery of complementary techniques..."
* "Perhaps the projects in greatest danger from poor requirements work are those that seem fairly small and simple, but turn out to contain hidden complexities."
In addition to the quotable quotes, the book is also crammed with well-crafted expressions and valid observations. A few that I liked are:
* "goals and stakeholders work together"
* "ill-defined boundaries"
* "interfaces aren't just hardware"
* "requirements archaeology" (gathering requirements from documents)
* "Requirements Chef" (a lovely concept, included in Chapter 15, "Putting it all Together")
* "no two projects are alike"
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.
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.
on 3 April 2009
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.
on 27 July 2009
Fantastic book! Have you ever struggled to find out what your customer actually wants? And after you're well on the way with your project, you start getting customer comments like: "yes, but..", "I didn't mean that..", etc. And then you begin to feel like "uh, oops, we really should have elaborated more on defining the requirements...".
But the term defining implies that your customer tells what they want and you write it down in a meeting, polish later on, and that's it. Go on and start a project ... and problems like above surfaces.
Requirements need to be discovered and this is the best book on how to systematically "tease" out what the customer (=stakeholders) want, what are they assuming, but not saying unless explicitly asked, etc.
The "abstraction level" is very good, not too cookbook specific and not too academically general. Text is very readable and clear and well structured.
This book helps you to direct your (and your customer) thinking to obtain desired goals, and thus is valuable also for people outside the engineering field.
on 17 June 2009
Discovering Requirements: How to Specify Products and Services
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.
on 4 July 2013
A great book, which every Business Analyst should have. The writing style is engaging. The examples given are useful and drawn from diverse areas of business and industry. The book is useful for both Business Analysts and design engineers.
The book is so useful I have it as a reference guide in my day to day work as a Business Analyst, I wish I'd bought the book several years ago.
on 22 March 2009
Review of Discovering Requirements, by Ian Alexander and Ljerka Beus-Dukic, John Wiley, 2009.
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.
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 principle 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.
Chamonix March 22, 2009
on 23 December 2009
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 experience 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 requirements team. The book recommends using simple tools and techniques and use common sense rather than scientific methods.
on 9 May 2009
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 author's 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??
on 17 May 2010
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.