The Business Representative is a member of the business community who represents the target users of the BI system being build and may ultimately have ownership of the final system. They are responsible for agreeing the scope with the project manager and producing the business case. A key role of the business representative is to approve the functional requirements of the solution.
These are primarily the analytical and reporting requirements but may also extend to other areas such as information governance, quality requirements, performance, service levels and security. A good business representative is one who understands the benefit that information management and analytics can bring to a business, who can see the benefit of having their team, department or business using Business Intelligence applications to drive out new business benefit or gain competitive advantage.
Towards the end of the project, the focus is on adoption of the solution into production. Part of this involves producing or approving the end user documentation and training strategy. Once the system is live, they are responsible for measuring or demonstrating the return on the investment and managing future change requests.
The Business Analyst team is responsible for gathering detailed functional requirements from the business and documenting these in functional specifications. Later on in the project Business Analysts typically manage user acceptance testing. As data plays a fundamental role on a BI projects one of the main activities of a BI Business Analyst is to identify and define the data items required by components of the solution including reports, dashboards and more complex analytics such as ad hoc data analysis. The Business Analyst works with members of the business team to identify the source systems that contain these data items and then to produce a definition of the data item that is agreed by all parties. This is documented in a data dictionary or metadata catalogue. This is an important document as it ensures that everyone on the project, in particular the data integration, data modelling and analytics teams, have a clear and universal understanding of the data.
A requirements priority matrix is used to prioritise the requirements and the Moscow method can be used here. Prioritisation is useful in order to know what features can be dropped from scope or delayed to a future release if a project is running late.
The Business Analyst acts as an intermediary between the business and IT and is required to be able to communicate with both, to be able to use and understand the jargon and acronyms used by each camp. On some projects, Business Analysts are expected to be able to use formal modelling languages such as UML.
Once the functional specifications have been produced and approved the Business Analyst focuses on solution adoption. In this phase the Business analyst produces training materials and user guides and also takes a coordinating role in user acceptance testing, ensuring that the tests accurately reflect the requirements defined in the functional specifications.
The deliverables of the Business Analyst include,
- Functional Specification Documents
- Requirements Priority Matrix
- Data Dictionary
- Training Strategy
- Training Materials
- User Guides
Source System SMEs, Source System Analysts
A Source System Subject Matter Expert (SME) is a contact who fully understands the source system and in particular the data and the data model.The Business Analyst and later Information Architects and data Modellers work with the SMEs to understand the source system and its data. If a Source System SME is not available then Source System Analysts can be employed to analyse the source system, typically working with the other project members to help answer their questions on the source system and its data. Data models or entity relationship diagrams are produced in order to document the source system data structures.
Interface Specifications define how data will be transferred between the source system and the data warehouse. There are two options: either the source system delivers data to the warehouse in flat files or the warehouse fetches data directly from the source system database. In both cases the Interface Specification is a contract between the two systems that defines the extent of the data being transferred, definition of data types, file formats, unique identifiers, estimated data volumes, frequency and schedule and any data security considerations. The interface specification is produced and agreed by the Source System SME and the Data Integration Architect.
- Source System Data Models or Entity Relationship Diagrams
- Interface specifications