BI Solution Development and Lifecycle Management

Introduction

Business intelligence (BI) is often described as the process of converting data into information that supports decisions. In practice, however, a BI dashboard, semantic model, report, or analytical application is not a one-time product. It is an organisational information service that must be discovered, designed, built, tested, adopted, monitored, improved, and eventually retired. Its value depends not only on visual appearance, but also on data quality, usability, performance, governance, security, and alignment with business decisions.

BI solution development therefore requires a lifecycle approach. A lifecycle provides a disciplined sequence of activities while still allowing iteration. Requirements change as stakeholders see prototypes; data limitations become visible during development; users identify new questions during acceptance testing; and usage evidence may reveal that a technically correct dashboard is not influencing decisions. Effective BI teams respond to these discoveries through controlled iteration rather than treating the initial specification as permanently complete.

This chapter presents a practical lifecycle covering discovery, prototyping, development, testing, user acceptance, deployment, documentation, version control, performance optimisation, maintenance, and impact evaluation. It is intended for analysts and BI professionals who must contribute to the full life of a solution rather than only create charts.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain why BI solutions require iterative lifecycle management.
2. Translate business decisions into measurable BI requirements.
3. Design and evaluate BI prototypes.
4. Apply disciplined practices for development, testing, deployment, and version control.
5. Diagnose common performance and data-quality problems.
6. Prepare documentation that supports operation, governance, and adoption.
7. Evaluate the business impact and lifecycle health of a BI solution.
8. Identify ethical, security, privacy, and accountability risks in BI delivery.

1. The BI Lifecycle as an Iterative System

A traditional systems-development view presents stages in a linear sequence: requirements, design, construction, testing, and implementation. This model is useful for identifying responsibilities, but it is too rigid for many BI projects. BI requirements are frequently ambiguous, data sources are imperfect, and stakeholders often cannot articulate what they need until they see a working representation.

An iterative BI lifecycle combines stage discipline with repeated learning cycles. A typical cycle is:

discover → prototype → develop → test → accept → deploy → monitor → improve

The cycle is not necessarily circular in a simplistic sense. Governance gates, approvals, and release controls are needed between stages. Nevertheless, feedback may send the team back to an earlier activity. For example, a failed data-quality test may require a revised source definition, while poor user adoption may require a redesigned workflow rather than a cosmetic change to the dashboard.

A useful distinction is between a project lifecycle and a product lifecycle. The project lifecycle ends when an agreed solution is delivered. The product lifecycle continues through operation, enhancement, support, impact assessment, and retirement. BI teams should manage dashboards and semantic models as products with owners, users, service expectations, and measurable outcomes.

1.1 Value, quality, and risk dimensions

A BI solution should be evaluated across several dimensions:

These dimensions can conflict. For example, storing detailed data may improve analytical flexibility but increase privacy risk and query cost. A successful lifecycle makes such trade-offs explicit.

2. Discovery: Starting with Decisions Rather Than Charts

Discovery establishes why the solution is needed, who will use it, what decisions it will support, and whether the required data exists. A weak discovery phase often produces a dashboard containing attractive but irrelevant metrics. A strong discovery phase identifies decision processes and defines what evidence is required at each point.

2.1 Stakeholder and decision analysis

Stakeholder interviews should explore:

• the decisions users make;
• the frequency and timing of those decisions;
• current information sources and workarounds;
• definitions of important terms;
• acceptable levels of delay and error;
• actions that should follow particular findings;
• regulatory, commercial, or confidentiality constraints.

A stakeholder is not simply a person who requests a chart. The stakeholder may be a decision owner, data owner, subject-matter expert, operational user, executive sponsor, compliance officer, or technical operator. These roles may have different and competing priorities.

A decision statement is more useful than a vague requirement. For example:

Regional sales managers need to identify products with declining weekly demand early enough to adjust replenishment and promotional activity.

This statement can be converted into measures, dimensions, thresholds, refresh requirements, and expected actions. It also permits evaluation: if managers cannot identify declining products or do not change replenishment decisions, the solution is not achieving its intended purpose.

2.2 Scope and feasibility

Discovery should define an initial minimum viable product (MVP). The MVP is not an unfinished or careless product; it is the smallest governed solution capable of testing the main value proposition. Scope should distinguish:

• essential measures and dimensions;
• desirable enhancements;
• excluded requirements;
• data sources and ownership;
• refresh frequency;
• user groups and access rules;
• success criteria;
• dependencies and risks.

A feasibility assessment considers data availability, data granularity, historical coverage, licensing, integration effort, privacy restrictions, skills, and operating cost. A requested metric may be conceptually meaningful but impossible to calculate reliably if the source does not capture the relevant event or time period.

2.3 Requirements and acceptance criteria

Requirements should be written so that they can be tested. A functional requirement might state: “The dashboard shall allow a regional manager to filter sales by region, product category, and week.” A non-functional requirement might state: “The summary page shall load within five seconds for the agreed test population under normal operating conditions.”

Acceptance criteria should specify the expected result, not merely the presence of a feature. For a revenue measure, criteria may include the formula, treatment of returns, currency conversion, time zone, and reconciliation source. Ambiguous terms such as “real time,” “high performance,” and “accurate” must be replaced by operational definitions.

3. Prototyping and Co-Design

A prototype is a deliberately limited representation used to learn. It may be a paper sketch, wireframe, low-fidelity interactive mock-up, or working report connected to sample data. Prototypes reduce the cost of discovering misunderstandings before extensive engineering effort has been invested.

3.1 Prototype objectives

A prototype may test:

• whether the page structure matches the user’s workflow;
• whether users understand metric names and visual encodings;
• whether the proposed filters answer common questions;
• whether a decision can be completed without excessive navigation;
• whether the required level of detail is available;
• whether the visual design creates misleading interpretations.

A prototype should have an explicit learning objective. “Create a dashboard” is not a prototype objective; “test whether supervisors can locate late orders and identify the responsible distribution centre” is one.

3.2 Designing for comprehension

Visualisation should support a sequence of questions: What is happening? Where and when is it happening? Why might it be happening? What action is available? Excessive decoration, ambiguous colour, inconsistent scales, and unnecessary chart types impair comprehension.

Important design practices include:

• use titles that state the analytical question;
• label values and units clearly;
• use consistent definitions and colour meanings;
• provide suitable defaults rather than empty screens;
• show comparison periods or targets where relevant;
• distinguish missing data from zero values;
• provide drill-through only where it supports a real task;
• design for accessibility, including colour contrast and non-colour cues.

User observation is more reliable than asking users whether they “like” a prototype. In a short usability session, give users realistic tasks and record completion, errors, questions, and time taken. Feedback should be classified as a defect, a requirement change, a usability issue, or a training need.

4. Development: From Prototype to Governed Product

Development converts an agreed design into data pipelines, models, calculations, reports, security roles, deployment settings, and operational procedures. The technical architecture will vary, but the responsibilities are broadly similar.

4.1 Data and semantic modelling

A robust BI model separates source acquisition, transformation, analytical modelling, and presentation. Common activities include:

1. ingesting data from approved sources;
2. profiling fields, keys, nulls, duplicates, and value ranges;
3. standardising formats and business rules;
4. creating fact and dimension structures where appropriate;
5. defining measures in a shared semantic layer;
6. applying row-level or object-level security;
7. exposing only certified fields and calculations to report authors.

A single source of truth does not necessarily mean one physical database. It means that an agreed business concept has an authoritative definition and controlled implementation. If “active customer” is calculated differently in three reports, users may obtain technically consistent but organisationally contradictory answers.

Measure definitions should identify numerator, denominator, filters, exclusions, time basis, currency, and aggregation behaviour. For example, a rate calculated by averaging store-level percentages may differ from a rate calculated from total counts. The correct method depends on the business meaning and population structure.

4.2 Data-quality rules

Data-quality controls should be implemented close to the data, not left entirely to visual inspection. Typical rules test:

• uniqueness of identifiers;
• referential integrity between facts and dimensions;
• completeness of required fields;
• valid dates and categorical values;
• duplicate transactions;
• unexpected volume changes;
• reconciliation to a trusted control total.

A simple completeness rate for a field can be expressed as:

The formula assumes that “expected values” has been defined consistently and that null status is an appropriate proxy for missingness. It does not establish accuracy: a populated field may still contain an incorrect value.

4.3 Calculation example: defect density

Suppose a BI release contains 18 confirmed defects after testing and 12,000 lines of transformation and calculation code. Defect density is often reported as defects per thousand lines of code (KLOC):

This measure is only meaningful when the organisation defines what counts as a defect, when defects are counted, and how code volume is measured. It should not be used to compare teams mechanically across different tools or types of work. In low-code BI environments, model complexity, number of measures, data volume, and test cases may be more informative than lines of code.

5. Testing as Evidence, Not Ceremony

Testing establishes whether the solution meets requirements and is safe to release. Testing should be risk-based: high-impact measures, access controls, financial totals, and data-refresh processes deserve more extensive testing than low-risk formatting details.

5.1 Levels of BI testing

Unit testing examines a transformation, calculation, query, or component in isolation. For example, a date transformation may be tested with leap years, time-zone boundaries, and invalid dates.

Integration testing examines interactions among sources, pipelines, models, security rules, and reports. It can reveal mismatched keys, timing dependencies, or incorrect data types.

Data reconciliation compares BI results with an approved source or control total. Differences must be explained, not automatically treated as errors; legitimate differences may result from timing, scope, or business-rule differences.

Performance testing measures response time, refresh duration, concurrency, resource use, and failure recovery under defined conditions.

Security testing verifies that users can see what they should see and cannot see what they should not see. Testing should include boundary roles, inactive users, exported data, and shared links.

Regression testing repeats critical tests after a change. A change to a common date table or measure can affect many reports even if the edited report appears correct.

5.2 Test cases and traceability

A useful test case includes an identifier, requirement, preconditions, input data, procedure, expected result, actual result, evidence, tester, and status. A requirements traceability matrix links each requirement to design elements, test cases, defects, and acceptance evidence. Traceability is particularly important in regulated or financially sensitive contexts.

A defect should be recorded with severity, reproducibility, affected component, business impact, owner, and resolution. Severity and priority are different: severity describes impact, while priority describes urgency in the release context.

6. User Acceptance and Organisational Readiness

User acceptance testing (UAT) is a business-led assessment that the solution supports real work. It is not a substitute for technical testing, and it should not be the first time users encounter the product.

UAT participants should represent intended roles and realistic data conditions. They should perform agreed scenarios, such as identifying an exception, explaining a variance, exporting an approved detail set, or taking a corrective action. The acceptance decision should be documented as accepted, accepted with known limitations, or rejected pending remediation.

Readiness extends beyond the software. It includes:

• named business and technical owners;
• communication of purpose and scope;
• training or embedded guidance;
• support channels and escalation routes;
• data definitions and known limitations;
• access provisioning;
• operating procedures;
• a plan for replacing or retiring old reports.

A technically successful release can fail if users continue relying on spreadsheets because the BI product is not embedded into meetings, workflows, and accountability structures.

7. Deployment, Release Control, and Version Management

Deployment moves a tested solution into an environment where users can access it. Mature teams separate development, test, and production environments. Environment separation reduces the risk that unfinished changes affect operational users.

A release plan should identify the release scope, dependencies, migration steps, validation checks, communication, rollback approach, and responsible persons. A rollback plan is essential when changes affect critical reporting or automated decisions.

7.1 Version control

Version control records changes to code, queries, configuration, model definitions, documentation, and where practical, report artefacts. A repository should support:

• a clear branching or change-management strategy;
• meaningful commit messages;
• peer review;
• tagged releases;
• separation of credentials from source code;
• reproducible deployment;
• audit history.

A practical workflow is to create a small change branch, review the change, run automated and manual tests, merge it into a controlled integration branch, deploy to test, obtain approval, and promote the release. The exact tooling is less important than traceability and repeatability.

Configuration should be externalised where possible. Connection strings, workspace identifiers, refresh schedules, and feature flags may differ by environment and should not be hard-coded into transformation logic. Secrets must be stored in an approved secret-management facility, not in notebooks, screenshots, or repositories.

8. Documentation and Knowledge Transfer

Documentation is an operational control, not an administrative afterthought. It reduces dependency on individual developers and supports audit, maintenance, onboarding, and incident response.

A useful BI documentation set includes:

Documentation should be versioned alongside the solution where practical. It should state the refresh timestamp, data coverage, exclusions, interpretation cautions, and contact route. A dashboard without these details can create false confidence, particularly when users mistake an old refresh for current information.

9. Performance Optimisation

Performance should be managed through measurement rather than intuition. First establish a baseline: page-load time, query duration, refresh duration, data volume, concurrency, and resource consumption. Then identify the bottleneck using query plans, workload monitoring, logs, or platform diagnostics.

Common optimisation approaches include:

• reducing unnecessary columns and rows;
• selecting an appropriate grain;
• creating efficient keys and relationships;
• using star-schema principles where suitable;
• pre-aggregating frequently used summaries;
• partitioning historical data;
• applying incremental refresh;
• reducing high-cardinality fields in interactive visuals;
• avoiding repeated or expensive calculations;
• limiting excessive visual queries on one page;
• improving source indexes and extraction logic;
• choosing import, direct-query, or hybrid modes according to workload.

Optimisation involves trade-offs. Pre-aggregation can improve response time but reduce detail. Caching can improve speed but introduce staleness. Removing fields can reduce model size but limit analysis. Every optimisation should preserve semantic correctness and document its freshness implications.

A service-level measure such as availability can be defined as:

The formula assumes that agreed service time and unplanned downtime are defined consistently. Planned maintenance may be excluded if the service agreement states so. Availability does not measure accuracy or user value; a dashboard can be available and still be wrong or unusable.

10. Maintenance, Monitoring, and Incident Management

After deployment, the BI solution enters an operational stage. Maintenance includes corrective changes for defects, adaptive changes for source or regulatory changes, perfective changes for improvements, and preventive changes that reduce future failure.

Monitoring should cover at least four areas:

1. Pipeline health: failures, delays, row counts, schema changes, and freshness.
2. Data quality: nulls, duplicates, invalid values, reconciliation differences, and anomalies.
3. Technical service: query performance, refresh duration, capacity, availability, and concurrency.
4. Product use: active users, frequently used features, search behaviour, exports, and abandonment.

Alert thresholds should be actionable. An alert that fires for every small variation will be ignored; an alert with no owner will not improve reliability. Incidents should be classified, communicated, resolved, and reviewed for root causes. A post-incident review should examine not only the immediate error but also why controls failed to detect or prevent it.

Change requests should be assessed for impact on definitions, historical comparability, security, performance, downstream reports, and user training. A seemingly minor change to a dimension or calculation may alter historical trends and executive decisions.

11. Impact Evaluation and Benefits Realisation

Delivery metrics such as number of pages, visuals, or releases do not prove business value. Impact evaluation asks whether the solution changed information access, behaviour, decisions, process efficiency, or outcomes.

Possible measures include:

• reduction in time spent preparing recurring reports;
• increased use of certified information in decision meetings;
• faster identification and resolution of exceptions;
• reduced duplicate or conflicting reports;
• improved forecast, service, or operational outcomes;
• user-reported confidence and task success;
• cost avoided through automation.

A simple benefit-cost ratio can be expressed as:

Benefits and costs must use the same valuation basis and time period. Relevant costs may include development, licences, infrastructure, training, support, and change management. Estimated benefits should state assumptions and avoid claiming that every observed improvement was caused by the BI solution. External factors, managerial changes, seasonality, and broader process improvements may also influence outcomes.

For a more credible evaluation, establish a baseline before release and compare it with post-release evidence. Where feasible, use matched teams, phased rollout, or repeated measurements. Qualitative evidence is also important: interviews may reveal that a dashboard changed meeting agendas even when a single numerical outcome cannot be attributed confidently.

12. Illustrative Case: Regional Distribution Performance Hub

This is a fictional illustrative case.

Background

Northstar Distribution operates six warehouses and supplies retail outlets across three regions. Managers received weekly spreadsheets assembled from warehouse, order, and transport systems. The spreadsheets used different definitions of “late delivery” and were often distributed two or three days after the relevant week.

Problem

Senior management wanted a common view of order fulfilment, but the initial request for “a real-time dashboard” was too vague. Interviews revealed three distinct decisions: warehouse supervisors needed to manage picking backlogs during the day; regional managers needed to investigate late deliveries each morning; and executives needed a monthly view of service performance.

Analysis and approach

The BI team defined three user journeys and agreed that an hourly refresh was sufficient for supervisors, while executive reporting could use a daily certified snapshot. The team created a prototype using two weeks of data. During usability sessions, supervisors could see the late-order count but could not identify whether the cause was picking, loading, or carrier delay. The data model was therefore extended to include operational status events.

A shared definition was approved:

A delivery is late when the confirmed delivery timestamp is later than the promised delivery timestamp, excluding orders cancelled before dispatch.

The team documented the definition, created data-quality checks for missing promised timestamps, and reconciled weekly totals to the transport system. Row-level security restricted regional managers to their assigned regions. The release was deployed through separate development, test, and production environments, with a rollback copy of the prior report.

Testing found that a detailed order table caused slow page loads. The team retained detail for drill-through but used an aggregated daily summary for the main performance page. This improved response time while preserving investigative capability.

Outcome

After six weeks, the solution showed strong adoption in morning regional meetings. Managers reported that they could identify repeated carrier delays without manually combining spreadsheets. The team did not claim that the dashboard alone improved delivery performance. Instead, it established a baseline, tracked corrective actions, and planned a three-month impact review.

Learning points

The case illustrates that lifecycle success depends on decision discovery, shared definitions, prototype testing, model design, security, performance trade-offs, controlled deployment, and post-release evaluation. The most valuable output was not a set of charts but a governed decision service connected to operational action.

13. Governance, Ethics, and Responsible BI

BI governance assigns authority for definitions, access, quality, retention, change, and accountability. It should be proportionate: excessive approval can delay useful work, while weak control can produce inconsistent or harmful decisions.

Privacy principles relevant to BI include purpose limitation, data minimisation, access restriction, retention control, transparency, and secure handling. Analysts should avoid exposing individual-level information when aggregated information is sufficient. Small-cell suppression or other disclosure controls may be necessary where users could infer sensitive attributes.

Security should follow least privilege: users receive the minimum access required for their legitimate role. Export and sharing controls deserve attention because a secure dashboard can still create a data breach through unrestricted downloads.

Ethical concerns also arise when dashboards are used to rank employees, allocate resources, or trigger interventions. Historical data may encode unequal treatment or measurement bias. A technically accurate visualisation can still support an unfair decision if its context, limitations, or affected groups are ignored. Human review, documented decision rules, monitoring for disparate effects, and appeal mechanisms may be required.

AI-assisted BI features can generate summaries, suggest visuals, or answer natural-language questions. These features may improve accessibility, but generated explanations and calculations require verification. Organisations should define which sources are authorised, how prompts and outputs are protected, how uncertainty is communicated, and when human approval is mandatory. AI should not be treated as a replacement for data lineage, testing, or accountability.

14. Contemporary Development Practices and Best Practices

Modern BI delivery increasingly adopts analytics engineering, in which transformations are modular, tested, documented, and managed as code. DataOps applies automated testing, observability, and controlled deployment to data workflows. Data products treat curated datasets and semantic models as reusable services with owners and service expectations. These approaches do not eliminate the need for business discovery; they strengthen the repeatability of implementation.

A practical best-practice checklist is:

1. Begin with decisions and measurable outcomes.
2. Define business terms before building complex visuals.
3. Prototype with representative users and realistic tasks.
4. Profile and test data before trusting calculations.
5. Establish a governed semantic layer.
6. Separate development, test, and production environments.
7. Use version control, peer review, and reproducible deployment.
8. Test security, performance, refresh, and regression—not only appearance.
9. Document lineage, assumptions, ownership, and limitations.
10. Monitor both technical health and user adoption.
11. Evaluate impact against a baseline rather than assuming value.
12. Retire redundant products and preserve required records.

Challenges and Limitations

Lifecycle management cannot solve every organisational problem. Poor source systems may limit accuracy; conflicting executives may prevent agreement on definitions; licensing and infrastructure costs may constrain scale; and adoption may remain low when incentives do not support evidence-based decisions. Performance targets are context-dependent, and a metric such as availability can conceal poor semantic quality.

Iterative delivery also has risks. Continuous change can create scope expansion, inconsistent versions, or user fatigue. Prototyping can encourage stakeholders to focus on appearance before data validity. Agile methods can under-document decisions if teams mistake speed for quality. These risks are managed through explicit priorities, acceptance criteria, governance gates, documentation, and periodic product reviews.

Chapter Summary

BI solution development is a lifecycle rather than a one-off reporting exercise. Discovery connects information needs to decisions; prototyping exposes usability and requirement problems early; development creates governed data models and calculations; testing establishes evidence of correctness, security, and performance; UAT confirms business fitness; and controlled deployment reduces operational risk. Documentation, version control, monitoring, and maintenance preserve reliability after release. Performance optimisation must be evidence-based and balanced against freshness and analytical flexibility. Impact evaluation should compare post-release evidence with a baseline and distinguish correlation from causal claims. Throughout the lifecycle, privacy, security, fairness, transparency, and accountability are essential. The mature BI professional therefore manages not only dashboards and data, but also definitions, controls, people, processes, and organisational outcomes.

Key Terms

Business intelligence (BI): The use of data, analytical methods, and information products to support organisational decisions.

BI lifecycle: The sequence of discovery, design, development, testing, deployment, operation, improvement, and retirement activities.

Decision statement: A description of a decision, its decision-maker, timing, evidence needs, and intended action.

Minimum viable product (MVP): The smallest governed solution capable of testing a central value proposition.

Prototype: A limited representation used to learn about requirements, usability, or feasibility.

Semantic layer: A governed business-facing layer containing shared entities, definitions, relationships, and measures.

Data lineage: The record of how data moves and changes from source to report or analytical output.

Data quality: The fitness of data for its intended use, including dimensions such as completeness, validity, accuracy, and timeliness.

User acceptance testing (UAT): Business-led testing that evaluates whether a solution supports real user tasks and requirements.

Regression testing: Repeating established tests after a change to detect unintended effects.

Release management: The controlled planning, approval, deployment, and communication of a change.

Version control: A system for recording, reviewing, and retrieving changes to solution artefacts.

Runbook: Operational instructions for monitoring, refreshing, troubleshooting, recovering, and escalating a BI service.

Incremental refresh: Updating only new or changed data rather than rebuilding the entire historical dataset.

Row-level security: A control that restricts the rows visible to a user according to role or context.

Availability: The proportion of agreed service time during which a service is operational.

Benefits realisation: The process of measuring whether an investment produces intended organisational benefits.

Technical debt: Future cost or risk created by expedient design choices that make later change more difficult.

Data product: A maintained, governed data asset designed for reuse by defined consumers.

Observability: The ability to understand system and data behaviour through logs, metrics, traces, and quality signals.

Review Questions

Short Answer Questions

1. Why is an iterative lifecycle more suitable for many BI solutions than a strictly linear process?
2. What is the difference between a project lifecycle and a product lifecycle?
3. Identify four types of testing relevant to BI solutions.
4. Why should a BI team document metric definitions in a semantic layer?
5. What is the purpose of a rollback plan in deployment?

Long Answer Questions

1. Explain how discovery converts a vague request for a dashboard into testable business requirements.
2. Discuss the relationship between prototyping, usability testing, and user acceptance testing.
3. Describe a controlled BI deployment process, including environment separation, version control, peer review, and release evidence.
4. Explain how performance can be improved through modelling, aggregation, refresh strategy, and query optimisation. Discuss the associated trade-offs.
5. Evaluate the importance of documentation, monitoring, maintenance, and impact evaluation after a BI solution has been released.

Analytical / Application Questions

1. A sales dashboard reports different values for “active customer” in three departments. Design a lifecycle-based intervention to diagnose and resolve the problem, including governance, testing, deployment, and communication.
2. A dashboard has excellent technical availability but very low adoption. Analyse possible causes and propose an evidence-based impact-evaluation plan.
3. A public-sector BI solution contains individual-level service records and is requested by a broad management audience. Recommend controls covering data minimisation, access, disclosure risk, documentation, ethical use, and ongoing monitoring.

Multiple Choice Questions with Answers

Question 1

Which activity should normally occur first when developing a BI solution?

A. Deploying the production dashboard

B. Discovering the decisions and users the solution must support

C. Optimising database indexes

D. Writing the user guide

Correct Answer: B. Discovering the decisions and users the solution must support

Question 2

What is the primary purpose of a BI prototype?

A. To serve as the permanent production system

B. To eliminate the need for data testing

C. To learn about requirements, usability, or feasibility before full implementation

D. To replace user acceptance testing

Correct Answer: C. To learn about requirements, usability, or feasibility before full implementation

Question 3

Which statement best describes user acceptance testing?

A. It is a business-led assessment of whether the solution supports real work

B. It tests only database indexes and query plans

C. It is performed exclusively by software developers

D. It occurs after the solution has been retired

Correct Answer: A. It is a business-led assessment of whether the solution supports real work

Question 4

A data-quality check finds 9,500 non-null required values out of 10,000 expected values. Using the chapter’s completeness formula, what is the completeness rate?

A. 5%

B. 9.5%

C. 90%

D. 95%

Correct Answer: D. 95%

Question 5

Which practice most directly supports reproducible and auditable BI deployment?

A. Editing production reports without recording changes

B. Storing credentials in source-code repositories

C. Using version control, peer review, and tagged releases

D. Allowing every user to publish directly to production

Correct Answer: C. Using version control, peer review, and tagged releases

Question 6

Which measure is concerned specifically with the proportion of agreed service time during which a BI service is operational?

A. Availability

B. Data completeness

C. Defect density

D. User adoption

Correct Answer: A. Availability

Question 7

Why might a BI team use an aggregated summary table on a dashboard’s main page?

A. To remove all access controls

B. To improve response time while retaining detail through a suitable drill-through path

C. To guarantee that data is accurate

D. To eliminate the need for a semantic model

Correct Answer: B. To improve response time while retaining detail through a suitable drill-through path

Question 8

Which document primarily explains how to refresh, monitor, recover, and escalate a BI service?

A. Business glossary

B. Runbook

C. Wireframe

D. Stakeholder register

Correct Answer: B. Runbook

Question 9

Which statement about benefits realisation is most accurate?

A. The number of dashboard visuals proves business value

B. All improvements after deployment can automatically be attributed to BI

C. Impact should be assessed against a baseline while considering other influencing factors

D. User adoption is irrelevant if the dashboard is technically correct

Correct Answer: C. Impact should be assessed against a baseline while considering other influencing factors

Question 10

Which principle is most relevant when users receive only the data access required for their legitimate roles?

A. Least privilege

B. Incremental refresh

C. Pre-aggregation

D. Regression testing

Correct Answer: A. Least privilege