What we're doing
The research into a research piece on best practices for requirements documents is underway. As anyone who has ever been responsible for requirements knows, there are two sides to this question:

• The requirements process. The overt part of requirements is the process of writing them. The subtler part of the process is figuring out the information needed for the audience. Development (including QA and documentation) might be the primary audience, but they're hardly the only ones.
• The work product. In other word, the actual requirements document. Or, in many cases, documents. For example, while there might be a template for feature requirements, it may link to related or supporting documents (personas, customer feedback, etc.)

How you can help
As with any type of research, the larger and more representative the sample, the better. Which means that you, Dear Reader, can help make this research project all that it can be. In this case, we need your help with that second aspect of requirements, the work product.

If you're willing to share your template for requirements, please send it (or them) along. We're definitely not interested in the content--just the template. We promise to keep the source of any archived requirements documents confidential.

• Samples of what you might have that we'd love to see include the following:
• The Word document for feature requirements.
• The data model for requirements maintained in a fancy-schmancy requirements tool.
• The standard format for use cases and user stories.
• The mock-ups used to depict requirements, if you don't keep traditional requirements.

You can send this information directly to me, tgrant@forrester.com. If you're not sure what to send, just ask.

Plus, if you're willing to be interviewed for the requirements process part of the story, please let me know,

What's in it for you
As always, we'll share the final report with you, once it's published.