Every project is, or should be, driven by user requirements. Requirements are the organization's way to articulate what needs to happen in order to provide value. Yet time and again requirements are looked at as something overly technical, mysterious, and too confusing to easily handle. Repeatedly, organizations use a template to ensure that requirements are defined early in the solution process. Sadly, the intended purposes are habitually defeated as these templates are filled with a lack of understanding for what information belongs in a given section, resulting in people creating documents that the authors themselves do not understand. Across many organizations requirements documents are created, reviewed, and even agreed to, that far too often are incoherent monstrosities saying nothing of actual value.
These documents may contain boiler-plated sections that are irrelevant to the job at hand, and can be full of bullet points referring to other sections that do not even exist within the document. It might not be unusual to find a specific point repeated as an "assumption," a "dependency" and a "requirement" (business wishes to be sure IT understands that the item is _really_ important). Why does this embracing of the incomprehensible happen? This literary defeat of rationality occurs for multiple reasons. Far too frequently, the writer of such a document ignores the holes within the document because, he/she knows what they mean and in his/her mind what is "on paper" is of less importance. These writers are simply trying to follow a format that they are given that is "too technical" for them to understand. While what is written makes no sense to these authors, the technical staff accepts the gibberish, so the document must be okay, right? The developers may have long since given up trying to develop based on the requirements document. The documents are often in such a state that anyone who says that they could develop something from just the document alone is clearly lying. But the development staff has learned the hard way that what is or is not in the document means nothing; any information of value will have to be pulled out of people's head at meetings or via email. Ultimately, the organization can tell the world that they have documented requirements, yet at the same time have a library of useless nonsense.
Requirements are not intended to be overly technical. In fact, the less technical they are the better. Regardless of the specific format chosen, what is critical is that what is written be comprehensible. The writer should often review what is being written from the perspective of, "If I knew nothing about this project, would this document inform me of the necessary functions?" If the writers find they cannot follow what is needed, then more rework of the content is necessary. The document can read like a children's story; "Papa Bear wants his porridge" is just fine. Starting off at such a primary level is a great beginning; complexity can be added as the more subtle issues are added. Once the writers loose sight of the direct link to the necessary concepts and clarity, they need to re-think what they are writing. If the business analyst does not fully understand any single statement, then something needs to be cleaned up. There are many vital points that requirements need to address - such as, is every individual requirement something that can be tested? Ideally, as one is testing the solution, those testers should be verifying that each requirement is met. Lists of other good characteristics for requirements can be easily found. Yes, communication is hard, and language is a very ambiguous tool. But incoherent documentation is worse than no documents at all because bad documents give the false impression that actual forethought has been applied to the process.