60 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.

My journey in the world of software development has been arduous and challenging.

One of the common struggles we all face is the overwhelming number of solutions available, making it impossible to fully grasp everything at a deep level.

Just when I thought I had mastered an approach and felt competent in it, a new shiny approach would emerge, demanding my immediate attention. It often felt like a never-ending race to keep up with the ever-evolving field.

This constant pursuit of staying relevant as a software engineer can be frustrating, as it feels like we are always lagging behind the rapidly advancing world. I discovered that knowledge of specific technologies, frameworks, or libraries does not easily transfer across different technology stacks. They are too specific and lack universality. It was then that I turned my focus to more general principles of software engineering.

I realized that there are fundamental engineering… show more.

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.

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.

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.

“Good agile testing is good context-driven testing applied in an agile context.”

I recall reading through the authors’ lessons on software testing at about the same time I dived into more agile topics. Lessons Learned in Software Testing helped me keep the connection towards more traditional contexts – more so since I was still working in a more traditional context.

With their more than 100 lessons some of them applied to me, others did not. I am sure, other readers will find the same in their context.