Thursday, August 25, 2016

Common Business Analyst Deliverables

Common Business Analyst Deliverables



 Project Stage
 Document Name
 Brief Description
 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.
 Analysis
Business process mapping document
 It contains “as is” and “to be” 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.
 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 trace-ability.
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 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.