Types of Project Documentation

🎯 Learning Objectives

By the end of this lesson, you will:

• Identify the 5 most common types of project documentation
• Know who writes each document and what it contains
• Know what a QA looks for when reviewing each type
• Understand the relationship between these documents

📚 The Documentation Ecosystem

On most projects, you'll encounter several types of documents. Think of them as a layered cake 🎂 — each layer adds more detail:

Business Need (BRD)
    ↓
Product Vision (PRD)
    ↓
Technical Specification (Tech Spec)
    ↓
Work Items (User Stories / Tasks)
    ↓
Visual Specification (Figma Mockups)

Each layer should be consistent with the one above it. Spotting inconsistencies between layers? That's static testing.

📄 Document Type 1: BRD (Business Requirements Document)

What it is: Describes why the project exists — the business problem being solved.

Who writes it: Business analysts, product owners, stakeholders.

What it contains:

• Business goals and success metrics
• High-level scope
• Stakeholder needs
• Constraints and assumptions

What QA looks for:

• Are the goals measurable? ("Increase conversion by 15%" ✅ vs. "Make it better" ❌)
• Are constraints realistic?
• Are success criteria testable?

📋 Document Type 2: PRD (Product Requirements Document)

What it is: Describes what the product will do to solve the business problem.

Who writes it: Product managers.

What it contains:

• Feature list and descriptions
• User personas and journeys
• Non-functional requirements (performance, security)
• Out-of-scope items

What QA looks for:

• Are non-functional requirements specific? ("Page loads in <2 seconds" ✅ vs. "Page loads fast" ❌)
• Is the scope clear? What's explicitly out of scope?
• Are edge cases mentioned?

🔧 Document Type 3: Tech Spec (Technical Specification / ТЗ)

What it is: Describes how the product will be built.

Who writes it: Tech leads, architects, senior developers.

What it contains:

• System architecture decisions
• API contracts
• Data models and flows
• Integration points

What QA looks for:

• Are all API endpoints described with error responses?
• Are data validation rules specified?
• Are integration failure scenarios covered?

📝 Document Type 4: User Stories

What it is: A short description of a feature from the user's perspective.

Who writes it: Product managers, BAs, sometimes developers.

Standard format:

As a [role], I want to [action], so that [benefit].

What it contains:

• The story card itself (role/action/benefit)
• Acceptance Criteria (AC) — specific conditions for "done"
• Notes, edge cases, attachments

What QA looks for:

• Is the role realistic?
• Is the action specific?
• Are there Acceptance Criteria?
• Do the AC cover negative paths (error states, empty states)?

💡 The most common gap: AC that only describes the happy path. Always ask: "What happens when it goes wrong?"

🎨 Document Type 5: Design Mockups (Figma / etc.)

What it is: Visual specification of the user interface.

Who writes it: UI/UX designers.

What it contains:

• Screen layouts
• Component states (normal, hover, active, disabled, error)
• Typography and spacing
• Responsive breakpoints

What QA looks for:

• Are all component states designed? (Don't just check the normal state!)
• Do the screens cover error states and empty states?
• Is terminology consistent with the rest of the docs?
• Does the Figma match the written spec?

💡 Pro Tip: Figma is often more up-to-date than the written spec. When they conflict, ask which one is authoritative — before development starts.

🔗 The Cross-Document Check

The real value comes when you compare documents against each other:

• Does the BRD's business goal align with the PRD's features?
• Does the PRD's feature list match the Tech Spec's components?
• Do the User Stories reference the right personas from the PRD?
• Does the Figma match the User Story's AC?

Any gap between layers is a potential bug — catch it now.

💡 Pro Tips

💡 Tip 1: Ask for all documents at the start of a sprint, not just the user stories. Context from BRD/PRD changes how you interpret edge cases.

💡 Tip 2: If a document doesn't exist yet, ask who's writing it and when it will be ready. Surprises in development are expensive.

💡 Tip 3: Create a "documentation checklist" for your project. Tick off each document type as it's received. Missing documents = missing information = future bugs.

📋 Summary

Up next: a universal 5-criteria checklist you can apply to every document you review.