10 books like Use Cases

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.

Most discussions about requirements focus on functionality, which is what the users most obviously observe in a software system. However, user satisfaction also depends heavily on nonfunctional requirements, such as various quality characteristics the system exhibits: usability, availability, reliability, security, scalability, maintainability, and others.

The Quest for Software Requirements is the only book that focuses on nonfunctional requirements. It provides many questions a business analyst could ask during requirements elicitation to understand the stakeholders’ expectations for those all-important quality attributes. That’s an often-neglected aspect of requirements exploration that frequently leads to deficiencies that can be expensive to correct later in development or after the product is released. This book can help you avoid those unpleasant outcomes.

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.

This book is the software industry’s “bible” on how to start software development projects. 

It explains how to conduct up-front user research, before design, prototyping, and coding start. User research, followed by analysis of your findings, is how you determine requirements and figure out what features or improvements are needed and which are most important. 

This book presents a collection of methods for doing that. You probably won’t need every method described this book on every project, but having Holtzblatt and Beyer’s toolkit of user-research and analysis methods available when needed is valuable. 

I read it several times, and now several of its methods are baked into my normal design process.

There are a whole host of books about UX methods, but in our world of ever-advancing technology, there are few books that are really up to date with how to practice UX when the medium is no longer one-dimensional or even a physical product.

As AR and VR experiences are becoming more and more normal, I’ve appreciated being able to read a book that really captures the most recent evolution of UX methods towards a new virtual world of possibilities. 

This book captures lessons from many authors at Google, some of whom I’ve worked with over the years. The chapters on availability (7, 8, 9) were a revelation to me. I had no idea how Google approaches the topic of resilience and recovery in their systems, and I now think of the whole topic very differently. The biggest takeaway is how to think about the design of systems.

This is the API design patterns book. I love this book because it provides a comprehensive set of well-described and easy-to-reference API design patterns. It establishes a common domain vocabulary for discussing APIs. Each pattern comes with a UML diagram that gives it a level of exactness and makes it quickly parseable. Even without reading the full description of a pattern, I can look at its UML diagram and promptly get its essence.

The book is divided into three parts. There are multiple reading paths through the book—so I didn’t need to read it end to end in a sequential order. After going through the introduction to understand the structure and layout of the book, I could jump to the patterns and use case examples most relevant to my needs. The book also comes with a companion website. This is an excellent work and a handy reference for all API… show more.

This is one of those books that changed how I thought about and approached software development. First, the book addressed the pain points that I had run into so often: the problems with infrequent, manual deployments, the outages caused by changing configuration rather than source code, the nightmare of merge conflicts that you get from long-lived feature branches, and so on.

Then, it showed how to flip the typical software development process on its head through CI / CD, changing the default from “our software is broken, and we need an integration and release process to get it working” to “our software is always working, and we can release it at any time.” Once I read it, I could never go back to the old way.

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.