Our Current Top Books
These are the books that we recommend for requirements, innovation and general thinking work.
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 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."
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.
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.
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
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.
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.
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 gves 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 anotehr 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 and 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, that way an iconoclast would. -- jsr London, April 2009.
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.
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.
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.
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.
'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
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.
"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."
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?
"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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
This book contains more material that is quoted today than any other software book I know.