Tips for Quality Assuring Requirements

I was just brainstorming with myself on how to ensure the best possible quality assurance on requirements prior to locking them in.  This concept applies equally to a BRS v 1.0 as it does to this week's story cards.

Here is what I have got for you.  Your comments would be great to round out this idea.

We start with the principle that the requirements statement is being used by all parties to development as a baseline for understanding of what is to be constructed.  It should go without saying that documents anchor conversations and don't substitute them. Sadly it has to be said.

There are typically multiple stakeholders to each requirement or requirement set.  The general classes are the project sponsor, the users of the system, developers and testers.  You have not had a requirements specification properly quality assured if all these stakeholders haven't had a look and offered comment.

The next thing you need to ask is what's in it for them when reviewing your content.  Developers want to see an unambiguous and coherent vision with sufficient detail to get stuck in, testers want to be able to test things without having to intuit requirements, users want to know how it's going to affect their day to day lives, particularly without getting in the way of the rest of their job and sponsors are worried about money and gaol attainment.

What can you do to better manage quality into requirements statements?