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 a set of specifications you might consider creating as a business analyst.
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 a set of specifications you might consider creating as a business analyst.Stakeholder Analysis
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.
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.
Business Analysis Plan
It might seem like a redundant step – a plan for creating a plan? It’s true. 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.
It might seem like a redundant step – a plan for creating a plan? It’s true. 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.
Current State Analysis
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.
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.
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 aBusiness 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?
In an agile environment, these sort of questions might be answered in an epicformat.
(Before I forget, all of my requirements documentation templates, including a simple Scope Statement, are included in my Business Analyst Template Toolkit.)
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 aBusiness 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?
In an agile environment, these sort of questions might be answered in an epicformat.
(Before I forget, all of my requirements documentation templates, including a simple Scope Statement, are included in my Business Analyst Template Toolkit.)
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.
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.
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.
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.
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.
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.
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.
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.
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-datesystem documentation.
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-datesystem documentation.
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 agendasand 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.
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 agendasand 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.
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.
No comments:
Post a Comment