Do you create a traditional Business Requirements Document to capture your business and/or functional requirements? Adding a few diagrams to your BRD can make it more impactful and easier to understand.
In this video, I demo 3 different diagrams that can easily be added to your BRD. And while a full-text transcript is available, you’ll want to check the video for an insider peek into our 3 examples from the Visual Model Sample Pack.
For those who like to read instead of watch, here’s the full text of the video:
Today, we’re here to talk about three diagrams that you can add to your business requirements document because BRDs can be long and difficult to understand.
Business Requirements Documents Can Be Text Heavy
While I personally no longer create BRDs, and our template toolkit does not include a BRD template, instead, we have a three-page statement, and then models for business process documents and use cases that are separate.
I know many of you do and you had a question about how your organization, or if your organization requires you to use a BRD template, how can you make it more user-friendly by adding some visual models to it?
Today, we’re going to demo a couple of diagrams. These are from our Visual Model Sample Pack. You can easily add to a BRD to make it more clear.
Add a System Context Diagram to a Business Requirements Document
The first one of these diagrams is called a system context diagram. This shows the central system under design and the primary ways information flows into and out of the system.
You see, here, we have a portal, and then we have the accounting system, internal system, email server, document management system. These are all showing how information goes back and forth between the central portal, which was the system under design, and then the other related systems. This is useful in the BRD because it can help you to show the big picture of the system and how it fits together with everything else in your organization.
It’s included in our three-page scope statement template that we offer at Bridging the Gap, and it’s included in a lot of different diagrams. It’s common diagram for business analysts to use because it brings a lot of clarity very quickly.
Add a Business Process Diagram to a Business Requirements Document
The second model you might look to create, and this one you might be familiar with is called a workflow diagram, or a business process flow diagram, or business process model. While you can create them at a low level of detail, this one is relatively detailed and dialed into a specific business process. You can also create them at a very high level to show the big picture of how the process related to the requirements in your BRD.
You can have a big picture high-level map in your BRD, and then, maybe, some supporting ones. If your BRD is comprehensive and includes all the requirements, you might include a workflow diagram for each key section of requirements that, essentially, is showing how those requirements fit together.
If you’re a higher level, then you could just have one that shows the big picture, and you can drill into those more detailed requirements than a business process model.
Add a Scope Model to a Business Requirements Document
The third thing that I would include is called a scope diagram, or any sort of diagram that shows, functionally, how you decompose or organize, the requirements.
The technique from A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is called functional decomposition. You might have more of a hierarchy than we have here, so, you could also show this as more of an organizational chart view where, maybe, job seekers have key functionality. You want to show the hierarchy between job seekers and applications, and resumes, and search. Things like that; employers, and reviewing applications, and what all the key functions employers do.
You could break this down in a hierarchy. Here, we were just showing the really big picture of what are the key features in the product platform. What are the key areas that we’re looking at and how do they…we weren’t even showing how they, really, together, we could, but we just chose to be abstract to get the big picture.
What’s inside the product platform, and what’s outside? There was a system context diagram field to this as well, even though it’s not modeled as system context diagram.
This, I would use to organize each area of my requirements. If I had a section on requirements for employers, and then a section on requirements for partners, this would be that visual model that shows the big picture, how is this document organized? How are the requirements in this document organized?
You want to look for a way to functionally organize your document and show how the business requirements or functional requirements fit within that and decompose the overall structure of your documentation.
Check Out the Visual Model Sample Pack for 22 Visual Models
These are swipe files. What you’re seeing here is the PDF. In our Visual Model Sample Pack, we have swipe files in the native format of each of the models. We have 22 different models covered. I’ve just been focusing on the visual here because it tends to be the most interesting. But inside that pack, you also get an overview of the model, a link to the BABOK® Guide, and why I created the model. All of these were created in my real-world work as a business analyst.
A description of the different elements of that model, different terminology that can be used, and how this fits in with business analysis techniques and terminology, when you would use it, and the step-by-step guide on how to create a similar model, and finally, what to watch out for.
These are common mistakes people make with this model and how that trips them up in their business analysis work.
Again, you can download the Visual Model Sample Pack from our website. It is a paid product. It’s $97. You get 22 of these PDF documents along with the actual source files that you can use right away to start creating these in your own business analysis work.
To recap, if you’re looking to add to your BRD, the three models I would suggest paying attention to make it more user-friendly are:
- The system context diagram.
- The process flow diagram to show either that high level or maybe several of them to show a lower level detail for each area of your business requirements document.
- Then the scope model, or something that shows, in general, how this document is organized and how are the requirements in this document organized.
Those are going to take you a long way to making a clearer document that’s easier for your stakeholders to understand, easier for you to review with your stakeholders, and get lots of buy-in on that as well.
Again, Laura Brandenburg from Bridging the Gap. Happy modeling.