A comprehensive guide to the major Business Analyst deliverables?

By | 20/08/2016
23 Comments

All business analysis activities should result in an artifact being produced.  These artifacts will vary depending upon the methodology and techniques being used.  In addition, there are several instances where similar documents may be known as different names. Variations have therefore also been included. The table below lists each type of document common to business analysis and a brief description.  It doesn’t necessarily mean they will all need to be used but they all have a purpose. There may be instances where one document merges one of more of these together.

Project stage Document name Brief description
Various Business Analysis approach The purpose is to:

  • To set out the business analysis involvement for the work concerned to set expectations, to feed into a wider plan and gain agreement on the deliverable’s.

For further information see the article:
Various Change control The purpose is to:

  • To have a process in place to manage changes when they happen.  Changes need to be prioritised, documented, communicated and implemented if approved.

For further information see the article:
Project initiation Vision document Or Business case Or Feasibility study The purpose is to:

  • Set out and gain consensus of the direction of the project and scope from the senior stakeholders.
  • Justifies the benefits and estimated costs.
  • It will provide enough evidence that the money is worth being spent, allow funding to be agreed or will show that it isn’t worth doing which then prevents further money being wasted.
  • It makes sure that the overall solution is agreed and that it will meet the business needs.

For further information see the article :
Analysis Business process mapping document It contains business process diagrams.  The purpose of it is to:

  • Understand the business processes.
  • Help identify the problems and opportunities for change.
  • Understand the scope of the requirements as each requirement should relate to a process.  This is why it should always be done before the business requirements document.
  • Business stakeholders are more likely to be know their business processes better than their requirements.  Therefore this is a better starting point and further justification for doing this first.

For further information see:
Analysis Business requirements document It contains a catalogue for all of the business requirements, a priority for each and a justification. The purpose of it is to:

  • Gain a consensus and understanding of all of the business requirements in scope for the project
  • Understand which of the requirements are mandatory to the extent that if they weren’t delivered the project would not be worth doing.
  • Pre-requisite for being able to start system requirements to ensure traceability.

For further information see:
Design Use case model Or Context diagram It contains a use case model which is a UML (Unified modelling language) tool or a context diagram. The purpose of it is to:

  • Identify system boundaries (which systems are in scope).
  • Identify the use cases (goals) for each of the systems in scope.  This is a summary of all of the things the system has to do.
  • Identify the human and system interfaces for each of the goals.
  • Allow estimation and planning depending upon the number of use cases and the complexity and size.
  • Pre-requisite for the system requirements.

For further information see:
Design System requirements document Or Functional requirements document Or Use cases Or User stories Or User story boards It contains all of the requirements that need to be met by the project systems in scope. The purpose of it is to:

  • Ensure the system requirements will meet each of the relevant business requirements and is understood and acceptable to the business stakeholders.
  • Ensure the system requirements are understood and acceptable to the IT stakeholders.
  • Allows developers to code the systems in scope according to the system requirements.

For further information see:
Design Non-functional requirements document It is really important that non-functional requirements are gathered early on and aren’t missed out. The purpose of it is to:

  • Set out non-functional requirements.  A non-functional requirement is a quality, constraint or behaviour that the system being built must meet.
  • To ensure the system being developed is adequate as involves a wider variety of IT stakeholders than the developers and a wider set of questions to the business stakeholders.  For example will the system have adequate enough capacity for the volumes of data anticipated.

For further information see:
Design Data mapping document This document focuses on data requirements. The purpose of it is to:

  • Identify all of the types of data required and agree a consensus of the names to be used and definitions.
  • Identify all of the relationships between each type of data and the data down to field/attribute level.
  • Provide a logical data model which can be used to work out a physical data model.
  • Ensure all of the data required can be met.

For further information see:
Design RFP RFP stands for Request for proposal. It is written when goods or services are required from an outside supplier where no products or expertise are currently available to meet the needs of the project within the company. The purpose of it is to:

  • Specify the needs and allows other companies to bid for the work.

For further information see:
Design Evaluation scoring matrix This is written in conjunction with the RFP.  The purpose of it is to:

  • Agree the success criteria to ensure the best vendor is selected.
  • Allow all scorers to follow the same success criteria.
  • Provide objectivity to the process.
Development Options paper If problems are encountered the business analyst can write an options paper.  The paper should be short and:

  • Specify the problems encountered and the reasons.
  • What the potential options are to resolve the problem.
  • Make a recommendation with reasons.

The purpose of it is to:

  • Allow problems and resolutions to be understood and agreed so the project can proceed.

For further information see:
Design / testing / implementation Gap analysis document This may be carried out at several stages to ensure that what is being produced traces back to:

  • The requirements.
  • The scope.
  • The benefits expected.

For further information see:
Testing / implementation Test strategy / test scripts Normally tester deliverables, however there may be occasions where the business analyst may contribute to writing the, be a reviewer, carry out testing or help co-ordinate with other testers and business users. The purpose of it is to:

  • Ensure all of the different business scenarios will be met by the system being changed.
Testing / implementation Training materials / new business processes Normally a trainer deliverable.  However there may be occasions where the business analyst may document new business processes and ensure training manuals are kept up to date.
Testing / implementation Handover documentation If the business analyst encounters several problems during the delivery process they may be best placed to put a handover document together for various parties to ensure resolutions have been formally captured.  This is particularly important if any new manual workarounds get introduced as a result.

Thoughts? Questions? Please share in the comments.

 

If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes.  The book is available from www.koganpage.com and all major print and e-book retailers.

Related Posts

23 thoughts on “A comprehensive guide to the major Business Analyst deliverables?”

  2. svitlana

    Thank you for this article. Could you recommend web resource where could be downloaded all these templates (Vision,RFP, etc)?

    Reply ↓
    1. Helen Winter Post author

      Hi, glad you like the article. I have a set of templates that I haven’t published yet. Is there any one in particular you are interested in? If you let me know I might be able to send you a copy.

      Regards,
      Helen

      Reply ↓
      1. timi ajiboye

        thank you helen for your article, please I would be interested in your templates please. thanks, as I am just getting in to the business analysis wolrd

        Reply ↓
      2. timi ajiboye

        thank you helen for your article, please I would be interested in your templates please. thanks, as I am just getting in to the business analysis wolrd

        Reply ↓
  3. Shweta Srivastava

    Yes Helen, I would be interested in the templates. Your article is amazing and very helpful

    Reply ↓
    1. Helen Winter Post author

      Hi Shweta,

      Thanks for your feedback. I will post them at some point but may take me a while as I’ve got other articles I want to focus on first. If there is a particular template you are interested in let me know and I’ll send it to you.

      Regards,

      Helen

      Reply ↓
  4. Vijay

    Thanks for this wonderful article. I’m new to being a BA and the only document I worked with are user stories maintained in Jira and Flow charts.

    So this article is pretty much what I needed.

    If it’s not too much to ask, I would be thankful if you can send me templates for each of the document you have described in this article.

    Thanks!

    Reply ↓
  5. Helen Winter Post author

    Thanks Vijay, I hadn’t realised how popular templates would be. I’ll look into uploading some templates in the near future.

    Regards,

    Helen

    Reply ↓
  6. Mrinalini Mohan

    Hi Helen, this high quality BA deliverable checklist is like a blueprint and covers all bases. Thank you for sharing!

    Do you have any blog or a forum where you also share from your vast experience many potential challenges a BA would face and possible solutions? That would be most helpful too.

    Mini

    Reply ↓
    1. Helen Winter Post author

      Hi Mini, thanks for your good feedback. I quite often make the articles I write about common problems I come across. My latest article is around the difficulties of getting people to read the deliverables we produce. If you visit businessbullet.co.uk and look at the contents you will be able to see all of the different types of articles written in one place. If there is any thing in particular you would like covering please let me know.
      Regards, Helen

      Reply ↓
  7. Grace

    hi Helen, understand the deliverables are more catered to a SDLC cycle. What’s your views if the project is based on SCRUM agile approach? What will be the deliverables that may be different?

    Reply ↓
    1. Helen Winter Post author

      Hi Grace,
      Some deliverables could be the same. For example the business analysis approach document and the vision document. An agile approach still needs business requirements or a product catalog to work from. In the design section scrum may make use of user stories for example. It depends on when a business analyst gets involved. I’ve assumed in the deliverable list they are involved from the beginning of a project before the design. Scrum is the design phase of a project onwards.

      Reply ↓
  8. Craig Thomson

    I was also wondering if these templates or at least structure guides for these documents were available? Great article and will be adopting at early stages of my BA career.

    Reply ↓
  9. Helen Winter Post author

    Thanks Craig, I have added some links explaining the structure of some of these documents such as what to include in a business requirements document. I have held back on publishing templates because there are some many methodologies that can be used. I will carry on publishing articles that are practical in nature and will update this article with additional links as relevant to help.

    Regards,
    Helen

    Reply ↓
  10. Lakshika Swarnamali

    Hi Helen,
    This helped me a lot. Thank you very much.

    Reply ↓
    1. Helen Winter Post author

      Really pleased to hear that.

      Thanks,

      Helen

      Reply ↓
  11. Hamish K

    Incredibly useful content – thank you.

    This rough framework / template is exactly what i was after having moved from supplier side consultancy to client side business analysis. I’m trying to cobble together and understanding of what should happen in what order, various tools / techniques as well as potentially introduce a base line from/against which future BA work could be based upon. This is the second article I’ve now read on your platform – very much appreciated.

    Reply ↓
    1. Helen Winter Post author

      Hi Hamesh,
      Thanks for your feedback and glad it helped you.
      Regards, Helen

      Reply ↓
  12. Richard

    Hi Helen,
    I am a Project Manager very keen to learn how the collaboration between a Project Manager and a Business Analyst can help make a project a success, and found this PMI White Paper on the subject very useful: https://www.pmi.org/learning/library/business-analyst-project-manager-collaboration-6512. However, in trying to understand, in detail, what the Business Analysis deliverables are, I found this pitched, in some instances, at too high a level, which is why I would like to join the chorus of those who have expressed their appreciation of your article.
    This White Paper, and a number of websites I could mention, detail that, amongst other deliverables, there 4 types of requirements that a Business Analyst should define:
    Business Requirements
    Stakeholder Requirements
    Solution Requirements (Functional and non-Functional)
    Transition Requirements
    I come from a background of deploying and subsequently migrating new IT systems and applications into the Operations and Maintenance (production/BAU) SDLC phase, and would like to know your thoughts as to whether or not a few words from yourself on the subject of Transition Requirements might be useful for those who read this article. To migrate new systems and applications into this phase, I have been required to complete a Cutover Into Production document which contains all the information that the Service Management team would need to help manage the new system or application in this environment. Such information would, for example, include details of the new system / application and details of who the 1st, 2nd and 3rd level BAU support teams are and how they may be contacted.
    Best regards.

    Reply ↓
    1. Helen Winter Post author

      Hi Richard,
      Glad you appreciate the article. Next time I update this I will add a reference about transition requirements. I will definitely read the article you sent me from PMI.

      Regards,

      Helen

      Reply ↓
  13. Richard McClenaghan

    Hi Helen

    Great article and glad I have come across it. I think you may be a kindred spirit – in terms of wanting to help support business analysis and bring some very useful information together 🙂

    Richard

    Reply ↓
    1. Helen Winter Post author

      Hi Richard,
      That sounds great. I’ve sent you a connection request on LinkedIn.
      Regards, Helen

      Reply ↓

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.