The BBAI template library gives business analysts everything they need to deliver professional, consistent work — from requirements gathering through to solution validation. All templates are free. Use them as-is or adapt them to your project context. Jump to section: Requirements · Analysis & Assessment · Stakeholder Management · Process & Workflow · Business Case & Planning · Testing & Quality · BA Project Management · Agile & Product Requirements Templates The most-used templates in a BA’s toolkit. Requirements templates help you capture, document, and manage what the business needs from a solution. Business Requirements Document (BRD) The BRD captures what the business needs to achieve, independent of how the solution will be built. Use at the start of a project to align stakeholders before solution design begins. Section Content to Include 1. Executive Summary Problem statement, business opportunity, and recommended approach (1 page) 2. Business Objectives SMART goals the solution must achieve, linked to strategic objectives 3. Current State As-is process description, pain points, and root causes 4. Scope In-scope processes, systems, and stakeholder groups. Explicit out-of-scope list. 5. Stakeholders Key stakeholders, roles, and approval authorities 6. Business Requirements Numbered list: BR-001, BR-002… Each with priority (MoSCoW) and owner 7. Assumptions & Constraints Known limitations, dependencies, regulatory requirements 8. Success Criteria How the business will measure whether the solution delivered value 9. Glossary Business terms and definitions used in this document Functional Requirements Specification (FRS) Translates business requirements into specific, testable functional behaviours. Used by development teams to understand what the system must do. Write this after the BRD is approved. Field Description Example FR-ID Unique reference number FR-001 Title Short name for the requirement User Login Description What the system must do The system shall allow registered users to log in using email and password Source Business requirement it traces to BR-003 Priority MoSCoW classification Must Have Acceptance Criteria How to confirm it works Given [context], When [action], Then [expected outcome] Owner Stakeholder responsible Product Owner Status Draft / Approved / Implemented / Tested Draft Requirements Traceability Matrix (RTM) Maps each business requirement through to functional requirements, test cases, and implementation. Ensures nothing is missed and every requirement can be tested. Essential for projects with regulatory compliance requirements. BR-ID Business Requirement FR-ID Functional Requirement Test Case ID Test Status Sign-off BR-001 Users must authenticate securely FR-001, FR-002 Login, Password Reset TC-001, TC-002 Pass ✓ BR-002 [Requirement text] [FR-IDs] [FR titles] [TC-IDs] Pending User Story Template Captures requirements from the user’s perspective in agile projects. Each story should be independently deliverable and testable. Use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) to validate stories before sprint planning. Field Format / Example Story ID US-001 As a… [Type of user / role] I want to… [Goal or action] So that… [Business value or outcome] Acceptance Criteria Given [context], When [action], Then [result]. Add one row per criterion. Story Points [Effort estimate] Priority Must Have / Should Have / Could Have Dependencies [Other story IDs] Notes Edge cases, exclusions, open questions Use Case Template Describes a system interaction from the actor’s perspective. Use cases are more detailed than user stories and are better suited to complex workflows or compliance-heavy projects. Field Content Use Case ID UC-001 Title Descriptive name (verb + noun: “Submit Expense Claim”) Primary Actor Who initiates the use case Secondary Actors Other systems or roles involved Preconditions What must be true before this can start Main Success Scenario Step-by-step numbered list of the happy path Alternative Flows Valid variations of the main flow (Alt-1, Alt-2…) Exception Flows Error conditions and how the system handles them Postconditions System state after successful completion Business Rules Rules that govern this use case (link to BR-IDs) Business Rules Template Documents the operational policies, regulations, and constraints that govern how the business works. Business rules are separate from functional requirements — they define the boundaries of acceptable system behaviour. Rule ID Rule Statement Category Source Impact Owner BR-001 All purchase orders above $10,000 must have two approvals Approval Finance Policy v3.1 High CFO BR-002 [Write rule as: Entity must/shall/must not verb condition] Validation / Approval / Calculation / Restriction [Policy, regulation, or SME] High / Medium / Low [Name] Data Dictionary Template Defines every data element used in a system or process — its name, format, valid values, and business meaning. Essential for integration projects, data migration, and anywhere multiple systems exchange data. Field Name Business Definition Data Type Format Valid Values Mandatory? Source System CustomerID Unique identifier for a customer account String CUST-NNNNNN CUST-000001 to CUST-999999 Yes CRM [Field name] [Plain English meaning] String / Integer / Date / Boolean / Decimal [Pattern or example] [List or range] Yes / No [System name] Analysis & Assessment Templates Gap Analysis Template Compares the current state to the desired future state to identify what needs to change. Use early in a project to scope the work and justify investment. Dimension Current State (As-Is) Desired State (To-Be) Gap Priority Recommended Action Process Manual data entry, 3-day cycle Automated, same-day processing No automation; manual errors High Implement workflow automation Technology [Current tools] [Target tools] [Difference] High / Med / Low [Action] People / Skills [Current capability] [Required capability] [Skills gap] [Training / hiring] Data [Current data state] [Required data state] [Data gap] [Migration / cleanse] Root Cause Analysis — 5 Whys Template Traces a problem back to its root cause by asking “why” repeatedly. Works best for process failures where human or system factors compound. Use before defining requirements so you solve the actual problem, not just the symptom. Level Question Answer Problem Statement What is the observable problem? [Describe the symptom clearly] Why 1 Why does this problem occur? [First cause] Why 2 Why does [Why 1 answer] happen? [Second cause] Why 3 Why does [Why 2 answer] happen? [Third cause] Why 4 Why does [Why 3 answer] happen? [Fourth cause] Why 5 Why does [Why 4 answer] happen? [Root cause] Corrective Action What addresses the root cause? [Recommended action] SWOT Analysis