Requirements are interface design
A requirement is not only documentation. It is the first interface people use to understand a system.
Recently, I worked on a legal change delivered as more than forty individual requirements.
None of them were unnecessary. Together, they described a single algorithm that had to be implemented as a whole. Every rule depended on the others, and the feature could only be considered correct if the entire regulation remained internally consistent.
What surprised me was not the complexity of the regulation. It was the experience of reading it.
After only a few requirements, I found myself repeatedly scrolling back to reconnect earlier rules with later exceptions. By the tenth requirement, understanding the next sentence depended on remembering the previous nine.
The algorithm itself was coherent.
Its representation was not.
Business logic rarely arrives in a form that can be understood immediately. We encounter it through documents, conversations, diagrams and software. Those representations shape the mental model we build long before implementation begins.
A linear list works well when every item is independent. Algorithms are different. They contain dependencies, precedence, exceptions and relationships. When those relationships remain implicit, understanding becomes a memory exercise instead of a reasoning exercise.
The document contained every rule required to implement the feature. What it did not provide was a structure that helped readers understand those rules as one coherent system.
That distinction matters.
Good interfaces do not reduce functionality. They reduce the effort required to understand it. Requirements deserve the same design attention.
Sometimes that means a decision table instead of a list. Sometimes it means grouping related rules. Sometimes it means making dependencies explicit rather than expecting readers to reconstruct them for themselves.
The goal is not to simplify the business.
The goal is to simplify the path towards understanding it.
Long before users experience the product, analysts, developers and testers experience its requirements.
That experience is design too.