High Level Information Requirements Deliverable Template

From MIKE2 Methodology

Contents 1 Introduction 1.1 Overview 1.2 Purpose of Document 1.3 Inputs to this Document 1.4 Output of this Document 1.5 In Scope 1.6 Out of Scope 1.7 Approach 1.8 Assumptions 1.9 Audience 2 Business Function/Area Summary 2.1 Business Function/Area Overview 2.2 Business Benefits 2.3 Business Function/Area Coverage 2.4 Business Area Prioritisation 2.5 Business Area Delivery Priorities 3 High Level Business Requirements 3.1 Business Area 1 3.1.1 Business Area Description 3.1.2 Business Requirements Summary 3.1.3 Benefits Rating 3.1.4 Complexity Rating 3.1.5 Business Area Dependencies 3.1.6 Functional Requirements 3.1.7 Historical Data Requirements 3.1.8 Business Issues 4 Appendices 4.1 Appendix A – Source Systems 4.2 Appendix B – Example Analysis 4.3 Appendix C – Example Reports

Introduction

Overview

<< Include a short paragraph about the Information Management Programme, Client Objectives and any other general information. >>

Purpose of Document

<< Include a statement defining the purpose of the document. This section should reference overview information on the company and well as relevant specifics at the division or department level. It should emphasize that the purpose of this document is to define the strategic business requirements and business issues that were identified during the stakeholder workshops/interviews/questionnaires. >>

Inputs to this Document

<< Describes the key artifacts that are input into this deliverable. The standard MIKE2.0 approach is listed below. >>

This document provides a template for the Defining the High Level Information Requirements task of the Overall Implementation Guide

The output from tasks from the Overall Business Strategy for Information Development activity act as input into this deliverable. These tasks included:

• Define Strategic Business Vision
• Define Strategic Critical Success Factors (CSFs)
• Define Strategic Key Performance Indicators (KPIs)

There are also document templates for these tasks.

Output of this Document

<< The output of this document should provide the business with a prioritised list of high-level business requirements, which can then be used to prepare a solution. The standard MIKE2.0 approach is listed below. >>

This document can then be used as an input to the following activities:

• Future State Vision for Information Management
• Strategic Requirements for BI Application Development
• Strategic Requirements for Technology Backplane Development
• Strategic Non-Functional Requirements
• Current-State Logical Architecture

In Scope

<< Clearly define the scope of this deliverable. >>

Out of Scope

<< Outline the items that are out of scope for this deliverable. >>

Approach

<<This section should provide the reader with the process through which the requirements were gathered. It should describe the approach used in gathering the business requirements. For example, were interview carried out as a series of interviews/workshops/ online questionnaires? It should also describe the business units that attended and the roles of the attendees along with names. >>

Assumptions

<< Insert any valid assumptions. For example, the stakeholders nominated for each Business Division/Function have a good understanding of the reporting and analytical requirements for their respective business areas and have expressed these requirements during the respective workshops. >>

Audience

<< Describe the intended audience for this document. Was this document produced for management, analyst and technical leads. >>

Business Function/Area Summary

<< Heading Depends on Type of Project. >> << This section (Business Area Summary) can potentially be ignored if the requirements are for a specific area. If it is for a specific Business Area then just capture the detail in the next Section. If there are multiple Business Functions and Business Areas to consider then presenting a summary and identifying scope of activities is helpful.

Note for difference between Business Function and Area see Figure 1 below. The key was to try and show a level of hierarchy within the business. >>

Business Function/Area Overview

<< Provide an overview of the business and the challenges that it faces. Articulate strategies that it\’s putting in place to address those challenges and how these requirements fit with that. >>

Business Benefits

<< Firstly, briefly describe the Business Vision/Direction, Business Drivers / Critical Success Factors and the Key Performance Indicators (KPIs) identified during the Business Exploration tasks listed in Section 1.2 above.

<<Secondly, describe the overall Business Benefits that will be gained from the implementation of the solution. This section summarises the benefits across the various business areas >>

Business Function/Area Coverage

<< The following diagram indicates the different business functions/areas that were identified. The purpose of the diagram is to show the readers the entire business and key areas that will be in scope or out of scope. The diagram can be tailored towards how one views their business, the purpose of the diagram is to illustrate the layers within the business i.e. HR = Business Function and Recruitment = Business Area. You will need to tailor the organisation or department concerned.

For Example: Consider the Finance Business function within a typical utilities industry, some examples of Business Areas within the Finance Business Function are Network Revenue, Revenue Assurance, Network Consumption, Capital Projects etc> The Business Area Diagram illustrates the Business Areas identified. The Business Area Diagram varies depending on the approach pursued i.e. an Enterprise Wide solution to Information Management versus Departmental Solution to Information Management. The fundamental difference between these 2 approaches is as follows:

• Enterprise Wide Solution: - This comprises of one or more Business Areas spread across multiple Business Functions of the Organisation, and involve interviewing Business users from various parts of the organisation. For Example an Enterprise Wide Solution may focus on the Business Areas included within the Finance, Marketing, Operations and HR Business Functions.

<< An example of a Business Area Diagram for an enterprise wide solution is provided below >> .

• Departmental Solution: - This comprises of one or more Business Areas associated with a single Business Function of the Organisation, and involve interviewing Business users from a single facet of the organisation. For Example a Departmental solution may focus on the Business Areas included within the Finance Business Function only.

<< An example of a Business Area Diagram for a departmental wide solution is provided below >> .

The table below provides an overview of the business areas identified. There is a more detailed definition for each of the business areas within the body of this document.

Code	Business Function	Business Area	Definition
<A101>	<Finance >	<Billing>	< This department handles all billing matters of the business >

Business Area Prioritisation

The business area prioritisation is based on a comparison of business benefit versus complexity. The business benefit rating is between 0 and 3:

• 0 = no business benefits
• 1 = minor business benefits
• 2 = major business benefits
• 3 = significant business benefits.

The complexity rating is also ranked between 0 and 3, where 0 = Complex and 3 = Simple.

<< This section can be tailored to other categories that the customer or the consultant wishes to use. Some examples of factors that could be used for determining the complexity ranking are listed as follows:

• The number of source systems relevant to the business area.
• The number and complexity of the reports associated with the business area.
• Dependencies on other business areas or projects.
• The complexity of the Business Rules associated with the business area. >>

<< Business areas receiving a high business benefit rating and low complexity ratings are ranked higher than those with opposite ratings. Workshops or interviews are normally held to identify a number of factors for determining the complexity ranking and thus decide on the business area ranking. >>

The table below summarises the benefits and overall complexity rating for each business area.

Code	Overall Ranking	Business Function	Business Area	Dependencies	Complexity Rating	Business Benefit Rating

<< Details of the business area benefits and complexity rating should be discussed in the details section that follows. By summarising the ratings a summary is derived and listed in the table above. Rules used in categorising should be captured to ensure there is clarity in how the ratings were categorised>>

Business Area Delivery Priorities

<< This section shows initially formulated priorities for delivery for each of the business areas identified. The number associated with each business area illustrates the order of delivery and the timeline shows the timeframe and scope of each of the Phases. At this stage, the timeline does not have system information (i.e. Source Systems) as it is a Business Requirements document. >

<< It is not necessary to have system information and thus system information is optional to the Business Delivery Priorities, since it is possible that a decision on potential source systems may not have been decided upon until source systems are analysed e.g. understanding things such as data quality. >

High Level Business Requirements

Business Area 1

<Repeat Section for each relevant Business Area. >

Business Area Description

<Provide a summarised description of the business area in terms of the key or main types of data focus, key metrics and any other relevant or generic information. >

Business Requirements Summary

The reporting and analytical requirements are outlined in the table below.

Reference ID	Requirements Title	Requirements Description	Priority Ranking (H, M, L)	Complexity Rating (H, M, L)	Benefit Rating (H,M,L)	Key Business Contact
			<< E.g. = If Complexity = L and Benefit = H then Priority= High>>

A Reference ID is used to uniquely identify a specific reporting/analytical reporting requirement within the business area.

Benefits Rating

<< These are the business benefits associated with the delivery of this business area. Examples of some common benefits include (but not limited to):

• Improved visibility of information associated with this business area
• Ability to measure the effectiveness of business processes via KPI’s
• Cost savings from being able to decommission a specific system or tool
• Reduction of duplicated efforts across the business in producing similar reports or analysis
• Time savings from automation
• Timely, accurate and trusted information from a single integrated source >>

<< The business benefits for Business Area 1 can include the following:

• Cost savings as a result of reducing data marts
• Cost savings in extracting and preparing information
• Additional revenue generated by increasing the timeliness of delivering the marketing campaigns

In some instances there will be a case where the customer will be able to provide details of what they term as having the most benefit, if possible capture this in a similar table as shown below >

Reference ID	Requirements Title	Cost Savings	Revenue Generation	Time Savings	Benefit Rating
					For eg. = if savings > $1m or revenue generation > $1m or Time Savings > 200hrs = High

Complexity Rating

<< The following table demonstrates how complexity of the requirement was derived.

The information to obtain may not be readily available, to ascertain complexity interviews may need to be carried out at SME (subject matter expert) level. An example of the logic used to derive complexity for requirements is show below. Other categories that are relevant to the respective industry or business can be used to derive the complexity rating, some examples of these are:

• Availability of metadata
• Data Quality Programmes exist within the organisation
• Source Systems are legacy systems with no documentation>

Reference ID	Requirements Title	\# of Source Systems	Availability of Documentation	Availability of Key SME\’s	Complexity Rating
					For e.g. = if \# of SS > 3 + No documentation available + No Key SME available then HIGH COMPLEXITY

Business Area Dependencies

<List the Business Area Dependencies if any, using delivery road map diagram above.>

Functional Requirements

<These are the functional requirements for satisfying or catering the analytical and reporting requirements of this business area For example these requirements could be around, How frequently should the data be updated (daily, weekly or monthly basis), the level of detailed required e.g. Information should be available at the lowest level / Transactional level so that a more thorough analysis can be performed, capture of monthly snapshots for performing a trend analysis, Measures required to capture the quality or effectiveness of a business process, etc. >

Historical Data Requirements

<In order to meet the analytical and reporting requirements associated with time variance, a certain degree of historical data is usually migrated from the source systems. The level of information provided in this section is quite brief, for example if billing transactions over the past 5 years need to be migrated, then the information included in this section could read as "Billing History – 5 Years">

The Business Area 1 business area requires the following amount of historical data:

Business Issues

< These are the business issues pertaining to the Business Area and are typically identified during workshops conducted with a specific Business area. Typical issues include:

• Lack of consistency in the processes capturing the operational data relevant
• Information available is inappropriate or insufficient for providing an accurate comparison or view of a situation. >>

The following business issues were identified during the requirements workshop:

Appendices

Appendix A – Source Systems

Name	Primary Source System	Description	Comments

Appendix B – Example Analysis

<Insert examples (if any) of analysis currently conducted by the business >

Appendix C – Example Reports

<Insert examples (if any) of reports currently used by the business >