Function Analysis

Functions describe what something does, not how. Phrasing matters: it forces the team out of solution language.

Rules

• Verb + noun. Active verb, measurable noun. "Notify operator", not "notification system".
• One function per line. Compound verbs hide design choices.
• No brand or implementation in the noun. "Persist verdict" not "Write Postgres row".
• Quantify when possible. "Bound spend <= $X/day".

Classification

• Basic function - the reason the thing exists. Removing it kills the value.
• Secondary function - supports, enables, protects, or pleases. Removable if a better path exists.
• Unnecessary function - historical, habitual, performative. First candidate for cut.
• Required function - imposed by law, contract, or policy. Cannot be cut without authority.

Mark each function with one tag.

FAST diagram quickstart

Function Analysis System Technique. Read left to right: higher-order *why* on the left, lower-order *how* on the right. For each function, ask:

• Why does this function exist? -> answer is the function to its left.
• How is it achieved? -> answers are the functions to its right.
• When else? -> concurrent functions sit vertically.

Stop expanding when you reach functions whose answer is "by implementation". That column is the design boundary.

A skinny FAST is enough for most software work. Three columns: outcome -> primary functions -> supporting functions.

Examples

Software - antispam verdict pipeline

• Basic: *Decide verdict* (allow|block|unclear).
• Basic: *Persist verdict* (auditable, queryable).
• Basic: *Bound spend* on LLM calls.
• Secondary: *Explain verdict* to moderator.
• Secondary: *Cache verdict* for repeat content.
• Unnecessary: *Visualize verdict graph in admin UI* - historical, no decisions taken from it.
• Required: *Retain logs >= 30 days* (policy).

Non-software - quarterly offsite

• Basic: *Align direction* across leads.
• Basic: *Surface conflict* safely.
• Secondary: *Reward team*.
• Secondary: *Onboard new hires*.
• Unnecessary: *Produce slide deck* - nobody re-reads it.
• Required: *Stay within travel budget*.

Drill question

Ask the user, one at a time, with *Recommended:* attached:

"If we removed function X, what concretely fails?" - *Recommended: check if anything downstream (code, runbook, contract, user flow) actually depends on X; if no dependency surfaces from inspection, treat X as a tentative cut candidate and ask the user to confirm.*

Cut what survives this question. Promote what doesn't.