New Zealand
Business Analysis

CDP undertake a great deal of business intelligence business analysis. It’s like normal BA, but it is informed by our deep understanding of what makes for successful business intelligence projects. All projects benefit from good business analysis and business intelligence project are no exception. But business intelligence projects have some unique features that make the business analysis process distinctive. In particular, their iterative nature means that requirements gathering, analysis and architectural design are consequentially distinctive.

CDP provide business analysis services within the context of the IBM Solutions Implementation Methodology (SIM). It is a step-by-step guide to conducting a complete development lifecycle (analyse, design, build, deploy, operate). It describes activities, deliverables, roles and responsibilities, inputs, tools, tips and proven practices. The Methodology toolkit consists of multiple Roadmaps. Each Roadmap has a hierarchy of diagrams with Process Steps. Attached to these Process Steps are links to related documents (samples, templates, considerations, tips and proven practices).

Business analysts identify business needs and solutions to business problems. Business analysis has an overlap with requirements analysis. Some of the common techniques CDP use for requirements gathering include:

  • Brainstorming
  • Focus group
  • Interviews
  • Workshops
  • Reverse engineering
  • Surveys
  • User task analysis
  • Process mapping

Given the nature of business intelligence it is imperative that the solution is evaluated against a defined set of Business and Functional Requirements. The difference between Business and Functional requirements is as follows:

  • Business requirements describe what needs to be done to meet a business objective.
  • Functional requirements describe how the business requirement will be delivered by the system.

Business requirement documents:

  • Detail what needs to be delivered in any proposed solution for it to meet the business needs.
    However, it does not detail how any solution would deliver on those requirements
    or whether the functionality is even possible; this is the job of the functional requirement.
  • Record the criteria to measure the success of any solution that is recommended.
    If it is doubtful a requirement can be delivered then this will be noted in the requirement risks section.
  • Map to a set of functional requirements and a set of success criteria are recorded.
  • Describe the requirements to be delivered.
  • Cover the end to end solution and identify any possible risks in enough detail to ensure
    that the design can be completed.
  • Provide a clear understanding of the requirements, including any possible ambiguities.
  •  

The topics to be covered, amongst others, include:

  • Constraints.
  • Data requirements.
  • Risks.
  • Reporting requirements.
  • Training needs.
  • Business background.
  • Project success factors.
  • List of items that are in and out of scope.
  • Assumptions.
  • Dependencies.

Business intelligence projects work best when the requirements are not considered to be set in concrete. Ideally they would be, but the business intelligence world is not like that and they have to be revisited, revised and reiterated as projects progress. Your requirements gathering work needs to be thorough and you need to insist on getting exactly what you need to interviewees/participants, but you will recognise that business rules change over time and you are likely to have to alter your requirements. It is essential that iterations are built into the process.