Explore Documentation Types
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the role of documentation in a project.
- Describe some of the major document types created by business analysts.
The Winning Trifecta for the Successful Business Analyst
“There is more to knowing than just knowing.” ―Mokokoma Mokhonoana, Philosopher and Author
Remember Ian Lin, the VP of International Sales at Ursa Major? Well, he did the right thing by engaging a business analyst to help him achieve his goal. He’s now able to see and adjust his team’s quarterly forecast amount. The BA helped him achieve this outcome quickly and successfully.
By now you can probably guess how it happened: The business analyst applied her communication skills to elicit the needs from Ian (the stakeholder) and collaborate successfully on every level across teams. She had the product knowledge and the skills to attain the intended result. But there’s one more thing that the business analyst did that led to a successful conclusion: She used documentation as a tool to communicate and collaborate with stakeholders.
You’ve learned that communication skills are indispensable to a successful project. Good communication keeps information accessible and flowing between stakeholders, development teams, and project management teams. Collaboration is also key. Team members come with their own views, ideas, and objectives, and BAs need to collaborate effectively with all members in order to get alignment on the project. Then there is documentation. Effective communication, collaboration, and documentation together are the winning trifecta in the business analyst world. Together, they often result in a successful outcome.
Let’s take a look at some types of documents that business analysts compile and rely on.
Types of Documentation
The types of documentation you create depend on varied factors, including:
- Type of project
- The business need
- Stakeholder needs
- Assumptions
- Constraints
There’s a myriad of document types that can be important to a business analyst. They range from printed documents to information repositories to collections of screenshots to websites and blogs containing company and department information. For each project, you create and use only the types of documents that are most appropriate.
Let’s look at some specific examples. For other examples of documents that a business analyst creates, see the Resources section in this unit.
|
Document Type |
What It Is |
|
Glossary of terms |
This is a list of key terms and definitions that boosts understanding across teams involved in the project. |
|
RACI chart |
RACI stands for responsible, accountable, consulted, and informed. It’s a matrix that delineates who is responsible for what in the context of the business analysis effort. Responsible: A person who performs an activity or does the work. Accountable: A person who is ultimately accountable for the outcome Consulted: A person who needs to provide feedback or contribute to the activity. Informed: A person who needs to know of a decision or action. |
|
Interview and elicitation records |
These documents capture important information from stakeholders. |
|
Stakeholder analysis |
This document identifies:
|
|
User stories |
A user story describes the functionality that a business system should provide so that it can be developed. It is often called a ticket or work item. The format is “As a…. I want to… So that I can…” |
|
Use cases |
A use case identifies, defines, and organizes the system requirements from the perspective of a user. |
|
Business analysis plan |
This plan lists all the business analysis activities that will take place throughout the project. |
|
Current state analysis |
If the current business process or domain is not well understood, the BA analyzes and documents the current state before scoping a project to improve upon it. |
|
Scope statement specification |
This is the most fundamental deliverable on any project. It is a clear definition of what needs to be achieved and the work that must be done to deliver the project or product. |
|
Functional requirements specification (FRS) |
This is the business requirements that are defined from an end user or business perspective. It will specify the expected outcomes. |
|
System requirements specification (SRS) |
This document details how the complete system should function and enumerates hardware, software, and functional and behavioral requirements of the system. |
|
Gap analysis document |
This document describes the gaps between the current processes and the intended processes. |
|
Change request logs |
This document is a log of all the change requests in the project including date of request, requester, and any other key information. |
|
Wireframes and other visual documentation |
This document contains renderings of the user interface, often in the form of low-fidelity wireframes. |
|
Test plans, test cases, or user acceptance test plans |
These documents describe the test plans and detailed test cases that the team will use to validate the functional requirements. |
|
Change management |
This document describes the method for pushing out changes to the business. |
How to Think About Documentation
Business analysts create and update documents throughout the project lifecycle. Their documentation fulfills various project needs, is consumed by different types of stakeholders involved in a project, and is presented in varied formats and media.
Presenting Results
When presenting results, be sure to use a format that’s easy for everyone to understand. Choose a format that’s easy to update, as updates inevitably happen. This becomes your presentation model.
To decide on the best presentation model, ask yourself:
- Who is the target audience, and is the information appropriate for the audience?
- What do each of the stakeholders need, and how will they understand the information?
- What information is important to communicate?
- Are there any regulatory or contractual constraints to conform to?
Here are three formats for presenting information to stakeholders. Use just one or multiple formats depending on your answers to the questions above.
|
Format |
What It Is |
|
Formal Documentation |
This format is usually based on an organizational template and can include text, matrices, or diagrams. |
|
Informal Documentation |
This format may include text, matrices, or diagrams that are not part of a formal organizational process. |
|
Presentations |
This format is best for providing a high-level overview of goals, solutions, or information to support a decision. |
Let’s Wrap It Up
We’ve covered a lot of information about what a business analyst does and what skills make a business analyst successful. From collecting information and documenting it to communicating ideas and needs to collaborating with stakeholders, the business analyst plays a significant role in the project lifecycle. Don’t underestimate the power of this role when it comes to implementing a successful enterprise solution.