Requirements are interface design
A requirement is not only documentation. It is the first interface people use to understand a system.
A regulatory change arrived as more than forty requirements. Every item was necessary, and together they described one algorithm.
The difficulty was not the regulation itself. It was the reading experience. Later rules depended on earlier ones; exceptions changed the meaning of previous statements. After a few pages, understanding the next sentence required holding the entire list in memory.
The logic was coherent. Its representation was not.
A list is useful when its items are independent. An algorithm contains precedence, dependency and exception. Hiding those relationships turns reasoning into recall.
Requirements are therefore an interface to the business logic. They shape the mental model used by analysts, developers and testers long before a customer sees the product.
Designing that interface may mean grouping rules, drawing a decision table, naming dependencies or separating the default path from exceptions. None of this removes business complexity. It makes the structure of that complexity visible.
Completeness is not enough. A requirement set also needs to help another person form an accurate model of the whole.