Documentation & Use Cases

Documentation is where all your elicitation, analysis, and modeling work becomes a tangible deliverable. A Business Analyst produces more written artifacts than almost any other role — and the quality of those documents directly determines whether the solution team builds the right thing.

This topic teaches you the core documents every BA must know: the Business Requirements Document (BRD), Functional Requirements Document (FRD), Software Requirements Specification (SRS), user stories with acceptance criteria, use case diagrams, and the Requirements Traceability Matrix (RTM). You will see real templates, learn what goes where, and practice writing requirements that are clear, complete, and traceable.

Complete Requirements Elicitation and Stakeholder Management before starting this topic.

A requirement that exists only in someone’s head is not a requirement — it is an assumption. Documentation transforms assumptions into agreed-upon, testable, traceable specifications that the development team can build from and that the QA team can verify against.

Good documentation serves multiple audiences:

• Stakeholders: Confirm that their needs are understood correctly
• Development team: Know exactly what to build
• QA team: Know exactly what to test
• Future team members: Understand why decisions were made
• Auditors: Verify compliance with standards

The golden rule: if it is not written down, it does not exist.

The BRD defines the business need at a high level — what the organization needs and why, without specifying how it will be built.

Standard BRD structure:

1. Executive Summary — one-paragraph overview of the project
2. Business Need / Problem Statement — why this project exists, what problem it solves
3. Project Scope — what is in scope and what is explicitly out of scope
4. Stakeholders — list of key stakeholders and their roles
5. Business Requirements — high-level requirements (business rules, constraints, assumptions)
6. Functional Overview — high-level description of what the solution will do
7. Non-Functional Overview — performance, security, and compliance needs
8. Dependencies — what this project depends on
9. Risks — identified risks and mitigation strategies
10. Acceptance Criteria — how you know the project is successful
11. Appendix — glossary, references, diagrams

The BRD is typically 15-40 pages. It is reviewed and signed off by the project sponsor before detailed requirements begin.

The FRD takes the business requirements from the BRD and translates them into specific, testable functional requirements. This is the document developers actually build from.

Standard FRD structure:

1. Introduction — project background, purpose of the FRD, references to the BRD
2. Functional Requirements — detailed requirements organized by module/feature, each with: ID, description, business rule, priority, and acceptance criteria
3. Non-Functional Requirements — performance (response time, throughput), security (authentication, authorization), availability (uptime), scalability
4. Data Requirements — data entities, relationships, data flow, data validation rules
5. Interface Requirements — UI mockups, API contracts, system integrations
6. Business Rules — specific rules the system must enforce (e.g., "orders over $1000 require manager approval")
7. Assumptions and Constraints
8. Appendix — glossary, data dictionary

FRD example requirement:

FR-001: The system shall allow a customer to submit an invoice by uploading a PDF or CSV file. Maximum file size: 10 MB. The system shall validate the file format and display an error message for invalid files.

The SRS is the most comprehensive requirements document, often following the IEEE 830 standard. It is common in large-scale or regulated projects.

IEEE 830 SRS structure:

1. Introduction — purpose, scope, definitions, references
2. Overall Description — product perspective, functions, user characteristics, constraints, assumptions
3. Specific Requirements — functional requirements, external interface requirements, performance requirements, database requirements, design constraints, security requirements
4. Appendices — models, prototypes, analysis results

The SRS differs from the FRD in its comprehensiveness — it covers not just what the system does, but how it interacts with other systems, what hardware it needs, and what standards it follows.

In Agile environments, user stories replace traditional requirements documents. A user story captures a requirement from the user’s perspective in a single sentence:

Format: "As a [type of user], I want [an action] so that [a benefit/value]."

Example: "As a finance manager, I want to approve invoices in the mobile app so that I can respond while traveling."

Each user story must have acceptance criteria — specific, testable conditions that must be true for the story to be considered "done":

• Given I am logged in as a finance manager, when I open the pending invoices list, then I see all invoices awaiting my approval
• Given I tap "Approve" on an invoice, when the system processes the action, then I see a confirmation message and the invoice is marked as approved
• Given I tap "Reject" on an invoice, when I enter a reason, then the invoice is returned to the submitter with my comment

INVEST criteria for good user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Use case diagrams show how actors interact with the system at a high level. They are part of UML (Unified Modeling Language) and are excellent for scoping a system.

Elements:

• Actor (stick figure): A user or external system that interacts with the system
• Use Case (oval): A goal the actor achieves (e.g., "Place Order," "View Report")
• System Boundary (rectangle): The system being described
• Associations (lines): Connect actors to use cases
• Include: A use case that is always part of another (dashed arrow with <<include>>)
• Extend: A use case that optionally adds behavior (dashed arrow with <<extend>>)

Example: For an e-commerce system, actors include Customer, Admin, and Payment Gateway. Use cases include Browse Products, Add to Cart, Place Order, Process Payment. "Process Payment" is included in "Place Order." "Apply Discount Code" extends "Place Order."

The RTM ensures that every business requirement is covered by a functional requirement, a test case, and a deliverable. It prevents requirements from being "lost" during development.

RTM structure:

Benefits of RTM:

• Ensures complete coverage — no business requirement is forgotten
• Supports change impact analysis — when a requirement changes, you can trace its dependencies
• Aids in project tracking — shows what is implemented and what is tested
• Satisfies audit requirements in regulated industries

1. Write a one-page BRD for a hypothetical online library system. Include: executive summary, business need, scope (in/out), and 5 high-level business requirements.
2. Take one business requirement and write 4 detailed FRD requirements with IDs, descriptions, and acceptance criteria.
3. Write 5 user stories for a mobile banking app with acceptance criteria for each.
4. Draw a use case diagram for an online food delivery system with at least 3 actors and 6 use cases.
5. Build an RTM linking 5 business requirements to functional requirements and test cases.

In a real job, your documentation quality directly determines your credibility. When you hand a developer a well-structured FRD with clear IDs, acceptance criteria, and a traceability matrix, they trust you and build the right thing. When you hand them a vague paragraph, they guess and you spend weeks in rework. The BRD is your contract with the sponsor — it defines what "done" means. The RTM is your safety net — it ensures nothing falls through the cracks during a long project. BAs who document well are the ones who get assigned to the most important projects.

Business problem: A university wants to build a student registration portal. Students currently register in person.

Objective: Write a complete set of documentation for the student registration portal, from business level to testable requirements.