There are many different elements that can go into a business requirements template, and I’ve found the terminology varies widely for how the different elements are labeled and described. It’s a shame there isn’t a greater consistency out there in what goes into a business requirements template, and unfortunately the Business Analysis Body of Knowledge (BABOK) doesn’t attempt to provide guidance in those regards. It simply states, among other things, that requirements must be documented, but it doesn’t say how to document them. I don’t think anyone would disagree with the need for documenting requirements, but it’s the documented requirements that are the most critical piece of all! It’s basically the contract between you and your client. So why, oh why, wouldn’t the BABOK include some guidance in creating a business requirements template? I scratch my head.
On the bright side, it gives me a reason to create a post on this topic. I will share my business requirements template with you, but first, allow me to share with you a little history on how it came into existence. I created it about 1.5 years ago based on what I know from experience needs to go into a business requirements document, and also what my organization expected to see in a requirements document. I went through documentation that predecessors had created, then I went to talk to people who had read and used that documentation, and I asked them what they liked and didn’t like about it. I also spoke to my manager to get her take on what was lacking in the business requirements documentation, and what her vision was on where business analysis was going for our organization. I learned so much about my organization’s stance on business analysis by doing this, and I can’t recommend doing this enough if you are considering creating a business requirements template for your organization.
Another important point to raise about the business requirements template I’ve created is that I do a peer review of it about every six months with fellow business analysts who have been using it. We talk about what we like and what we don’t like about it, what could be improved, what can be removed, and any new sections that we would like to add. The reason I do this peer review every six months is because I feel a template should not be a static document. That’s not to say it should be changed frequently, whenever the mood strikes you. If you do that, then you defeat the purpose of having a template in the first place, which is consistency in business requirements documentation. Rather, reviewing the template on an intermittent basis, about every six months or so, and carefully considering the various elements of the document is essential to ensure that the template continues to meet the needs of your organization, as the business of your organization continues to evolve.
In regards to the business requirements template that I created, there are a few things to keep in mind:
- I work in the IT industry, so the requirements documentation is tailored for an IT project. A requirements document for, say, the construction industry may be quite different.
- My organization supports enterprise business applications, so any projects that we undertake almost always require reports of some kind, hence the section called General Reporting Requirements.
- There are no sections for data modeling. This is because in my organization, we do not consider this be the role of the Business Analyst. We have Technical Architects who perform data modeling.
- This is not a technical specifications document. It contains sections for stating the business requirements, and in practice, I may include some high-level mock-ups of functionality in the appendix, if needed, but that’s as technical as it gets in my documentation. This is because in my organization, Technical Architects create their own technical/design specifications based on their assessment of the business requirements documentation.
- In the sign-off section at the end, you will see I list a space for the Project Sponsor or Functional Lead (SME) and the Technical Lead. Here I have a confession to make: so far, I haven’t been able to get documentation formally signed off (meaning ink to paper) by either of these parties. We don’t have a rigid sign-off process established in my organization. The most I’ve gotten so far is a verbal agreement or an email confirmation. My vision is to one day reach a comfort level where both parties can sign off the requirements documentation without hesitation. Long story short, we’re not there yet, and perhaps we’ll never be. I’ve got a long post brewing in my head on this topic. Once I figure out my stance on this subject, it will appear.
- I use italics throughout my template to provide instructions on how each section should be used. These comments should be removed in the final document.
Now that my preamble is out of the way, here is the link to my template, followed by a summary of it’s key elements:
The following list identifies what I feel are the key elements of any business requirements template for an IT project:
- The project overview, including a list of project stakeholders/contributors, in-scope deliverables, and out-of-scope items. Including some of the project documentation in the business requirements is important to keep the requirements focused on the goals of the project.
- Common acronyms, names, and their descriptions. Acronyms have a way of multiplying like bunnies. Sure, they’re great for reducing how much you have to type or talk, but they can be a nightmare for anyone new to the project or organization.
- The existing process(es). In Lean methodology, this is referred to as the Current State. Please don’t underestimate the importance of documenting the existing process, or let your client talk you out of documenting it because they don’t see the need for explaining what they used to do. Understanding the existing process, and the problems associated with it, has implications on the priority of the requirements, the analysis of the requirements, and the solutions that are proposed. Don’t overlook it!
- The detailed requirements. This is where you dig into the minute details of your requirements. In my requirements documentation, I always use the items listed in the In-Scope Deliverables section as the parent requirements in this section, and they are prefixed with PREQ-X.X. This creates the necessary tracing to identify where each requirement is coming from, as you don’t want to stray beyond the scope of the project. Child requirements are prefixed with CREQ-X.X. Be sure to state each individual requirement separately, ID’d accordingly, and don’t bundle them into long, wordy paragraphs.
- The business rules. Any rules affecting how a piece of functionality works need to be listed in the business rules section. The business rules specify the limits for expected behaviour.
There are many other elements that you could add to your requirements documentation, and you will have to make the judgement call on those other elements based on your analysis of your own organization. I would suggest you Google “business requirements template”, find a few other templates that you like, and pick out elements you think would be appropriate for your organization. It might take some trial and error, but this shouldn’t deter you. Ask your clients for feedback once you’ve started using a new template, and adjust the template as necessary.
I welcome thoughts from my readers on what other elements you feel are critical to a business requirements template. Please leave any such comments or questions below and I will respond.