Most IT documents are horrible. I’m not talking about the bad grammar and the over-use of acronyms, but about they fact that they are fundamentally written for the computer and not the programmer.
Humans can hold a very limited number of items in working memory at the same time (four to seven), so writing requirements as a list with 842 items it bound to fail. The writers cannot keep the system in working memory, so they create an inconsistent and contradictory list. And the programmers can’t keep the requirements in working memory, so they will make bad implementation decisions.
Scrum tries to address this problem by using stories and iterative development. If you are stuck in a waterfall project model, re-structure your requirements list into a hierarchy where each requirement contains no more than seven sub-requirements.
Disastrous IT projects start with bad requirements. Make sure your requirements are human-readable.