Imagine you are ready to dive deep into a new project, but amidst the sea of information and tasks, you find yourself at a crossroads:
- What documents should you create to capture those crucial requirements?
- How can you ensure you’re fulfilling your role as a diligent business analyst?
The path to success lies in understanding the power of documentation. In this video, Laura shares examples of the five types of requirements documentation that every business analyst needs to start using, including:
- Scope Statement Specification
- Business Analysis Plan
- Business Process Documentation
- Functional Requirements Documentation
- Information or Data Requirements Documentation
Throughout this video, Laura mentions various free resources we have that will give you a jump start in your requirements documentation, you can download those at the links below:
>> Click here to download Business Process Template <<
>> Click here to download Use Case Template <<
Imagine this. You’re ready to do a deep dive into a new project as a business analyst, but amidst the sea of information and tasks at hand, you find yourself at a crossroads. Which documents should you actually create to capture these crucial requirements? How can you ensure that you’re fulfilling your role as a diligent business analyst?
The path to success really lies in understanding the power of documentation, not just as a create all the documents type of tool, but as an analysis and a thinking tool, and a helping the business make better decisions type of tool. Today I’m going to cover five types of requirements documentation that every business analyst needs to be aware of and start using on most of their projects.
Hi, I’m Laura Brandenburg from Bridging The Gap where we help you start, succeed and excel in your business analyst career.
Scope Statement Specification
We’re talking about five types of requirements documentation today. The very first one I want to talk to you about is the Scope Statement. This is the very first type of document that you want to create on just about any type of project. It defines the scope of the project.
This specification might also be referred to as a business case or a vision document, or a Business Requirements Document, although in practice, BRDs typically include many additional sections that would include functional requirements. I’m going to classify that as a separate deliverable. We’ll talk about that in a little bit.
In this requirement specification, the scope statement, you’re essentially answering the following questions:
- What problem are we solving?
- What’s the business need?
- What is the scope of the solution to that problem?
- How in a high level view are we solving that problem?
- What does the solution look like?
Then you’re really using both of those questions to get to this final question, which is:
Is the investment in solving that problem worth it? Is there going to be a positive ROI, or return on investment, in this project?
Now, in an agile environment, those sorts of questions might be answered in an epic format, but regardless of what format, what document, what type of methodology you’re using, you want to get clear on what problem you are solving and what the solution looks like at a high level so that you’re scoping that project and getting buy-in that you need from senior level stakeholders to move forward.
Business Analysis Plan
Once you have the scope, the next type of requirements documentation is the Business Analysis Plan. A business analyst will typically create a plan that outlines the elicitation, the requirements analysis, and the validation and verification efforts as well as clearly indicate who is responsible for what within the context of the business analysis effort.
The business analysis plan will often be driven by the organization’s business analysis or software development methodology. Again, that might be formal or it might be really informal. If you don’t yet have a methodology, you can start with the eight step business analysis process framework that we teach at Bridging the Gap. I did an entire video outlining this framework step by step. Be sure to watch that after you finish this video.
Business Process Documentation
With the scope defined and your plan in place, you know where you’re headed, it’s time to start digging into the details. Although there is always a temptation to jump right into the software solution or functional requirements, it almost always makes sense to first start with analyzing the business process.
- Part of analyzing the business process is a process flow diagram, which is also sometimes called a workflow diagram or a process map. It shows the big picture of how the overall process flows from a stakeholder or end user perspective. This is a type of visual model that’s a great way to elicit a lot of information and create a shared understanding of both your current state and your future state process relatively quickly.
Here’s an entire video on creating a great process map:
- To accompany your process flow diagram, you want to use this textual business process document. We teach this technique of textually modeling a business process in our online business analysis training courses at Bridging the Gap because it helps you capture more details and analyze the process in more depth. Often, a process flow diagram is a great way to get the big picture, but you’re going to overlook some nuances and some details that a textual template will help you think through. Often those issues or inconsistencies are really easy to glaze over with just a workflow diagram, and you are going to catch them when you do the more in-depth analysis using a business process template like this.
>>Click here to download the full template<<
- To help you in that process, we have a really valuable resource for you available at Bridging the Gap. Our business process template is designed to help you capture and analyze the intricacies of your business process. By using this template, you can uncover all of those hidden issues and gain a deeper understanding for your workflow. Click below to claim your free business process template download.
>> Click here to download Business Process Template <<
What’s really important in this third type of documentation, the business process documentation, is that you are getting a business perspective of both the current state, or as is business process, and your desired future state, or to be business process. This is going to help clarify, in even more detail, the specific problems that you need to solve using technology.
You can learn more about as is and to be business processes in the following videos:
Functional Requirements Documentation
Next up on the list, our fourth type of documentation, is functional requirements documentation.
If the solution is a software solution, not all solutions are, sometimes you can just update the business process to solve the business problem. We don’t always need to use technology, but very often we are leveraging technology as all are part of the solution. In that case, the business analyst is going to specify the functional requirements for the project. These are also known as the solution requirements, the software requirements, sometimes the technical requirements, or the system requirements.
Functional requirements identify what the system does, how it functions, and they are typically written at the level of what a given user, like an actual end user, a person, can get the system to do. It’s what they see in their interaction with the system that is a functional requirement.
There might be a lot of additional things happening behind the scenes. Those would be more technical system design type of requirements. A functional requirement would be something that an end user could experience in interacting with that software system. They can be captured in a wide variety of different requirements deliverables.
- The very first one that we love to teach, it’s one of my very favorite requirements modeling techniques, are called use cases. These are a very common way to capture a functional requirement. We teach use cases at Bridging the Gap, using the template that you see here. We do this because we find that use case analysis helps the BAs, again, identify otherwise missed requirements by getting really clear on that system user interaction. It’s a really key technique.
>> Click here to download Use Case Template <<
- To assist you in this process, we offer another great resource at no cost to you, which is our use case template. You can download the exact template that you see above. This is specifically designed to help you capture and document use cases effectively. By using this template, you can ensure that no requirement is missed and gain a lot of clarity on the interactions between the system and its users. Click below to claim your free use case template download.
>> Click here to download Use Case Template <<
- Other times use cases are captured together in a different type of document called a software requirements specification, or SRS, or a functional requirements document, FRD, those may also include non-functional requirements. They’re more of a list of requirements. The use cases though, because of the way they show the user system interaction, are really powerful analysis tools that help you think about what requirements you might otherwise miss.
- In an agile environment, functional requirements are typically captured in user stories, which are organized into a product backlog. You might still analyze the requirements and use cases to make sure you’re kind of keeping the thread of how all those user stories fit together in your product backlog.
You Don’t Need a Technology Background to Analyze Software Requirements
One thing I just want to mention here, for those of you who don’t have a technology background, this is the level at which you need to learn and understand how to talk intelligently about technology. It’s about what the system can do for the business, not about how the system is built. Even if this level of understanding technology systems is not appealing, you are probably better off focused on more business process focused business analyst roles.
I just want to highlight, you don’t need to understand how to code, how to run SQL queries, how to design the systems in order to get to this level of clarity that really gets business and technology users on the same page. This is more of an analytical thinking capability than a technical ability.
Throughout my experience, I’ve noticed that functional requirements can still be really challenging for many business analysts. There’s a layer of specificity that you need to get to, to really be effective at getting these right. That’s why I created a comprehensive video tutorial specifically on this topic. I highly recommend watching that video as well to gain valuable insights and clarity after finishing this video. You can click below to watch that video. It’s an excellent resource to deepen your understanding of functional requirements.
Information or Data Requirements Documentation
One fifth and final type of requirements documentation, and that is to capture the information or data requirements. In addition to the user facing functionality of the software, the business analyst may identify elements of the information model as well. There are a few common types of data requirements documentation.
- One of the very first is the glossary. This is used to define a common language and terminology. You were going to use this to get really crystal clear on what terminology your business is using, making sure that the way you use a term like “customer” or “account” or “order” in your business process, in your use case, is consistent and that all of your stakeholders have the same understanding of what that term means.
- The next really common data requirements model is an entity relationship diagram. This shows those key concepts that might end up in your glossary and how they relate to one another, what details are captured in the information system about each concept. For example, if you had an order, are you getting the order date? Are you getting links to specific products? That would be a relationship to another entity called a product. You’d have the order time, the shipping address, things like that. And where are those captured? That’s what your entity relationship diagram is showing. These can look really technical, but you can also do them at a very business abstract level view so they really show the business concepts and the business understanding of the information domain.
- The last thing I want to show you is called the data dictionary. It also fits into this category of data requirements documentation. It will go into the details then about the specific fields or attributes, such as how long can that field be? What type of information does it hold? Are there any validation or business rules?
- When you combine, you can elaborate and combine data dictionaries from multiple systems to show how fields from one system will map to another, either for a one-time system integration or a system migration project that would be one time where you’re moving data from one source to another. Or we’re using something like an API to show how the ongoing system integration works and how those fields map to one another. This is called data mapping. I’ve got an entire video on data mapping.
Again, while all of this data modeling stuff can seem really complicated and technical, the way we teach it at Bridging the Gap is very business oriented. In The Business Analyst Blueprint training program, you would learn each of these data modeling techniques as well as how to use system context diagrams to show the overall information or data flow for your project.
To get you started with an overview of data modeling, we also offer a free data modeling training course, which is a portion of our full-fledged data modeling training module.
Key Practice: Choose Your Requirements Documentation Intentionally
We just listed five categories of documentation and multiple different types of specifications you might use within each of those categories. By no means does a business analyst create every one of these specifications for each and every project. Most business analysts will pick and choose the most appropriate specifications given the nature of their project, and they’re going to customize those templates based on the stakeholder needs and project considerations.
You want to look at what is happening in your project and what is really needed to make the next decision. What’s even more important is that you have a clear and focused business analysis approach that enables you to be more strategic and proactive in terms of how you approach the project.
We’ve got a wealth of content dedicated to providing valuable tips and strategies and insights for business analysts like yourself to help you really be strategic and proactive as possible. We have new videos releasing here every week, but you’re going to have to subscribe to the BTG YouTube channel to stay in the loop with all of our new content.
Remember to claim our free use case template by clicking below. And f you don’t have a business analysis methodology nailed down yet, that is really the very next place to start.
Make sure to watch our eight step business analysis process framework video by clicking the video below.
I’ll see you over there.
Download Your Use Case Template Today
If you want to get started with your requirements documentation, I invite you to download our Use Case template (it’s free). You’ll learn the key elements that go into a business process model, and be able to kick-start your requirements documentation process.