Many problems we’ve traditionally had with understanding, communicating and implementing solutions for user’s needs are reduced or go away as agile development lets us shift our focus from requirements documents to frequent conversations about actual, current, needs.
Still, these things in no way mean that we should stop thinking about requirements, even written ones. We’ll still be facing them even when the terminology and the means of handling them change. And context is key, as always: if you must have very formal written documents, if you really must, well, then you must.
With no further ado, here are some books (see: it’s not a bad idea to write things down from time to time) that have helped me understand this aspect of communication in our projects.
- To begin with, we need to understand that at the core of the challenge of understanding user’s needs lies a deeper challenge: that of knowing what the problem really is. This is what Gerald Weinberg and Donald Gause explore in their entertaining little book Are Your Lights On?, a true must-read in this context.
- Next up, something completely different. Or not. While expressions like “requirements gathering” may have some believe that requirements are like pretty little flowers waiting around to be picked and catalogued by a jolly gatherer, this act of finding user needs is not seldom pretty challenging: we’re talking about facing and synthezing a multitude of opinions from a bunch of stakeholders, after all. So, we should be able to talk about potentially contentious issues in a productive way. In come the authors of Crucial Conversations, with their collection of principles for helping yourself keep even your challenging interactions with others sane.
- On a possibly less far-fetched side, Mike Cohn’s book on User Stories describes a middle ground between the often bloated use case format and the context-disabled IEEE-style “the system shall” requirements. Simple and usable, but beware: XP-people will sometimes angrily remind you that they, not Mike, invented user stories.
- In software projects, we have a long and sad history of estimating the cost of requirements, but not the value of them. Donald Reinertsen takes us one step beyond the (powerful and typically sufficient) product backlogs and teaches us how to bring back value to the table. See: Managing the Design Factory.
- I think I liked this next one too, even though a few years have passed since I last read. Since its Gerald Weinberg again, I’m not worried about recommending it: Exploring Requirements: Quality Before Design, by Mr Weinberg and Donald Gause.