Functional Toolbelt

Mental models, techniques, and validation tools for producing better functional analysis. NOT a deliverable skill — a toolbelt that enhances output quality of any requirements or specification work.

Principio Rector

Las herramientas no producen calidad — la disciplina en su uso sí. El functional toolbelt no es un deliverable — es un kit de técnicas que eleva la calidad de cualquier trabajo de análisis funcional. Event storming sin disciplina es brainstorming caótico. Acceptance criteria sin estructura es prosa ambigua.

Filosofía del Toolbelt

1. Técnica correcta para el contexto. Event storming para descubrir dominios, story mapping para planificar releases, acceptance criteria para validar. No usar martillo para todo.
2. Formalismo proporcional. Business rules críticas en pseudo-código. Rules simples en lenguaje natural. El nivel de formalismo depende de la severidad.
3. Traceability end-to-end. Cada requirement tiene un origen (stakeholder, rule, flow) y un destino (test, acceptance criteria). Sin trazabilidad, los requirements son declaraciones sueltas.

$ARGUMENTS

$ARGUMENTS format: [tool-name-or-number] [context]
Examples:
  "event-storming loan-origination"     → Tool 1, domain=loan-origination
  "acceptance-criteria user-registration" → Tool 4, story=user-registration
  "anti-patterns scan requirements.md"   → Tool 6, input=requirements.md
  "3 business rules from interviews"     → Tool 3, source=interview notes

• If no tool specified → show 6-tool menu with one-line descriptions
• If tool specified without context → ask for the input artifact

Parámetros de Pipeline

• MODO=paso-a-paso → pausa después de cada tool output para revisión
• FORMATO=html → aplica design-system tokens al output
• VARIANTE=ejecutiva → solo resumen de hallazgos, sin matrices detalladas

Output Format Protocol

• Markdown siempre incluye front-matter con metadata (tool used, domain, date)
• HTML aplica brand-config.json si disponible

Tool 1: Event Storming (Lightweight — 90 min)

Inputs: Domain actors, key processes Process: Identify domain events (temporal markers) > Group by aggregate > Identify commands + actors > Surface policies/rules > Mark hot spots (unknowns) Output: Event timeline > domain events > aggregates > bounded contexts

Edge Cases:

• Circular events (Order Placed > Payment > Order Placed): surface business rule preventing cycle
• God-aggregate (5+ events): signals context boundary issue — recommend splitting
• Missing actors (events without source): mark as hot spot requiring stakeholder clarification

Trade-offs: Speed (90 min) vs completeness (full domain modeling) — prioritize critical paths. Visual (sticky board) vs structured (spreadsheet) — visual aids creativity, spreadsheet aids traceability.

Conditional Logic:

• IF events unclear → trace 1 user journey end-to-end first
• IF no process flows exist → generate basic flow from stakeholder interviews
• IF aggregate boundaries disputed → document multiple hypotheses, defer to architecture team

Tool 2: Story Mapping

Process: Extract user activities from flows > Decompose to tasks > Write user stories > Assign acceptance criteria > Plot backbone (activities, horizontal) vs detail (stories, vertical) > Slice into releases (MVP, phases 2-3) Output: Backbone > Walking Skeleton (MVP) > Release Plan with story counts

Edge Cases:

• Epic masquerading as story (too large): split into 2-3 stories per variant
• Technical story without user value: reframe as infrastructure epic or reject
• Missing happy path: prioritize nominal flow in early release, edge cases later

Trade-offs: Granularity (tiny stories, many) vs manageability (fewer, less traceable) — target 8-13 stories per release. Detail (full AC now) vs speed (AC during sprint) — write basic AC now, refine during sprint planning.

Conditional Logic:

• IF multiple actors → separate story maps per actor, merge at integration points
• IF story > 13 points → decompose into 2 stories
• IF no metrics for priority → use business risk (revenue loss if not delivered) as proxy

Tool 3: Business Rule Extraction

Techniques: Decision Table (conditions > actions > rows = rules), Decision Tree (condition > branches > leaf = outcome), Rule Catalog (name, classification, condition, action, exception, data, owner)

Classification: Constraint (what cannot happen), Derivation (what is calculated), Inference (what is deduced), Action-Enabling (what triggers a process)

Validation: Completeness (all condition combinations covered?), Consistency (no contradicting rules?), Necessity (traces to business objective?)

Edge Cases:

• Ambiguous conditions ("customer is qualified"): decompose into measurable sub-conditions
• Untestable actions ("notify relevant stakeholders"): specify exactly who, when, how
• Hidden exceptions: surface via stakeholder questioning

Trade-offs: Formality (decision tables) vs readability (narrative) — use both. Completeness (all rules) vs speed (80% important rules) — prioritize rules tied to business risk.

Conditional Logic:

• IF rule involves time → document temporal constraints
• IF rule has >5 conditions → decompose into sub-rules or decision tree
• IF rules conflict → document conflict, escalate to business stakeholder

Tool 4: Acceptance Criteria (Given/When/Then)

Pattern: Given [precondition], When [action], Then [expected result] Variations: Basic (single behavior), Extended (+And), Negative (Then = failure), Boundary (edge values)

Quality Rules (Non-Negotiable):

1. One behavior per scenario
2. Measurable outcomes (no "works correctly")
3. No implementation details (no "onClick handler fires")
4. Testable preconditions (specific values)
5. Use specific values ("income $75K" not "income")

Anti-Patterns: Vague Then ("handle appropriately"), Missing Given, Implementation leakage ("API endpoint called"), Untestable conditions ("under load" without metric), Conjunctive action (3 outcomes = 3 scenarios)

Edge Cases:

• Conditional actions (different Then per data): separate scenarios per condition
• Async outcomes: specify max acceptable delay in Then
• Third-party deps ("email delivered"): define acceptable failure mode

Conditional Logic:

• IF AC mentions external system → add "system unavailable" scenario
• IF scenarios > 8 per story → split across multiple stories
• IF AC references business rule → link back to rule catalog

Tool 5: Traceability Matrix

Structure: Requirement ID | Requirement | Linked Use Cases | Linked Flows | Test Cases | AC Covered

Validation Rules:

1. Every requirement has >= 1 use case (else orphaned)
2. Every use case has >= 1 flow (else abstract)
3. Every flow has >= 1 test case (else untested)
4. Every test case traces to >= 1 AC (else invalid)

Coverage Metrics: % traced requirements, % untested flows, % AC without tests

Gap Detection: Requirements without UCs (disconnected), Flows without UCs (orphaned), Orphan test cases (no AC), AC without tests (unvalidated)

Edge Cases:

• Many-to-many (one flow covers multiple requirements): signals decomposition issue
• Matrix > 50 requirements: filter by domain or split
• Regulatory requirements: trace with 100% coverage rigor

Conditional Logic:

• IF regulatory → require 100% traceability coverage
• IF critical path flow → ensure >= 2 test cases (happy + error)
• IF gap found → assign to owner (requirements > product, flows > design, tests > QA)

Tool 6: Anti-Pattern Detector

Categories:

1. Ambiguity: "handle appropriately" (no measurable outcome) → specify exact behavior
2. Untestability: "system should be user-friendly" (no metric) → provide measurable criteria
3. Over-Specification: "use MySQL 8.0.32" (how not what) → state requirement, let design choose
4. Missing Exceptions: "user logs in" (no failure path) → add negative scenarios
5. Scope Creep: Requirements not tracing to business objectives → defer or reject
6. Gold Plating: Features nobody asked for → require explicit business driver

Detection Process: Scan requirements (missing measurements) > Scan AC (implementation details, missing negatives) > Scan rules (untestable conditions) > Scan flows (missing error paths) > Cross-check traceability

Edge Cases:

• Intentional underspecification (innovation/exploration phase): mark as exploration story, exempt
• Phase-dependent strictness: lenient in early phases, strict at phase gates
• Regulatory over-specification ("must use FIPS 140-2"): document as compliance constraint, not anti-pattern

Conditional Logic:

• IF ambiguity in executive summary → escalate (high visibility)
• IF multiple anti-patterns in same requirement → likely incomplete understanding, request clarification
• IF severity = blocker (missing negative scenario on critical path) → must fix before phase exit

Assumptions & Limits

• Toolbelt is reference, not prescriptive — projects adapt or skip tools based on context
• Tools 1-3 need domain expert input; async facilitation possible but slower
• Output quality depends on input quality — ensure upstream artifacts are solid
• Not a replacement for domain knowledge — surfaces structure, business logic expertise still required
• Event storming assumes access to at least one domain expert; pure documentation-based analysis is weaker
• Traceability matrix scales to ~200 requirements before tooling (Jira, Azure DevOps) becomes necessary
• GWT acceptance criteria assume BDD-aware team; teams unfamiliar with BDD need coaching first

Edge Cases

Macro Trade-offs

Validation Gate

Before delivering toolbelt output, verify:

• Tool selection justified for project context
• Inputs identified and available (or gaps flagged)
• Edge cases for the selected tool explicitly addressed
• Output format matches downstream consumer needs
• Anti-patterns checked on own output (recursive quality)
• MODO/FORMATO/VARIANTE params respected in output
• Traceability links present (requirement origin → test destination)
• Domain glossary terms used consistently across all outputs

Casos Borde

Decisiones y Trade-offs

Knowledge Graph

graph TD
    subgraph Core["Functional Toolbelt Core"]
        A[metodologia-functional-toolbelt]
        T1[Tool 1: Event Storming]
        T2[Tool 2: Story Mapping]
        T3[Tool 3: Business Rule Extraction]
        T4[Tool 4: Acceptance Criteria GWT]
        T5[Tool 5: Traceability Matrix]
        T6[Tool 6: Anti-Pattern Detector]
    end
    subgraph Inputs["Inputs"]
        I1[Domain Actors & Processes]
        I2[User Flows & Journeys]
        I3[Stakeholder Interviews]
        I4[Existing Requirements]
    end
    subgraph Outputs["Outputs"]
        O1[Event Timeline & Bounded Contexts]
        O2[Story Map & Release Plan]
        O3[Business Rule Catalog]
        O4[Acceptance Criteria Suite]
        O5[Traceability Matrix]
        O6[Anti-Pattern Report]
    end
    subgraph Related["Related Skills"]
        R1[metodologia-workshop-design]
        R2[metodologia-technical-feasibility]
        R3[metodologia-ux-design-discovery]
        R4[metodologia-quality-engineering]
    end
    I1 --> T1
    I2 --> T2
    I3 --> T3
    I4 --> T6
    T1 --> T2 --> T3 --> T4 --> T5
    T6 --> T4
    T6 --> T5
    A --> O1
    A --> O2
    A --> O3
    A --> O4
    A --> O5
    A --> O6
    R1 --> A
    A --> R2
    A --- R3
    A --> R4

Output Templates

Formato MD (default):

# Functional Toolbelt — {proyecto} — Tool {N}: {nombre}
## Resumen
> Herramienta aplicada: {nombre}. Dominio: {contexto}. Hallazgos: X items generados, Y gaps identificados.
## Output de la Herramienta
[Contenido especifico del tool seleccionado: event timeline, story map, rule catalog, GWT, matrix, o anti-pattern report]
## Gaps Identificados
| Gap | Severidad | Owner Sugerido | Accion |
## Cross-Reference
[Trazabilidad hacia herramientas upstream/downstream]

Formato HTML (para presentacion a stakeholders):

Header: Logo + proyecto + tool seleccionado
Section 1: Tool Output (visualizacion interactiva segun tool)
  - Event Storming: timeline visual con stickies de colores
  - Story Map: backbone horizontal + stories verticales
  - Rule Catalog: tabla expandible con decision trees
  - GWT: scenarios formateados con syntax highlighting
  - Traceability: matrix interactiva con filtros
  - Anti-Patterns: report con semaforo de severidad
Section 2: Gaps & Action Items
Section 3: Cross-References to Related Tools
Footer: Attribution MetodologIA + fecha

• Filename: D-01_Functional_Toolbelt_{project}_{WIP}.html
• Branded (Design System MetodologIA v5). Light-First Technical page con tool output interactivo adaptado al tool seleccionado (event timeline, story map, traceability matrix, etc.), gaps en semáforo, y cross-references navegables. WCAG AA, responsive, print-ready.

Formato DOCX (bajo demanda):

• Filename: D-01_Functional_Toolbelt_{project}_{WIP}.docx
• Generado con python-docx bajo MetodologIA Design System v5: portada, TOC automático, encabezados/pies de página con marca, tablas zebra, tipografía Poppins (headings navy), Montserrat (body), acentos dorados

Formato XLSX (bajo demanda):

• Filename: D-01_Functional_Toolbelt_{project}_{WIP}.xlsx
• Generado con openpyxl bajo MetodologIA Design System v5. Headers con fondo navy y tipografía Poppins blanca, formato condicional, auto-filtros activados, valores sin fórmulas. Hojas: Event Storming, Story Map, Business Rules, Acceptance Criteria, Traceability Matrix, Anti-Patterns.

Formato PPTX (bajo demanda):

• Filename: {fase}_{entregable}_{cliente}_{WIP}.pptx
• Generado con python-pptx bajo MetodologIA Design System v5. Slide master con degradado navy, títulos Poppins, cuerpo Montserrat, acentos dorados. Máx 20 slides variante ejecutiva / 30 variante técnica. Notas de orador con referencias de evidencia ([CODIGO], [DOC], [INFERENCIA], [SUPUESTO]).

Evaluacion

Umbral minimo global: 7/10. Si alguna dimension cae por debajo, el entregable requiere revision antes de entrega.

Cross-References

• functional-spec — consumes toolbelt outputs to build formal specification document
• quality-engineering — testing strategy informed by traceability matrix (Tool 5)
• flow-mapping — process flows feed into event storming (Tool 1) and story mapping (Tool 2)
• design-system — when FORMATO=html, applies brand tokens to toolbelt outputs

Output Artifact

Primary: D-01_Functional_Toolbelt_{project}.md (o .html si {FORMATO}=html|dual) — Functional patterns catalog, composition strategies, implementation guidelines.

Diagramas incluidos:

• Pattern composition diagram
• Function pipeline flowchart
• Type hierarchy visualization

Autor: Javier Montaño | Última actualización: 12 de marzo de 2026