Behavior Description
Use this template when documenting use cases and scenarios — levels 3 and 4 of the Functional Domain Taxonomy. Each behavior document covers one Area and contains all use cases and scenarios within it.
When to Use
Section titled “When to Use”- Describing a user-facing or system behavior within a taxonomy area.
- Transcribing legacy use cases into the canonical naming scheme.
- Documenting new behaviors discovered during product analysis or implementation.
Target Section
Section titled “Target Section”product/use-cases/ or domain/ depending on the behavior scope.
Document Structure
Section titled “Document Structure”A behavior document has four sections:
- Front matter and header — YAML metadata and area-level introduction.
- Use Case blocks — One
##section per use case. - Scenario blocks — One
###section per scenario, nested under its use case. - Summary table — Optional rollup at the end of the document.
The document filename should match the area: ${domain}-${area}-behaviors.md (e.g., pro-oq-behaviors.md).
Template
Section titled “Template”Front Matter and Area Header
Section titled “Front Matter and Area Header”---title: "Area Title Behaviors"tags: [behavior, use-case, area-tag]domain: productmaturity: publishedauthor: Author Name---
# Area Title Behaviors
1-3 sentence description of the area scope.
Source document abbreviations used in this file:
| Tag | Source || --- | --- || TAG | path or link to source document |Use Case Block
Section titled “Use Case Block”Each use case is a ## heading with a description, metadata table, optional sequence diagram, and one or more scenario blocks.
## `DOMAIN::AREA::NNNN` -- Use Case Title
1-3 sentences stating the user-facing goal. Write in present tense, third person.
| | ||---|---|| **Persona** | Name (Role), Name (Role) || **Depends** | `ID`, `ID` || **Status** | Covered | Partial | New-extends | New-distinct |Status values: Covered (fully described by existing sources), Partial (gaps remain), New-extends (extends an existing use case), New-distinct (no prior documentation).
Scenario Block
Section titled “Scenario Block”Each scenario is a ### heading nested under its parent use case.
### `DOMAIN::AREA::UC::NNNN.TYPE` -- Scenario Title
1-3 sentences describing the specific realization. Focus on what distinguishes this scenario from siblings.
- TAG > [Legacy ID: Title](path#anchor) -- gloss- Crosses: `DOMAIN::AREA` > [anchor text](path#anchor)The .TYPE suffix (.US, .UC, .FS) is part of the heading. See the Functional Domain Taxonomy for type code definitions.
Optional Summary Table
Section titled “Optional Summary Table”## Summary
| Use Case | Scenarios | US | FS | UC || --- | --- | --- | --- | --- || `ID` Title | n | n | n | n || **Total** | **N** | **N** | **N** | **N** |Diagram Placement Guidelines
Section titled “Diagram Placement Guidelines”| Place diagram at | When |
|---|---|
| Use Case level | All scenarios share the same interaction shape and differ only in trigger, data, or entry point. |
| Scenario level | The scenario introduces a materially different interaction (additional actors, different API sequence). |
| Both levels | Shared “happy path” overview plus divergent scenarios. |
| Neither level | Behavior is simple enough that prose is sufficient. |
Complete Example
Section titled “Complete Example”See the source template at workspace/knowledge-base/templates/behavior-template.md for a full worked example with PlantUML sequence diagrams.
Copyright: © Arda Systems 2025-2026, All rights reserved