I was talking about requirements with someone at work this week, and I mentioned the concept of anti requirements. It’s important to think about the things that you don’t want to see in your product, almost as important as the things that you do want. You can’t be exhaustive about anti requirements, but a few of them go a long way to clarify the bounds of the picture.

Requirements don’t have to be exhaustive. They paint a picture of what you want to build, so that others can work together to build it. You can scale the level of detail based on many factors, where the end goal is clarity and brevity. Capture the intent rather than every atom of detail.

There are many tools for capturing intent too. Requirements that are written in a single, unified, and highly-structured format are difficult to read. My telephone book accurately lists all of the people that live in my town, but it gives me no idea who they are, what they do, or what their story is. And, it’s hard to read front to back. Requirements are about the same: you need the background stories, andecdotes, and other bits to really empathise with the users and their domains. A good mix of colours and devices makes it easy to read too, which is handy if you expect other people to get involved.

And empathy is the key, it isn’t just a stale dissection of facts. You need to really dig the domain — dig into it, get into it, become part of it. The cold, scientific approach to requirements can only result in dead, disconnected applications. There is no life without understanding, there is no depth without feeling. If you can understand your user, then you have a chance of understanding what rocks their world.