Requirements Quality Is in the Eye of the Beholder
It doesn’t matter how good you think the requirements you write are. If they aren’t clear to other people, they need improvement.
Just as beauty is in the eye of the beholder, so too is quality. Regardless of what form your software requirements take, your team’s requirements deliverables have an audience of people who will use them to do their parts of the project work, as well as representatives of customers who will use the product. Those recipients — not the people who produce the requirements deliverables — are the right ones to assess their quality.
I could create a set of requirements that seems perfect to me. It contains everything it should and nothing it shouldn’t, the contents are organized logically, and all of the statements seem clear and understandable — to me. But if someone finds problems with my requirements, it doesn’t matter how good I think they are. The creators (business analysts) and consumers (architects, designers, developers, testers, and others) of these bodies of knowledge should agree on their contents, format, organization, style, and level of detail.
