These are the books that we recommend for requirements, innovation and general thinking work.
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:
Your Volere authors are contributors to 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.
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."
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.
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.
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.
"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."
"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 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.
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.
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.
'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
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.
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.
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
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.
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.