Writing good business requirements can be achieved by following a few simple guidelines. Keep in mind you are not going for a Pulitzer Prize winning document you are looking for a clean and effective way to communicate a business requirement, feature or function to a group of end consumers. These consumers can be wide a range of technical, business or even executive owners. Regardless of the type of consumer a good requirements document should make sense to all end users. The first step is to make sure you have a good template in place. A good template is simple yet effective method of communicating a requirement that is brief yet thorough. There are many sample templates online or you could even ask a colleague if they have an effective template that works. When researching the right template make sure you consider using headers with bold and italicized titles to clearly identify sections and subsections.
Next, list an outline of the document’s sections and content brainstorm all of the areas the document needs to cover. This outline will ultimately make up your table of contents. Good requirements docs will have a well structures table of contents preferably clickable to allow the consumer to quickly navigate to a particular section. Also, remember to cut all the filler and fluff. I often review and edit requirements documents that are 60 pages that should be 10 to 15 pages. This causes the consumer of the document, for instance a technical resource tasked with defining the design and ultimately development of a feature, to waste time and potentially misinterpret the requirement. Or worse, miss the requirement all together. Again, be brief yet thorough and get to the point quickly. An effective business requirements document often has diagrams and process flows to effectively communicate the flow of data or system process. These diagrams should be as accurate as possible. Consult with subject matter experts to ensure “AS IS” or “To Be” process flows and diagrams accurately depict the business requirement.
Another key is to create a document that is flexible and easily updated. Most requirements documents will be updated over the course of a project as requirements or goals shift. Make sure you have a version control system that captures all necessary approvals as versions are updated. Finally, always get another set of eyes on your requirements document. If possible have an engineer review the document (preferably not the engineer that will ultimately be the end consumer of the doc) and a business resource to review the document to ensure the information is clear, concise and grammatically correct. Follow these steps and you will be on your way to writing an effective business requirements document.
Summarizing recommended steps:
- Obtain a good template and use a strong headers and clear page breaks
- Start with an outline of content to be covered in the document
- Write a well structures table of contents with logical sections and subsections
- Be brief but thorough
- Cut the filler and fluff
- Know your audience
- Create a flexible document that can easily be added to
- Get another set of eyes on the doc