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.
Requirements Document #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.
Requirements Document #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. If you don’t yet have a methodology, you can start with the 8-step business analysis process framework we teach at Bridging the Gap. Here’s a video walking you through it.
Requirements Document #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.
(Quick FYI – Click here to download our business process template for free.)
Requirements Document #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:
- What problem are we solving or what is the business need?
- What is the scope of the solution to the problem?
- Is the investment in solving the problem worth it?
Requirements Document #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.
- Use cases are a very common way to capture functional requirements.
- Other times the use cases are captured together in a Software Requirements Specification (SRS) , which may also include the non-functional requirements.
- In an agile environment, functional requirements are captured in user stories which are organized in a product backlog.
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.
Functional requirements can really trip analysts up – here’s an entire video on Functional Requirements.
Requirements Document #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.
Requirements Document #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.
While the way we teach it at Bridging the Gap is very business-oriented, data modeling can seem complicated. Here’s a data modeling tutorial:
Requirements Document #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.
Requirements Document #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.
Requirements Document #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 requirements templates based on stakeholder needs and project considerations.
Download Your Business Process Template Today
If you want to get started with your requirements documentation, I invite you to download our Business Process 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.
>> Click here to download the Business Process Template <<