Use Cases Overview
Use Cases Overview
This section documents real-world scenarios, user workflows, and implementation examples for Global Watch features. Use cases provide concrete examples of how the system behaves in various situations, including happy paths, error cases, and edge scenarios.
Purpose
Use case documentation serves multiple purposes:
- Requirements Validation - Ensure features meet user needs
- Testing Guidance - Provide scenarios for test case development
- Developer Reference - Understand expected system behavior
- Stakeholder Communication - Bridge technical and business understanding
Use Case Format
Each use case follows a standardized format:
Structure
## Use Case: [Name]
### Description
Brief description of what the user wants to accomplish.
### Actors
- **Primary:** The main user performing the action
- **Secondary:** Other systems or users involved
### Preconditions
- What must be true before the use case starts
### Postconditions
- What must be true after successful completion
### Main Flow
1. Step-by-step description of the happy path
2. Each step describes a user action or system response
3. Continue until the goal is achieved
### Alternative Flows
- A1: What happens when X goes wrong
- A2: What happens when Y is not available
### Business Rules
- BR001: Rule that governs this behavior
- BR002: Another applicable ruleUse Case Categories
Project Management
Scenarios related to creating, managing, and organizing forest monitoring projects:
- Create Project - User creates a new project with name, slug, and geometry
- Update Project - User modifies project details and settings
- Archive/Restore Project - User archives inactive projects and restores them
- Delete Project - User permanently removes a project
- Transfer Project - User transfers project ownership between accounts
View Project Management Use Cases →
Team Collaboration
Scenarios related to team accounts, members, and permissions:
- Create Team Account - User creates a new team workspace
- Invite Team Member - Owner invites users to join the team
- Accept Invitation - User accepts team invitation
- Update Member Role - Admin changes a member's role
- Remove Team Member - Admin removes a member from the team
View Team Collaboration Use Cases →
Asset Tracking
Scenarios related to managing assets, templates, and catalog items:
- Create Asset - User creates a geolocated asset in a project
- Create Asset Template - Admin creates a custom asset template
- Populate Catalog - User adds items to the asset catalog
- Create Asset from Template - User creates an asset using a catalog item
- Search Catalog - User searches for items in the catalog
View Asset Tracking Use Cases →
Actors
Common actors across Global Watch use cases:
| Actor | Description |
|---|---|
| Authenticated User | Any logged-in user |
| Account Owner | Owner of a personal or team account |
| Team Admin | User with admin role in a team |
| Team Member | User with member role in a team |
| Project Manager | User managing specific projects |
| Field Technician | User collecting data in the field |
| System | Automated processes and background jobs |
| Billing System | Stripe integration for payments |
Business Rules
Business rules are constraints that govern system behavior. They are referenced in use cases using identifiers:
Naming Convention
- BR-PRJ-XXX - Project-related rules
- BR-USR-XXX - User and authentication rules
- BR-TM-XXX - Team management rules
- BR-BIL-XXX - Billing and subscription rules
- BR-USG-XXX - Usage tracking rules
Example Rules
| ID | Rule |
|---|---|
| BR-PRJ-001 | Project slug must be unique within account |
| BR-PRJ-002 | Project slug must match pattern: ^[a-z0-9-]+$ |
| BR-TM-001 | Only owner or admin can invite members |
| BR-TM-002 | Cannot remove the primary account owner |
| BR-BIL-001 | Free tier: max 3 projects per account |
| BR-USG-001 | Usage tracked in real-time |
Testing Use Cases
Use cases directly inform test development:
Unit Tests
Test individual use case handlers:
describe('CreateProjectUseCase', () => {
it('creates project successfully', async () => {
// Test main flow
});
it('fails if slug already exists', async () => {
// Test alternative flow A1
});
it('fails if quota exceeded', async () => {
// Test alternative flow A2
});
});E2E Tests
Test complete user workflows:
test('user creates and manages project', async ({ page }) => {
// Step 1: Navigate to projects
await page.goto('/account/projects');
// Step 2: Create new project
await page.click('[data-test="create-project"]');
await page.fill('[data-test="project-name"]', 'Test Project');
// Step 3: Verify creation
await expect(page.locator('h1')).toContainText('Test Project');
});Use Case Dependencies
Use cases often depend on each other:
Create Project ──→ Track Usage ──→ Check Quota
└──→ Calculate Overage
Update Project ──→ Audit Log
Delete Project ──→ Stop Usage Tracking
Archive Project ──→ Pause Tracking
Restore Project ──→ Check Quota
└──→ Resume TrackingRelated Documentation
- Architecture Overview - System architecture and patterns
- Testing Guide - Testing strategies and tools
- Development Setup - Local development environment