In two previous articles I’ve given you a general overview of what requirements writing is, how to get involved, and how to gather requirements. But, as you know, most work isn’t done in a vacuum, so here comes the hard part — you’ve produced your requirements and now you have to get them reviewed by the customer, and maybe by developers or user interaction specialists.

In my first requirements review, I learned how to be “professional” very quickly. I thought that as a technical writer I had plenty of experience with being rejected, but the review was a trial by fire. There’s no point in beating around the bush — having requirements reviewed can be very difficult, even if you’ve gone through the process several times.

As we all know, words can be interpreted differently and a bazillion questions can come up about what you present. As the requirements writer, you have to field all these questions, even if they’re asked repeatedly (and by the same person) and you’ll have to answer them again and again, even after you’ve drawn pictures, created diagrams, done PowerPoint presentations, conducted group interviews and discovery sessions…as you see, it can be aggravating.
 
While answering all these questions, it’s helpful to remember that questions will only uncover more details, and make your requirements and the end product better. Fielding questions with grace and alacrity will (hopefully) engender respect, trust, and willingness from your co-workers to volunteer information and, yes, ask more questions.

Most of all, better communication with the customer produces requirements that suit the customers’ needs and that, after all, is the point of the requirements.