When writing requirements, how much consideration do you give to the reader?

Laura Brandau recently commented that high quality requirements are consumable.

Do you think about who needs to consume your requirements and why? Requirements that are hard to consume are ineffective. A complete and accurate requirements specification that nobody reads might as well be incomplete and inaccurate.

Communication not Documentation

The point of writing requirements down is to communicate - not just document. When creating a design or writing a piece of code, a developer needs to be able to understand which of the requirements are relevant to the task at hand. The same can be said of a quality analyst devising a test scenario or a business stakeholder reviewing your spec. These people, like most of us, can only keep about seven pieces of information in their heads at any given time. If your document fails to communicate what the reader needs to know at the time they need to know it, you've lost.

Use Cases: Consumable Requirements

Use cases go a long way towards making a large body of requirements more consumable. Yes, it's possible to write use cases that are hard to read - I know because I've done it myself. But ultimately, a use case describes how an actor goes about achieving just one goal using your system, and it does it in less than ten steps. The relevant non-behavioral requirements are captured while writing the use case and kept nearby. That way, a reader can understand those requirements in the proper context.

All of this leads to better communication, not just more documentation.

What do you think? Are use cases really more consumable?