Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  Getting Your Business Analysis Deliverables Organized
Previous Previous
Next Next
New Post 3/27/2014 8:23 PM
User is offline Meta BA
19 posts
9th Level Poster

Getting Your Business Analysis Deliverables Organized 
Modified By Chris Adams  on 4/23/2014 1:33:10 PM)

 We have all seen lists of all kinds of different business analysis deliverables, what I never see is a "which one goes where" so I have broken down it down by large categories that represent the high level phases of business analysis. I'd like your opinions and thoughts because becoming a great professional is about learning from those greater than yourself! Help me make my mental model better!

Understanding The Business - Business Case 

  • This might include Enterprise Level Requirements
  • Scope diagrams (context diagrams)
  • High level solution evaluations

Planning Your Work - Business Analysis Plan 

  • This is where you find that all important activity and work breakdown structure
  • Stakeholder analysis would be done here also

Defining The Solution - Requirements Package 

Evaluating The Solution - Solution Validation

  • The deliverable here is either evaluting several potential solution options or...
  • Evalutation an already designed solution to see that it actually meets needs.


New Post 4/28/2014 2:13 PM
User is offline Stephanie Cracknell
1 posts
No Ranking

Re: Getting Your Business Analysis Deliverables Organized 

I think this is an excellent start. I think we need a bit more about the processes and techniques as well as the deliverables.

Also, I think we are missing some key elements here such as identifying stakeholders, eliciting requirements and communication.

I tend to focus my activities in line with the IIBA for best practice and tend to focus as below:

1. Understanding The Business (enterprise analysis) & Define Business Need: 

  • This might include Enterprise Level Requirements
  • Define scope of the proposed solution
  • Scope diagrams (context diagrams) , process modeling, scope modeling, organizational modeling
  • Define Business Case
  • High level solution evaluations ( I would not include this here, as I feel it is too soon, and would include it as part of determining the solution approach), at this stage you would really just document what was in scope and out of scope

Outputs: Business Need, required capabilities, solution approach, solution scope, Business Case

  • 2. Planning Your Work - Business Analysis Plan & Monitor (the approach to performing business analysis and quality of business analysis)
  • ID stakeholders, define roles & responsibilities
  • Estimate time for business analysis tasks.
  • Planning how the BA will communicate with stakeholders.
  • Planning how requirements will be approached, traced, & prioritized.
  • Determining the deliverables that the BA will produce throughout the lifecycle of the project
  • Defining process for carrying out business analysis (methodology of project can dictate)
  • Determining the metrics that will be used for monitoring business analysis work (if your organization does this)

Outputs: BA Approach, Stakeholder list with Roles & Responsibilities, BA Plans, BA Comms Plan, Requirements Mgmt Plan, BA performance assessment (not all organizations define metrics for BA performance)

3. Elicitation (this is a massive one that I feel needs to be called out)

  • Prepare for elicitation (document analysis, surveys, interface analysis etc)
  • Conduct Elicitation (interviews, reqs workshops, brainstorming, etc)
  • Document results of the ‘Conduct Elicitation’ step
  • Confirm results through interviews, observation

**Note: while the IIBA does not list this as an elicitation technique, I have found this very valuable for uncovering hidden requirements or implicit knowledge. While it is fine to use this when documenting requirements, it is helpful when preparing for elicitation, to prepare some use cases and run through them with the users to validate your knowledge, and to see during observation, whether this use case is valid or if it is missing steps. I also use use cases after my interviews, to confirm with the stakeholders, that I have understood the process correctly.

Outputs: Supporting materials, Elicitation Results, Requirements (Stated), Stakeholder concerns, Requirements (confirmed),

4. Requirements Management

  • Manage solution scope & requirements
  • Requirements Traceability (matrix)
  • Maintain reqs for re-use (if your organization does this)
  • Prepare requirements package
  • Communicate requirements via workshops or structured walkthroughs

Outputs: Requirements approved, Requirements Package (this may contain requirements for vendor selection RFI, RFQ, RFP)

5. Requirements Analysis (requires input from 1, 3, and 4)

  • Prioritize requirements (MOSCOW)
  • Organize requirements (data flow diagrams)
  • Model requirements (data modeling, interface analysis, process modeling, prototyping, use cases/user stories)
  • Define assumptions and constraints (Risk analysis)
  • Validate requirements with stakeholders (acceptance criteria)

Outputs: Requirements (prioritized and verified), Assumptions & Constraints

6. Solution Assessment & Validation

  • Assessment of proposed solution with acceptance criteria/vendor assessment
  • Assess organizational readiness (SWOT, Force field analysis)
  • Define transitional requirements (where needed) these temporary requirements would apply to things such as data migration and disappear once they have been completed
  • Validate solution (identify defects)
  • Evaluate solution (solution performance assessment)

Outputs: Assessments of proposed solution, organizational readiness assessment, Transitional requirements, Identified defects how these will be mitigated, Solution performance assessment

Best Regards



New Post 6/23/2014 7:09 PM
User is offline Meta BA
19 posts
9th Level Poster

Re: Getting Your Business Analysis Deliverables Organized 


Your confusing Deliverable with Work Product. Most of what you stated are considered work items. Which are things you produce to help you do your job as a business analyst. You can check the IIBA definitions on these two terms and how they differ.  

A deliverable is essentially valuable information that someone else wants out of you. For example, if you were a contractor, your client would expect a GAP analysis, Requirements document, or solution assessment.  They aren't the concerned on what you produce to get there like plans or elicitation results. 

Deliverables = the Job

Work Products = doing the job right


Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Getting Your Business Analysis Deliverables Organized

Community Blog - Latest Posts

In today's dynamic business environment, mastering effective business analysis techniques is crucial for organizations aiming to achieve sustainable growth and competitive advantage. Business analysis involves the systematic evaluation of business processes, requirements, and strategies to uncover insights that drive informed decision-making. T...
For many years now, a lot of people have found it difficult to identify the difference between Sankey diagrams and parallel sets. The two have made headlines, given that most people find it challenging to note what makes them different from each other. What remains to be undeniable is the fact that the Sankey diagram is among the top data visualiza...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...



Copyright 2006-2024 by Modern Analyst Media LLC