Business Requirements Document Template

Free template available for download

Formal Documentation Requirements

Almost every engineering firm or department has their standard way of doing things. Whether developed internally, handed down from a prime contractor/customer or built from an industry standard; engineering finds its strength from well defined processes. These processes, and many time contract requirements, necessitate consistent and formal documentation. Details may change from project to project or client to client but in most cases they are largely similar. Chalk it up to the Pareto principal if you wish but once you create a good document for your process there is a high likelihood that you will use most of it again and again; not too much changes. There are many organizations that intentionally set out to create templates that all users must use and conform to for outputs and reporting. Other templates are “created” by taking that last document which was well received and updating the content.

Templates are a good thing. A standard starting point saves time, speeds review due to understood layouts, and new team members to come up to speed more quickly with consistent expectations. If your organization doesn’t have good templates, I highly recommend you take the time to find and/or create them for your team. A few ideas to get started:

Don’t start from scratch unless you absolutely have to do so! A lot of people have had to do this before; steal, I mean, learn from their successes and failures.
Think about reuse. Look for reports you need to reproduce on a regular basis and start there. Many times these are less formal monthly reports or status updates but they take your time more often and finding efficiencies here will pay more regular and obvious dividends. If you have a final output document at the end of a two year project, you’ve got time to get around to that template later.
See if your management or customers have an example of a really good deliverable. Ultimately they are the ones who need to be satisfied with the outputs from your project so knowing what they like is a good place to start.
Don’t assume their favorite document is actually good. I’ve seen examples where they liked a document (or didn’t) due to the font, it had nice graphics etc. These are good bits of information on format but it doesn’t necessarily mean the structure fits the ultimate goal of what you are trying to communicate.
Look at the applications you already have available and see if they have templates or tools that can help. For instance, Cradle provides an optional schema that includes templates for a Stakeholder Requirements Document, Interface Requirements Document, Systems Requirements Document, Issues Reports, Test Plans and Verification Forms. If your tools have templates they likely tie into your data and could both save time and increase accuracy.
If at all possible don’t develop your template under a tight deliverable deadline. If you are going to use it over and over again you want it to be right. See if you can take a report recently submitted and drop that content into your new template. Ask the stakeholders if the format works better for them. This lets you refine the template and not get into debates on the content.
Look for potential automation. Many tools can output data in formats that could populate your templates more easily. The less information you have to type or cut and past the greater your accuracy and time saved.
Once you have the template fairly well tuned; take some time to create a version with comments on the intent of a section, background information, source information. This will help others understand how you came up with the template and how best to use it and potentially adjust it for their projects. Remember the 80/20 concept. Make sure they know what 20% can be adjusted and which parts should remain to keep consistency with your defined processes.

If you take the time to listen and develop strong templates, you can have a big impact on your team’s productivity and communication. It is well worth the effort.