Requirements as risk mitigation

Really detailed use cases, and complete entity-relationship get a bad rap because they can be very complex to read, and are often not particularly good at describing the solution to end-users[1].

As a result they can get called a waste of time. We assume that requirements must be easily understood by business and IT stakeholders, and they seem to fail this rule - but most people persist with them out of a sort of gut-feel that they're useful despite being confusing to most users; and they're right to.

These sort of requirements mitigates your risk of internal incoherence, unwritten assumptions, and unexplored options. They may not be immediately readable by end-users but they ensure that the author has done a structured analysis of all the possibilities.

For example I had a project go wrong once because we assumed that each purchase order resulted in a single invoice, (e.g. a 1 to 1 relationship) when the reality was more complex (many to many). If a detailed ER diagram had been constructed the author would have raised this as explicit assumption. Similarly detailed use cases with very formal treatment of alternate paths are great at driving out odd little edge conditions.

Sometimes we produce requirements not to describe it to others, but to make sure we're across all the detail ourselves. This isn't the sort of work that gets users excited, but it does guard against something going wrong down the track.

[1] I've got some other posts about how to mitigate this, but that's another discussion