Share this
by LN Mishra, CBAP, CBDA, AAC & CCA on Jun 22, 2018 12:00:00 AM
As per BABoK, there are many deliverables that business analysts are responsible for. Many often new practitioners for business analysis get a bit confused about what do these documents actually contain.
This article lists 13 key business analysis deliverables for IT business analysts and a sample output as well.
It is perfectly possible for us to combine few documents if they belong to the same category and combined volume is manageable. Here is a short description of the deliverables and their contents:
BA Management related
1. Business analysis approach (High-level plan) - Contains activity, schedule, and effort for all BA activities
|
BA Activity |
Stakeholders |
Key Deliverable |
Target Date |
Est. effort |
Technique |
Status |
|
Obtain High-Level Requirements |
Senior Leadership |
Discussion notes |
10-Feb |
8 |
Workshop |
Open |
|
Work on BRD |
BA |
Draft BRD |
17-Feb |
24 |
NA |
Open |
|
Review and approval of BRD |
Senior Leadership |
Approved BRD |
24-Feb |
8 |
Review |
Open |
|
Obtain Detailed Requirements for Release 1 |
Domain SME |
Stakeholder expectations |
28-Feb |
16 |
Interview |
Open |
|
Requirements specifications for Release 1 |
BA |
SRS |
5-Mar |
24 |
NA |
Open |
|
Review and approval of requirements for Release 1 |
Domain SME |
Approved SRS |
10-Mar |
8 |
Review |
Open |
2. Stakeholder register - Contains details of stakeholders
|
Stakeholder Name |
Desig. |
Influence |
Impact |
Criticality |
|
Dave Richards |
CEO |
High |
Low |
V. High |
|
Mike Dent |
CDO |
High |
High |
V. High |
|
Dinesh Pandey |
Head-PMO |
High |
High |
V. High |
|
Lee Fung |
Head-IT |
High |
Medium |
High |
|
Adi Gururaj |
Head-HR |
Medium |
Low |
Medium |
|
Iqbal Mohammed |
Head-Administration |
Medium |
Low |
Medium |
|
Project Managers |
Medium |
High |
High |
|
|
Developers |
Low |
Low |
Low |
3. BA collaboration plan - How to collaborate with stakeholders
|
Criticality |
Email Update |
In-person Discussion |
Modes of Collaboration |
|
Very High |
Weekly |
Daily |
Email, In-person or Virtual meeting |
|
High |
Weekly |
Fort-nightly |
Email, In-person or Virtual meeting |
|
Medium |
Fort-nightly |
Monthly |
Email, In-person or Virtual meeting |
|
Low |
Monthly |
NA |
|
4. BA communication plan - Approach and schedule of BA communications
|
Trigger |
Aspect to be communicated |
Stakeholders to be communicated |
Modes of Collaboration |
|
Weekly |
Progress on business analysis |
Entire project team |
|
|
Delay in requirements approvals |
On need |
Steering team |
Email, or In-person or Virtual meeting |
|
Monthly |
BA Governance Summary |
Senior management |
Email and In-person or Virtual meeting |
|
Low |
Monthly |
NA |
|
5. Business analysis governance plan (Requirements management plan) - Requirements structure, traceability requirements, stakeholders list, roles, and responsibilities
6. Business case - Justification for investment
8. Traceability matrix - Linking requirements to the source, implementation artifacts.
|
Req ID |
Requirement |
Domain SME |
Use case |
Release # |
Dependent Req |
|
10000 |
Manage schedule |
Lily Vasantini |
ABCT SRS-Schedule Management - v12.0.xlsx |
3 |
|
|
20000 |
Manage defect |
Shalini Paul |
ABCT SRS-Defect Management - v12.0.xlsx |
2 |
|
|
30000 |
Manage risk |
Sara Lee |
ABCT SRS-Risk Management - v12.0.xlsx |
4 |
|
|
40000 |
Manage requirements |
Nori Masa |
ABCT SRS-Backlog Management - v12.0.xlsx |
5 |
|
|
50000 |
Track task effort |
Gajendra Battalla |
ABCT SRS-Effort Management - v12.0.xlsx |
1 |
Manage schedule |
|
60000 |
Manage audit and compliance |
Rebecca Randad |
ABCT SRS-Audit Management - v12.0.xlsx |
6 |
9. Solution validation report - A report indicating the proposed solution fulfilled desired business requirements
Requirements related
10. Business requirements - High-level requirements from a business (owner) perspective
11. Stakeholder requirements - Requirements elicited from stakeholders. Usually contain process flows, UIs, business rules, etc.
12. Solution requirements - Requirements developed for implementing the solution - Usually much bigger in size than the first two requirements. Can contain detailed UI, report models. Divided into 2 groups - Functional requirements and Non-functional requirements.
13. Transition requirements - Requirements needed to migrate from current system to new system (Typically data migration and training requirements).
Here is a sample image illustrating various types of requirements descriptions:
|
Type of requirement |
Example |
|
Business |
To enable digital commerce for the enterprise. |
|
Stakeholder (Sales Head) |
The system should have the ability to sell products in multiple geographies, currencies, time zones. Customers should be able to pay through PayPal, Bank transfer, Credit Card, Debit Card, BitCoin. Business rules |
|
Solution requirement |
Questions from the Developer's perspective What would the registration page look like? How many decimals for paid amount? |
We will be eager to know if you have found other deliverable which has helped you to do a better business analysis.
Happy reading and have a wonderful day.
Do provide your suggestions and comments.
About me
I work as a Principal Consultant and Trainer with Adaptive US, a leading requirement engineering solutions (training, consulting, and product) organization. You can reach me at LN@AdaptiveUS.com.
If you like my posts please like/share/comment and spread the word in your network.
No Comments Yet
Let us know what you think