Much of my daily work revolves around gathering business requirements and writing documentation. If you have done any technical work, you are probably familiar with a business requirements document (BRD). The BRD summarizes the requirements that need to be configured/coded. Usually, there is also a separate technical document that details all the technical specifications required to achieve the expected outcome.

This weekend I have been working on a BRD for my second client, and I have a feeling the final product will be unlike anything the client has seen before. Most BRD’s simply list requirements, many of which are poorly defined. The requirements I’m documenting are clearly defined, and I am adding two elements that are missing from almost every BRD I’ve ever seen.

Element #1: Rationale for the requirements. BRD’s usually list the “what” but not the “why.” The why exists in people’s heads, various emails, or other documents that inevitably get lost over time. I am usually called in to clean up messes, and I always wonder why certain requirements were defined. The rationale is the explanation behind the requirements. It provides a record of why decisions were made for historical purposes, but it also forces you to think hard about the requirements and ensure they are accurately and clearly defined.

Element #2: Scenarios with expected outcome. I have been in countless meetings discussing technical requirements, and we always end up using a whiteboard or documenting examples to explain how the logic is supposed to work. For some reason, these scenarios/examples are almost never included in the BRD. Why not? These examples allow everyone to understand the logic and expected outcome, especially people who are not technical. It also provides a blueprint for all the testing scenarios. 

Maybe I should go on Fiverr and offer my services to help people write phenomenal BRDs.