What Requirements Documents Does A Business Analyst Create?

Are you working on your first project as a business analyst? Have you ever wondered exactly what requirements documents a business analyst creates for review by the business and technical teams?

While the requirements documents created for any specific project will heavily depend on the type of project, the needs and preferences of your business and technical stakeholders, and your organization’s business analysis standards, what follows is 10 different types of different types of requirements specifications you might consider creating as a business analyst.

#1 – Stakeholder Analysis

The first thing we need to figure out as a business analyst is who are stakeholders are, meaning who do we actually need to talk to to understand the business problem and flesh out the requirements.

Even if the business analyst doesn’t create a formal stakeholder analysis specification, you will need to determine who the sponsor and key business stakeholders for the project, the multiple perspectives you’ll want to bring in to the requirements, and discover anyone else who needs to be involved. On a technology project, stakeholders typically involve subject matter experts from the business and IT teams.

#2 – Business Analysis Plan

Next on the list is to create a business analysis plan. A business analyst will typically create a plan that outlines the elicitation, requirements analysis, and validation/verification efforts as well as clearly indicates who is responsible for what within the context of the business analysis effort.

The business analysis plan will often be driven by an organization’s business analysis methodology, which may be formal or informal.

#3 – Current State Analysis

Understanding the current state is a critical step in the business analysis process. If the current business process or business domain is not well understood, it may be necessary to analyze and document the current state before scoping a project to improve upon it. This could involve “as is” process documentation or an assessment of current capabilities.

#4 – Scope Statement Specification

This is the most fundamental deliverable on any project – a clear definition of the scope of the project or product. This specification might also be referred to as a Business Case, Vision Document or Business Requirements Document (though in practice, BRDs typically include many additional sections that would include the Functional Requirements, which I classify as a separate deliverable). In this requirements specification, you are essentially answering the following questions:

In an agile environment, these sort of questions might be answered in an epic format.
(Before I forget, all of my requirements documentation templates, including a simple Scope Statement, are included in my Business Analyst Template Toolkit.)

#5 – Functional Requirements Specification

If the solution is a software solution (not all solutions are), then the business analyst will specify the functional requirements for the project. These requirements specifications might also be referred to as software requirements, technical requirements, or system requirements. Functional requirements identify what the system does – how it functions – and typically are written at the level of what a given “user” can get the system to do. Functional Requirements can be captured in a wide variety of requirements deliverables.

For BAs without an IT background, this is the level at which you need to learn to understand and talk intelligently about “IT” – it’s about what the system can do for the business, not about how that system is built. If even if this level of understanding technology systems is not appealing, you are probably better off focusing on business process-focused BA roles.

#6 – Wireframes and Other Visual Documentation

Often times, functional requirements are accompanied by renderings of the user interface, most commonly in low-fidelity wireframes. A BA who is also a user experience designer may also be responsible for creating a high-fidelity prototype.

And if the rules behind the user interface are important, a user interface specification can be a handy spec to pull all the details together in context for your development team. Workflow diagrams are also commonly used to depict a functional or business process in a visual way, which facilitates a more efficient requirements approval process.

#7 – Information or Data Model Documentation

In addition to the user-facing functionality of the software, the business analyst may identify elements of the information model too. This could be at a conceptual level (which I tend to capture in a domain model) or a more detailed level using a data dictionary or data mapping specification.

#8 – Test Plans, Test Cases, or User Acceptance Test Plans

If the business analyst is involved in testing the software application, they may also create a test plan and detailed test cases to validate that the functional requirements are met. Often this task is handled by a dedicated Quality Assurance Engineer in which case the BA might be asked to review their plans. Even when basic functional testing is performed by QA, the BA may be involved in testing conducted by business subject matter experts. This is typically called User Acceptance Testing (UAT).  The BA may list out scenarios for the business stakeholders to walk through and may actually facilitate elements of the testing.

#9 – Change Management

While User Acceptance Testing gets the business community started down the path of embracing the changes to come, other deliverables may be necessary. These could include updated business procedures or business processes, checklists or work aids, or new training materials. Again, sometimes these deliverables and processes are covered by other groups. Towards the end of the project, the business analyst may also update the requirements deliverables to reflect the as-built functionality so that the team can start the next project working for up-to-date system documentation.

#10 – Throughout the Project

While ideally the business analysis and project management roles are filled by two different individuals, the business analyst is responsible for managing the requirements process and contributing to the project plan. Often this means maintaining a requirements issues list, contributing to the project implementation plan, and providing regular status updates. You’ll also be creating meeting agendas and typing up meeting notes to capture the results of your requirements discussions and may be involved in managing change requests as stakeholders discover updates to the requirements.

Choose Your Requirements Documents

By no means does a business analyst create every one of these requirements specifications for each project. Most BAs pick and choose the most appropriate specifications given the nature of their project and customize their templates based on stakeholder needs and project considerations.

>>Save Time on Your Next Requirements Document

TemplatesWould you like a starting point for approaching common business analyst work scenarios? Check out my Business Analyst Template Toolkit – all of my requirements templates are fully annotated and editable by you, giving you a great starting point for starting your next business analyst project or formalizing your work samples.

Click here to learn more about the BA Template Toolkit

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more