Global WatchGlobal Watch Docs
Use Cases

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:

  1. Requirements Validation - Ensure features meet user needs
  2. Testing Guidance - Provide scenarios for test case development
  3. Developer Reference - Understand expected system behavior
  4. 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 rule

Use 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:

ActorDescription
Authenticated UserAny logged-in user
Account OwnerOwner of a personal or team account
Team AdminUser with admin role in a team
Team MemberUser with member role in a team
Project ManagerUser managing specific projects
Field TechnicianUser collecting data in the field
SystemAutomated processes and background jobs
Billing SystemStripe 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

IDRule
BR-PRJ-001Project slug must be unique within account
BR-PRJ-002Project slug must match pattern: ^[a-z0-9-]+$
BR-TM-001Only owner or admin can invite members
BR-TM-002Cannot remove the primary account owner
BR-BIL-001Free tier: max 3 projects per account
BR-USG-001Usage 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 Tracking

On this page