Our Current Top Books

 These are the books that we recommend for requirements, innovation and general thinking work.

Business Analysis Agility - James Robertson and Suzanne Robertson.

You can only deliver real value is to understand what your customers actually value, and solve the problems they actually have. Business analysis enables you to do this -- and it’s just as crucial in agile development environments as it was before you adopted agile.

In Business Analysis Agility, world-renowned experts Suzanne Robertson and James Robertson show how to perform effective business analysis that integrates tightly with agile development teams and processes. They introduce a better way of doing business analysis by first identifying customer segments and then developing value propositions for each.

You’ll learn how to use a series of “safe-to-fail probes” to determine the feasibility and viability of each option. Step by step, the Robertsons show how to design your solution for optimal convenience and efficient use of data. Discover how to describe your solution through compelling “story maps” that make it easier to prioritize and manage product backlogs, and stay in control of your product as it moves through development.


Systems thinking books Various authors,

Systems thinking has long been treated as a separate discipline. Now this is becoming more recognised as a skill that is of great benefit to Business Analysts. If this is new to you then I suggest you start by sketching dynamics models to clarify your own, and other peoples' mental models. It's amazing how much this helps with communication and how many questions it raises. The following is a list of useful books on Systems Thinking.

  • Russell L. Ackoff (2010) Systems Thinking for Curious Managers. (Triarchy Press). ISBN 978-0-9562631-5-5
  • Peter Checkland, John Poulter (2006) Learning for Action. (Wiley) ISBN 0-470-02554-9
  • Donella Meadows (2008) Thinking in Systems - A primer (Earthscan) ISBN 978-1-84407-726-7
  • John Seddon (2008) Systems Thinking in the Public Sector. (Triarchy Press). ISBN 978-0-9550081-8-4
  • Peter M. Senge (1990) The Fifth Discipline - The Art & Practice of The Learning Organization. (Currency Doubleday) ISBN 0-385-26095-4
  • Gerald M. Weinberg (2001 - revised) An Introduction to General Systems Thinking. (Dorset House) ISBN 0-932633-49-8
Business Analyst: Careers in Business Analysis. Adrian Reed.

An invaluable reference book for Business Analysts. The book makes a clear distinction between BA Skills and BA Role Names. The Skills Framework for the Information Age (SFIA) referenced in the book provides examples for how the skills are often packaged into Roles/Job Titles. This will help people figure out what they mean by a Business Analyst in their own particular organisation/project.

The chapter on the Breadth and Depth of the BA Role is a coherent discussion on where the BA role fits in the lifecycle of Business Change. And there is a good explanation of how a BA can work to communicate and fit with other specialist disciplines.

This is a major step towards making Business Analysis a more recognisable and hence more recognised profession.

Understanding Requirements: Beyond the Basics. David Gelperin. 

The challenges and opportunities inherent in the expanding role of software and in Agile development have caused an evolution in our understanding of requirements development (RD). The purpose of this book is to share new RD perspectives and pragmatic techniques based on this evolving understanding.

The book provides new perspectives on the goals and strategies of RD as well as the nature of requirements information and understanding. It describes the limitations of uniform approaches to requirements (e.g., Waterfall or Agile) and provides rationale and details so that you can use these new perspectives in your RD activities.

Current RD books thoroughly cover the tasks, techniques, and tools of requirements elicitation, analysis, specification, and validation. While this information is valuable in dealing with many situations, these books omit or contain inadequate information about: 
  • Stakeholder understanding
  • Demonstrations of developer understanding
  • Quality attributes
    • Supporting and conflicting relationships
    • Goal definitions
    • Achievement strategies
    • Verification strategies
  • Mixed requirements strategies
  • Requirements management
  • Requirements risk analysis and management

The supplementary readings (references) in each chapter include material from articles and books. All referenced articles are freely available on the book’s website ( The 3D quality model described in chapter 3 is freely available at

This book is meant to help experienced practitioners improve their requirements practices and those of their team. Product owners and managers, as well as project managers, should find the content especially useful since they are often responsible for requirements development and management. Other potential readers include requirements leads, technical leads, analysts, testers and other verifiers, quality support staff, developers, consultants, and customers.

Business Analysis and Leadership: Influencing Change - Penny Pullen and James Archer, editors.

This book is a collection of essays that are all pointed in the same direction -- the place that business analysis has within the organization. The editors wrote some of the piueces themselves, and called on notables in both the business analysis field and cleverly selected adjacent fields, to bring about a significant work. The topics are varied, which makes for both an educational and interesting read. Topics include:

  • facilitative leadership
  • working with the project manager
  • dealing with difficult stakeholders
  • the iterative business analyst
  • global working and virtual teams
  • systems thinking
  • power and politics
  • strategic thinking
  • becoming a thought leader
  • ethics, professionalization and best practice
  • developing your skills, and the courage to apply them
  • communication and negotiation

Your Volere authors are contributors to this book.


Mastering the Requirements Process - Getting Requirements Right by Suzanne Robertson and James Robertson

This review is posted on Dr. Dobbs site. We thank the Dr. Dobbs reviewer for it.

"Requirements books are few in number, but they all look like they were cloned from the same parent. They focus on how to cajole users into expressing their needs, and then segue into capturing that data in use cases. Then they cover requirements management and disappear entirely into discussions of pure IT processes. What they never actually do, though, is show you a complete and correct requirement, properly captured and correctly described.

This book takes a completely different approach, which is considerably more useful. The authors start right off showing you templates for requirements. They then step through the aforementioned topics. But instead of vanishing into IT procedural details, they circle back with an excellent series of chapters that critique bad requirements. They provide a series of intelligent suggestions for making the requirements better. For example, they discuss the problem of granularity — how detailed should the requirement be without veering too deeply into implementation details? How to avoid ambiguity in capturing needed details. How to specify measurable requirements. And so on. It's clear the authors have done a lot of work in this area and they've managed to extract the critical information and key lessons from their experience. These chapters alone are worth the price of admission. Having looked at many of its competitors, I can honestly say without fear of correction that this is the best book on requirements available today. Highly recommended."

User Stories Applied: For Agile Software Development by Mike Cohn

"User stories" and "requirements" are not always mentioned in the same sentences, except erroneously. So let me state at the outset that user stories are not requirements, they are placeholders for requirements. I am happy too see that Mike Cohn endorses this view, and got some way to bridging the gap between stories and requirements. He also gives some good advice of selecting the personas (my word, he doesn't call them that) for the stories.

User stories are often a weak link in the agile process, and I suggest strongly that anyone using any agile process read and digest this book.
Requirements in Engineering ProjectsJoao M. Fernandes and Ricardo J. Machado

This book focuses on various topics related to engineering and management of requirements, in particular elicitation, negotiation, prioritisation, and documentation (whether with natural languages or with graphical models). The book provides methods and techniques that help to characterise, in a systematic manner, the requirements of the intended engineering system.

It was written with the goal of being adopted as the main text for courses on requirements engineering, or as a strong reference to the topics of requirements in courses with a broader scope, or as a vocational courses, for professionals interested in the software and information systems domain. Each chapter includes a set of exercises.

Business Model Generation by Alexander Osterwalder & Yves Pigneur

I have to confess that my interest in this book is not as the authors intended. They write a book about planning a new business venture, and my interest is in planning a new business analysis project. However, I see enough value in the BMG approach to make this very worthwhile for business analysts to use.

The BMG approach (I will not call it a method, it is too smart for that) sets down a canvas giving segments for the various factors that one must determine for any business analysis project. Thus far it might resemble PESTLE, SWOT, ALUo and countless other inane acronyms. But from here on is where the book provides its worth.

The BMG canvas is wonderfully illustrated, and each of its segments explained.
•    Customer Segments: Who Will Use The Product?
•    Value Proposition: Why Will They Use The Product?
•    Channels: How Will The Product Be Delivered To The Customers?
•    Customer Relationships: How Will You Develop And Maintain Contact With Your Customers In Each Segment?
•    Revenue Streams: How Is Revenue Generated From Which Customer Segments?
•    Activities: What Are The Key Things That You Need To Do To Create And Deliver The Product?
•    Resources: What Assets Are Required To Create And Deliver The Product?
•    Partners: Who Will You Want To Partner With (E.G Suppliers, Outsourcing)
•    Cost Structure: What Are The main sources of cost required to create and deliver the product?

It is this explanation of the segments, and the examples of different companies that give the book its value and make it both interesting and worthwhile. I suggest that serious business analysts look at this book.

Complete Systems Analysis: The Workbook, the Textbook, the Answers by James & Suzanne Robertson

Complete Systems Analysis is a book that teaches systems analysis by having you, the reader, work through a significant case study. Along the way, you visit chapters that discuss various techniques and give you a solid knowledge of how to do it. You work along the path that you select -- easy, medium, advanced -- so that you are never floundering, nor are you restive because it is too easy.

"Clearly the best book available for teaching modern systems analysis to practitioners. It is equally strong in explaining techniques and in the underlying principles." Rich Cohen, STARSYS Inc.

Available from Amazon as a paperback and from InformIT as an e-book. A sample chapter is available for download.


Requirements in the Real World by Jan Willem Knop, Marcel Schaar and Mark Hoogeveld

The book is written in Dutch and the actual title is Precies volgens plan! ( Exactly according to plan!) and has a subtitle "Successful IT projects with clear requirements". A short English description of the book at can be found here
I cannot review the book as it is written in Dutch, however the summary indicates a useful reference for Dutch speaking requirements specialists.  The authors acknowledge their study of Volere and the Mastering Requirements courses as the  starting point and inspiration for developing their ideas.
The Quest for Software Requirements  by Roxanne Miller, MavenMark Books.

In an age when many technical books provide little more than cheerleading for one technique or another, it is refreshing to come across a book that is genuinely useful. The subtitle of Roxanne Miller's book gives us the clue as to what this book is about: "Probing questions to bring nonfunctional requirements into focus”.

The book has two parts, which I will explain to show you why I think this is useful. In the first part Ms. Miller takes us through an introductory piece on requirements. She is not attempting to make this an exhaustive treatise on gathering requirements. Instead, its purpose is to bring readers up to speed and preparing them to mine the value of part two.

In the second part of the book (I cannot call it the second half because it occupies most of the book), Ms. Miller provides us with an extensive list of nonfunctional requirements. Then comes the value: for each of the non-functional types she provides an expansive list of questions that the business analyst would do well to ask. This is not merely a checklist for the business analyst to tick off as he or she works through the pages. Instead, it provides questions that challenge the business analyst, and the stakeholders, to consider seriously the particular nonfunctional requirement type being dealt with at the moment.

Nonfunctional requirements are a major contributor to successful projects and products, and bewilderingly, are often ignored by development teams. Ignoring the nonfunctional requirements, or leaving them to the goodwill of the developers, almost always results in substandard products that are rejected by the users. Agile development teams are well advised to take note of this book—user stories are usually about functions or features. There is growing evidence that agile teams are not adequately discovering the appropriate nonfunctional requirements. Even a cursory reading of Ms. Miller’s book reveals many requirements that could easily be missed by the user story writers.

 I think that the best recommendation I can give this book is to say that I shall give a copy to the project on my consulting assignments. I know it is going to have a beneficial impact.

Presentation Zen by Garr Reynolds, New Riders Press.

Making presentations is a part -- or should be -- of most business analyst's work. This involves selling your ideas for the new system, trying to get a consensus on what the scope of the problem really is, and generally convincing people that you know what you are doing. And let's be honest, you are not going to be successful with a dull-as-ditchwater PowerPoint presentation full of bullet points.

Please read Garr Reynolds' book, and take just some of how advice. Your audience will love you for it, and who knows, they might even listen.

The Adventures of an IT Leader by Rob Austin, Richard Nolan and Shannon O'Donnell, Harvard Business Press.

This is a charming book written by charming people. Please do not be put off by my recommendation of the authors. I mention it because you will be charmed by this book, and you will learn from it—the authors are charming and knowledgeable. The Adventures of an IT Leader sets out to examine the role of the CIO using the form of the novel. Jim Barton is a newly appointed CIO with no IT experience, and he, along with you, learns how to be an effective leader in an organisation where IT plays a crucial role.

The novel form of learning is not, er, novel, and this time out Austin and company have used it to great effect. You are carried along with their hero as he deals with open warfare in his department as he struggles to juggle conflicting demands with resources and risk.

The book is not all entertainment. Each chapter has a section at the end for reflections and lessons learned. I was tempted to read only these, but the Jim Barton’s days in the office were far too alluring.

The Innovator's Toolkit: 10 Practical Strategies to Help You Develop and Implement Innovation Harvard Business School Press (Author)

This book lists a writer (Richard Luecke) but no author. So presumably, it has been assembled by members of the Harvard Business School Press. This shows as the book comes across as slightly stuffy and academic. But that is the bad news out of the way.

The rest of the book is made up of practical advice. That is, advice for someone who wants to pick up some, and I stress “some”, innovation techniques. The book has a grab bag of techniques for helping you find new ideas.

That’s the first third of the book. The rest of it concentrates on the hard stuff, and this is where the book comes into its own. The hard stuff is getting the innovation accepted by the organisation and the marketplace. The tone is academic, and this is not aimed at cavalier entrepreneurs, but at anybody who wants to place a structure around his or her attempts at moving from the innovation stage to the production stage. This then is the strength of this book.
Requirements Engineering: From System Goals to UML Models to Software Specifications Axel van Lamsweerde, John Wiley, 2009

The publisher's summary follows: "presents both the current state of the art
in requirements engineering and a systematic method for engineering
high-quality requirements, broken down into four parts.  The first part
introduces fundamental concepts and principles including the aim and scope
of requirements engineering, the products and processes involved,
requirements qualities to aim at and flaws to avoid, and the critical role
of requirements engineering in system and software engineering.

The second part of the book is devoted to system modeling in the specific
context of engineering requirements. It presents a multi-view modeling
framework that integrates complementary techniques for modeling the
system-as-is and the system-to-be. The third part of the book reviews
goal-based reasoning techniques to support the various steps of the KAOS
method. The fourth part of the book goes beyond requirements engineering to
discuss the mapping from goal-oriented requirements to software
specifications and to software architecture."
Just Enough Requirements Management. Alan Davis, Dorset House, 2005.

Explores the effect of too little and too much requirements work and offers a way to spend the right amount of effort for your project. Davis’ advice on progressive prioritisation using triage is particularly useful.
Agile Software Development: the Cooperative Game – second edition. Alistair Cockburn, Addison-Wesley. 

"Coming of age for software developers means understanding that software is a cooperative effort, not something individuals do in isolation. This is a book that teams of software developers can thrive upon, full of sensible advice for a cooperative development approach." – Tom DeMarco
Adaptive Software Development: a Collaborative Approach to Managing Complex Systems. James Highsmith, Dorset House, 2000.

This book describes an adaptive development cycle, which includes a number of “learning loops”, each including speculation, elaboration and learning. I particularly like his emphasis on focusing all decisions around the project's mission and using that mission as a way of continually asking are we on the right track?
More About Software Requirements: Thorny Issues and Practical Advice. Karl Wiegers, Microsoft Press, 2005.

The author’s Software Requirements, Second Edition, is a popular book about mainstream requirements. Here he takes the subject further by describing practical techniques for gathering and managing the software requirements that help you meet project specifications and customer expectations.
Group Genius—the Creative Power of Collaboration. Keith Sawyer, Basic Books, 2007.
Sawyer is a psychologist and has studied the behaviour of improvisational jazz and theatre groups to understand why these groups are so innovative. The lessons from this book are that innovation is a group activity, and groups are better than individuals at producing that creative spark.

More Joel on Software: Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity. Joel Spolsky, Apress, 2008.

"…I was learning the hard way about how to be a publisher and probably spending way too much time looking at web sites and programming than I should have in response to that. Anyway, one day I came across this web site called Joel on Software, which was run by a guy with strong opinions and an unusual, clever writing style, along with a willingness to take on the conventional wisdom. In particular, he was writing this ongoing series about how bad most user interfaces were—mostly because programmers by and large knew, as Joel and I would say, using the same Yiddish–derived NYC vernacular that we both share, “bupkis” about what users really want. And I, like many, was hooked both by the series and the occasional random essay that Joel wrote. And then I had this epiphany: I'm a publisher, I like reading his stuff, why not turn it into a book?…"    — Gary Cornell, Cofounder, Apress

We assume you have already read the original Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity. Joel Spolsky. Apress, 2004. Joel is perhaps the most interesting commentator on most things software. He is worth reading for his insights and pronouncements. His web site, Joel on Software, is well worth a visit.

Requirements-Led Project Management: discovering David’s Slingshot. Suzanne Robertson and James Robertson, Addison Wesley, 2005.

'You'll find this book a treasure trove of experience-based guidelines and illustrative examples on how to get the requirements right on your project. These include guidelines and examples on treating the requirements as an investment activity in Chapter 2; getting the right people involved and understanding their cultures in Chapter 3; techniques for stimulating mutual learning and a shared vision among stakeholders in Chapter 4; the use of prototypes and simulations in Chapters 5 and 6; dealing with legacy systems in Chapter 7; and managing systems requirements, systems of systems requirements, and requirements processes in Chapters 9, 10, and 11. Each chapter concludes with a nicely balanced set of "What do I do right now?" and "What's the least that I can get away with?" checklists.'

'As a bottom line, the book does a wonderful job of lifting its readers from a focus on templates and objects to a focus on peopleÕs needs, capabilities, and ability to work together to achieve a shared vision of the requirements (and the design) for a system that will satisfy all their needs and constraints. I hope you have the opportunity to use its practices on your next project.'    — Barry Boehm

adobe Download a sample chapter.

The Elegant Solution: Toyota’s Formula for Mastering Innovation. Matthew May. Free Press, 2007.

May discusses how Toyota, one of the most innovative companies in the world today, goes about generating thousands of innovations each week. He points out that innovation at Toyota is generated by the workforce. It is interesting to note that while all the auto makers are in trouble because of the credit crunch, Toyota is in less trouble than most, and far more likely to be stronger in the aftermath.
How Breakthroughs Happen: the surprising truth about how companies innovate. Andrew Hargadon. Harvard Business School Press, 2003.  

Hargadon discusses the role of the technology brokers, and how they gather the raw materials for innovation. He argues—successfully in my opinion—that almost all innovations come about be recombining existing elements to make something new. For example, the iPod recombined a hard disk, a screen, MP3 and so on to make an innovative device. This book is worth reading to see how technology broking works in many different organisations.
Waltzing with Bears – Managing Risks on Software Projects. Tom DeMarco and Tim Lister. Dorset House, 2003.

"Running away from risk is a no-win proposition. Sometimes you come across a project that looks positively risk-free. In the past, you may have looked at such an endeavor as a 'slam dunk' and thanked your lucky stars to be given an easy project for a change. We've had the same reaction. What dummies we were. Those projects weren't worth doing at all."
The Ten Faces of Innovation: IDEO's Strategies for Defeating the Devil's Advocate and Driving Creativity Throughout Your Organization. Tom Kelley. Currency Books, 2005. 

Kelley is one of the founders of IDEO. Over time, the people at IDEO have observed ten people-centric roles that they use to encourage different innovative points of view. There is a discussion, along with real examples, about each role and how to develop one’s talents to adopt that point of view. The book has a website.

About Face 3, the Essentials of Interaction Design. Alan Cooper, Robert Reimann and David Cronin. Wiley Publishing Inc., 2007.

Cooper’s book is about designing products based on human goals. His take on personas is worth the price of the book alone, and there is a lot more besides.
The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail. Clayton Christensen. Harvard Business School Press 1997.

Christensen observed that market-leading companies frequently are overtaken by new entrants, and he wondered whether the conventional explanations (lack of agility, arrogance, etc.) really explained this pattern. He studied, among many others, the disk drive industry. He discovered that, contrary to popular belief, the incumbent leaders were the ones to take best advantage of nearly every technological advancement. The exceptions were few but crucial. They were characterized by not actually improving the product along the dimensions of performance valued by the mainstream customers of the market leaders. Consequently, the incumbents spent relatively less of their resources developing these technologies and finding a market for them. New entrants, who believed in the value of the technologies, took them on and sought out new markets that would value the advantages they brought. Over time, the new technologies improved at a rate far faster than the performance demands of the market leaders' customers. Eventually, the new technologies became adequate in all the performance dimensions on which they previously had been inferior, yet they retained their additional advantages. Cut to the chase: the new entrants drive the previous leaders out of the markets they once led.

This sounds at first like the old saw about incremental vs. breakthrough technology improvements, but it is not. Even breakthrough technologies were best exploited by incumbent market leaders, as long as they were breakthroughs along performance dimensions that their customers valued. One key insight is that the leaders were hostage to the preferences of their customers, even when those preferences led, ultimately, to the demise of the firm.

There is much more to say about this book, but I will stop here as it is time to go. I cannot overstate my recommendation for this masterpiece! — Steve McManamin

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Frederick Brooks. Addison-Wesley, 1995.

This book contains more material that is quoted today than any other software book I know.
Extreme Programming Explained: Embrace Change (second edition). Kent Beck and Cynthia Andres. Addison-Wesley, 2004.

There are some interesting ideas in XP. One is writing the test cases before writing the code – this is pretty much the same idea as fit criteria. Another is pair programming – two programmers on the one keyboard having to agree the code solution before releasing it.
Adrenaline Junkies and Template Zombies - Understanding Patterns of Project Behavior. Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson, Suzanne Robertson. Dorset House Publishing, 2008. Hanser, Germany, 2008. Also available as a Kindle book.

How project behavior patterns affect the work and the organisation. Winner of the 2009 Jolt Award in the general books category.

"Another masterpiece from the folks who brought you Peopleware. Anyone who has survived a software project or two will surely recognize many of these patterns and will be able to learn from most of them. Adrenaline Junkies and Template Zombies is a real joy."

— Joel Spolsky, author of Joel on Software.

"A remarkably compelling book that captures with vignette, anecdote and history, both the anthropology and sociology of software project dysfunction. There is the knowing and weary but not-yet-cynical voice of experience that will make project leaders, managers and participants flinch and wince with recognition."

Michael Schrage, MIT Media Lab

"I loved this book - it was by and large a really fun read. I laughed at all the chapter headings and at most of the descriptions of bad project behaviour (others were a bit sobering), and cheered for the examples of great behaviour. Why the laughter? Because I recognised all these patterns - and I'll be the first one to say that more than likely I'm guilty of behaving badly on a project or two!

What this book highlights is a really important fact - we're all human. And funnily enough, project teams are made up of humans, and our stakeholders are also humans. Humans don't always communicate very well - we don't listen, make up stories, lie, cheat, steal, stamp our feet. It's a wonder we get anything done at all. When we do, it's because we played fair, everyone got their say, knew what had to be done, by when and by whom.

More specifically for me, Chapter 67 "Phillips Head" is quite topical right now as it talks about how a great innovation doesn't always get accepted straight away. And in a similar vein, Chapter 68 "Predicting Innovation" describes how to ensure a team keeps developing good innovative ideas using iterations, whilst keeping anxious stakeholders appraised of predicted delivery dates.

If you want to know what pattern your project is following I'm pretty sure you are more than likely to find it in this book."

I should also mention it goes straight into my "re-read" pile.

— Desirée Purvis (née Chu), CBAP

"Congratulations on your book award. I too found it very useful and a real eye-opener for any business; a must-read for any
manager. Well done!"
— Gennaro Pastore, Quality Control Manager, Dunhill.

The Myths of Innovation. Scott Berkun. O'Reilly Media, 2007.

This is an excellent book worthy of any innovator's bookshelf. By debunking the myths of innovation (the lone inventor, people welcome change, etc.), Berkun gives us wonderful insights into the innovation process. Also check his web site.
Iconoclast - a neuroscientist reveals how to think differently. Gregory Berns. Harvard Business Press, 2008.

This is a  remarkable book in that Berns takes us inside to brain to show what happens when we think. More importantly, he discusses the brain's activities when we think in unconventional ways. The iconoclast - someone who does things others say are impossible - is usually an innovator. Indeed Berns gives us many examples of iconoclastic innovators.

His treatment of how our brains act is wonderfully revealing. For example, the brain is 'lazy' and tends to rely on experience to guess at what we are seeing. Or to put that another way, rather than process all the pixels it gets from the eyes, it uses what is already knows to make assumptions to fill in the rest of the frame. From this we conclude that if you want to be an iconoclast, you have to deny your brain's shortcuts and ask it to process the whole picture.

But the subtitle 'how to think differently' is a little disingenuous. Berns tells us how iconoclasts think in different circumstances, or more fairly, how our brains should be acting under certain stimuli. For example, how our brains should act when we see things, how our brains should react to fear, and so on. However, I found very little that told me how I can make my brain act like an iconocalast's. Perhaps I am being lazy - now that I understand what my brain is doing, I can persuade it to see things in a different light, the way an iconoclast would. -- jsr London, April 2009.

Discovering Requirements. 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.

Suzanne Robertson
Chamonix March 22, 2009

Problem Frames: analyzing and structuring software development problems. Michael Jackson

Jackson is back with a follow up to his landmark Software Requirements & Specifications. This time he has lent his wit and intelligence to analysing and structuring the kind of problems faced by the software developer. Jackson argues that software development is about solving problems where there are very few well-understood problems. The aeronautical engineer does not have to be told that the plane has to fly and carry passengers, and by the way, take off and land. But as software is so malleable, we are usually faced with problems that very little of the basis is known.

His inference is that you must start by asking: What kind of problem is this? What purpose is being served in the world? What behaviour and properties must the computer have to achieve that purpose? JacksonÕs problem analysis takes you from the level of identifying the problem to the level of making the descriptions needed to solve it.

The central idea of this book is to use problem frames in problem analysis and structure. A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions.

Jackson is always informative and thought-provoking. Not a bad combination.

Exploring Requirements: Quality Before Design. Donald Gause and Gerald Weinberg

This book has been around for quite a while, but continues to be one of the important books in the field. Gause and Weinberg explore the area of requirements that most people find hard - the ambiguities, the difficulties in understanding people, the little things that are said that cause the requirements person to completely misunderstand the user's intention. It is not hard, say G & W, to get what you ask for. The problem is asking for what you really want. And this is the crux of the book - how to think about requirements, how to understand what the user is saying, how to listen to what is really being said.

It is not just the content that causes this book to remain popular. Don and Jerry's style has a lot to do with that. They are witty and wise. They entertain you as you learn. The stories of the requirements for the Do Not Disturb and the Superchalk products are particularly engrossing. They make sure that you are provoked as you work through their other examples.

But I feel that the lasting legacy of this book is the authors' ability to discuss frankly how requirements gathering is not an easy task. It is a challenge for the analysts and their users, indeed for all the stakeholders. G & W also talk about the delight when the requirements analysts understand what the user is thinking, even when the user is not articulating his thoughts.

This book is essential reading for everybody in the field of requirements.

The Art of Innovation. Lessons in creativity from IDEO, America's leading design firm. Tom Kelley

In this book Tom Kelley, the brother of IDEO founder David Kelley, tells stories. And like good stories, we learn from them. Kelley sets out to teach us how IDEO come up with their great products - the original Apple mouse, the Palm V, Handspring Treo, and their Visor Edge, TiVo and countless others. Through his recounting of brainstorming sessions, prototyping efforts and other activities at IDEO, we learn how to do it ourselves.

Why is this important? In the software industry we must continually innovate, and yet we get little training in how to innovate. The lessons that Kelley teaches are applicable to software products ­ not just the flashy desktop products aimed at consumers, but also the day-to-day software that we build for in-house consumption. Try Kelley's book, you will find it enjoyable and valuable.

Requirements by Collaboration. Ellen Gottesdiener

With thanks to Ian Alexander for the following: It really isn't every day that someone writes a book that provides a completely fresh take on requirements. Ellen Gottesdiener has managed to do just that. This readable and practical book is visibly based on a wealth of direct experience of facilitating requirements workshops, and her message is focused exclusively on the power of the workshop approach. This does mean that this book isn't for every project - if you are working on a subsystem under a strict contract, there is little scope for collaborating with stakeholders to work out the requirements together. To her credit, Gottesdiener carefully points out the limits of her approach, and she is admirably well-read.

The book uses the language of Use Cases, and refers to other UML diagrams along the way. It also mentions software from time to time, but this is definitely a book that is useful in systems of all types - from civil engineering projects to personal music players.

There are parts of this book that benefit enormously from Gottesdiener's natural enthusiasm, and the simple fact that she is American. She is able to talk in a simple and effective way about making workshops fun; about drawing mandalas and using the 4 principles of the native American medicine wheel; even about using toys as prizes and holding warm-up exercises to get people into collaborative mood.

Even engineers who have been running workshops for years will find new insights, conceptual tools and techniques in this lively and welcome contribution. Every requirements engineer should have a copy in a handy place on their bookshelf.

Contextual Design: Defining Customer-centered Systems. Hugh Beyer and Karen Holtzblatt.

This is one of my favourites; it more Post-it notes sticking out of the top than any other on my bookshelf. That's because there are so many insights inside that I do not want to lose. Please do not be misled by the word "design" in the title. The important part of this book is about contextual inquiry, where the developers work with the users to understand the work needs before attempting to design anything. Beyer and Holtzblatt give us a raft-load of ideas on how to get close to the customer, and how to understand what is really going on.

Contextual Design places great faith in the customer data - information and understanding of the customers and how they work. "Without a clear understanding of your customers, based on real events rather than anecdotes, and captured explicitly, you have no criteria for deciding on one action or design decision over anotherÉ.. But customers cannot tell you the important aspects of their own work practice because they are implicit and unrecognized. ÉContextual Inquiry reveals the hidden aspects of the work practice; paper prototyping reveals how a particular design plays out in the real work context."

This book is highly recommended for business analysts, and anyone whose work is understanding work.

Mastering the Requirements Process second Edition. Suzanne and James Robertson. Addison-Wesley, 2006. 

"This is not only the best book on requirements gathering that I've found, it is one of the best books on *any* aspect of software development that I've ever read. It is clear, focussed, well-written, full of extremely powerful concepts, and illustrated with useful examples and formal models of all aspects of the requirements gathering process and requirements-related information. As a result, I not only gained tremendous insight into how to improve the requirements gathering process at our company, I also learned by clear example how to make best use of each of the modeling formalisms the authors recommend." Tony Stewart

Detailed treatment of how to discover requirements at linked levels of detail and write them consistently. From the perspective of innovation, this book provides the details on how to discover and define Business Events, Business Use Cases and Product Use Cases. All of these are useful inputs to the innovation process.

Download a sample chapter from Addison-Wesley Professional