61 Books Like The Quest for Software Requirements

Suzanne and James Robertson have been writing insightful books on software requirements for many years. This book covers all the important topics, including understanding the real problem, different techniques for exploring solutions, and numerous ways to communicate requirements effectively. I especially like their treatment of quality attribute requirements and defining “fit criteria” to judge whether a solution adequately addresses them.

The book includes a comprehensive requirements specification template to guide writing a rigorous and complete specification on projects for which that is valuable. I also appreciate their use of visual models both to communicate with the reader and to guide the reader in communicating requirements to project stakeholders. I do prefer my book Software Requirements, but this is an excellent choice as well by two authorities in the field.

Exploring requirements is more about communication than computing. Requirements elicitation often involves discussions between business analysts and user representatives or other project stakeholders in either one-on-one discussions or group workshops. Requirements by Collaboration presents a wealth of practical tools and techniques for planning and leading requirements development workshops. It’s packed full of useful tips, checklists, questions to ask, and activities to perform to make workshops effective and successful.

I especially like Gottesdiener’s “collaboration patterns,” eight techniques that a workshop facilitator can employ to help the group achieve its objectives. The pattern called Decide How to Decide is the first one that any group of collaborators should use: exactly how will we make decisions? If you expect to lead, or even participate in, requirements workshops, read this book first.

I recognized the value of use cases the first time I used them successfully on a project. Some years later I developed a 1-day training course on use cases. I read four of the most popular use case books then available, cover to cover, one right after the other. Use Cases: Requirements in Context did the best job of presenting a practical approach to applying the use case technique. 

Shifting the requirements focus from system features to a usage-centric viewpoint provides many benefits, and use cases are the best way I’ve found to approach that. They provide an organizational structure for grouping related information relating to how users will interact with the system to perform tasks. This book describes a solid way to apply the use case technique.

Many agile projects employ user stories as a way to represent requirements rather than a more traditional approach combining use cases and functional requirements. I favor the latter approach for several reasons. Nonetheless, user stories are well established in the agile development world, and if you wish to learn about them, there’s no better author to read than Mike Cohn. Cohn describes how to craft user stories well and how they fit into the agile development process.

Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. The descriptions of each principle are concise, whereas my 60 lessons in Software Development Pearls go into a great deal more detail and offer many practical techniques.

There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.

This book helped me set my initial approach to software development and I still periodically return to it for grounding.

An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.

I’ve found in this book many useful topics about low-level design which connected with my first recommendation (Code Complete). For instance, about creating functions not only as a tactic for reusing code, but more as a way to give clear meaning to parts of the code, and make it more readable. I was happy to find in these authors ideas I have been agreeing with for a long time.

Then there’s also the fact that this book provides several examples with code on how to make the design simpler to maintain, and clearly illustrates the S.O.L.I.D. principles.

I've found this book enlightening in many key areas of software development, and as I was reading it, I felt connected with the author (even though I've never met him, I could imagine us having a conversation about software engineering, and agreeing on pretty much everything).

It was a revealing book for me, in the sense that it gave a formal framework to several ideas I've noticed as a practitioner over the years. In that regard, I wish I'd come across this work way earlier in my career.

This book changed my entire perspective on writing the UI and UX of great software. Even the revised edition is a bit old but still has many valuable lessons to teach. Platt established many of the fundamental principles of writing usable and transparent software, and his book should be read not only by designers, but perhaps especially by programmers.

One way to craft lessons learned is in the form of recommended best practices (or, as I prefer, “good practices”). Best practices represent collected and distilled wisdom from many observers, many projects, and many years of experience. Rapid Development includes 27 best practices for software development, with one chapter devoted to each. Although the book was published more than 25 years ago, most of these are still relevant. Indeed, several of them have been incorporated into routine contemporary practices: evolutionary delivery, designing for change, timebox development, and requirements scrubbing. Techniques such as inspections, miniature milestones, principled negotiation, and reuse are perennially pertinent.