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.

Image of winning ticket.

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:

  • Who you should talk with to understand the business problem
  • Who can help flesh out the requirements
  • The individuals who can give you a range of perspectives

User stories

In an agile development environment, a user story is a document describing the functionality that a business system should provide, written from the perspective of an end-user/customer/client. 

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)

If the solution is software (not all solutions are), then the business analyst specifies the functional requirements for the project.

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.

Resources