13.3 Writing a Business Requirements Specification

A business requirements specification (BRS) is the foundational document for any BI project. It translates a stakeholder’s needs into a structured format that both the analyst and the stakeholder can review and agree upon before work begins (Sommerville 2016).

13.3.1 Components of a BRS

A practical BRS for a BI project includes:

Problem statement. A clear, concise description of the business problem or opportunity. This should be specific enough to guide the analysis but broad enough to allow for analytical judgment. “Reduce employee absenteeism” is too vague; “Identify the factors most strongly associated with high absenteeism and build a model to flag at-risk employees for early HR intervention” is actionable.

Key questions. The specific questions the analysis must answer. These become the acceptance criteria — if the deliverable answers these questions, it meets the requirement.

Target audience. Who will use the results, and what decisions will they make based on them? An analysis for HR managers requires different framing than one for the CFO. The audience determines the format, level of detail, and technical sophistication of the deliverable.

Deliverables. What the analyst will produce: a report, a dashboard, a predictive model, a dataset, a presentation, or some combination. Each deliverable should be concrete and verifiable.

Key performance indicators (KPIs). The metrics that define success. For a predictive model, this might include minimum accuracy, precision, or recall thresholds. For a dashboard, it might be response time or the specific questions it must answer. KPIs make success measurable rather than subjective.

Timeline and constraints. When the work is due, what resources are available, and what limitations exist (e.g., data access restrictions, budget constraints, regulatory requirements, ethical constraints on which variables may be used).

13.3.2 Worked Example: Absenteeism Analysis BRS

Example: Complete Business Requirements Specification

Project: Employee Absenteeism Predictive Analysis

Problem Statement: The HR department has observed increasing unplanned absence over the past two years but lacks insight into which factors drive high absenteeism or which employees are at risk. They need an evidence-based approach to target wellness interventions.

Key Questions:

  1. Which employee characteristics (demographic, health, work-related) are most strongly associated with high absenteeism?
  2. Can we build a model that identifies employees at risk of chronic absence (defined as >40 hours/quarter) with at least 70% accuracy?
  3. How does absenteeism vary by season, department, and tenure?

Target Audience: HR managers who will use the results to design and target wellness programs. Results must be interpretable by non-technical stakeholders.

Deliverables:

  1. Exploratory analysis report with key visualizations (absenteeism by department, season, and employee characteristics)
  2. Logistic regression model predicting high absenteeism, with accuracy metrics
  3. Ranked risk list of current employees with predicted probability of chronic absence
  4. One-page executive summary for senior leadership

KPIs: Model accuracy >= 70%, model must not use protected characteristics (gender, ethnicity, religion) as predictors, all deliverables completed within timeline.

Timeline: 2 weeks from data access. Interim check-in with HR at end of week 1.

Constraints: Data is limited to the past 3 years. Some employee records may have missing health data. The model must comply with company data ethics policy.

13.3.3 Common Pitfalls

  • Vague requirements: “Analyze our data and find interesting insights” gives the analyst no direction and guarantees misalignment.
  • Scope creep: Without a written spec, stakeholders add requirements throughout the project. Empirical research confirms that scope creep is one of the strongest predictors of project failure (Komal et al. 2020). A spec provides a baseline to evaluate change requests against.
  • Unstated assumptions: The stakeholder assumes the analyst knows that “absenteeism” means unplanned absence only (not vacation), but the analyst includes all absence types. A spec surfaces these assumptions early.