| name | functional-analysis |
| description | Functional requirements analysis skill for TemperAI. Use when eliciting requirements from users and preparing to generate a PRD. Teaches the analyst how to think functionally, detect gaps, ask the right questions, and classify uncertainty correctly. Loaded by temper-analyst during Phase 1 (Functional Analysis & PRD Generation).
|
Functional Analysis — TemperAI Standards
What a good PRD contains
A Product Requirements Document captures the functional understanding of a system.
It is NOT a technical specification — it describes WHAT the system does for its users,
never HOW it is built.
A good PRD contains:
- Problem statement — clear description of the problem being solved.
- Target users — who will use this system.
- Core features — the 3–5 most important functionalities.
- Out of scope — what this version explicitly does NOT include.
- Business rules — any domain-specific rules or constraints.
- External integrations — third-party services, systems, or regulations.
- Non-functional requirements — performance, security, or scalability needs
as described by the user (not inferred).
How to read and understand a user's request
Step 1 — Read the entire input first
Do not start asking questions or generating files until you have read everything
the user provided. Build a mental model of the entire system before analyzing details.
Step 2 — Identify the purpose
Ask yourself:
- What problem is the user trying to solve?
- Who is affected by this problem?
- What happens if we do nothing?
Step 3 — Identify actors and roles
The person describing the system is rarely the only user. Look for:
- End users who interact with the system directly
- Administrators who manage the system
- Supervisors or managers who oversee operations
- External parties (customers, partners, regulators)
- Automated processes or systems that interact with this one
Step 4 — Identify capabilities
From the user's description, extract what each role needs to BE ABLE to do.
Focus on actions, not on solutions.
| ❌ WRONG — solution | ✅ CORRECT — capability |
|---|
| "I want a button to archive orders" | "Completed orders must be removable from the active workflow" |
| "I need a dropdown to filter products" | "Users must be able to find products by name or category" |
| "I want to send an email notification" | "Users must be notified when their order ships" |
Step 5 — Identify constraints and rules
Look for:
- Conditions that must be true for something to happen
- Things that are explicitly NOT allowed
- Status transitions or lifecycle steps
- Validations on data or behavior
Questions to ask when requirements are ambiguous or incomplete
Token-efficient questioning strategy
Do NOT ask one question at a time. Group questions by category and ask them
all at once. This minimizes back-and-forth and saves tokens.
Do NOT assume anything. If the user did not specify it, ask. There are no
"reasonable defaults" for business decisions. Every assumption is a risk.
Do NOT stop at the first vague answer. If the reply still allows multiple
functional interpretations or leaves behavior unresolved, ask follow-up clarification
questions until the materially relevant doubt is gone.
Do NOT ask questions about things that are explicitly out of scope. If the
user says "no authentication for now," do not ask about auth.
Questions by category
Category A — Purpose and actors (always ask first)
- What specific problem does this system solve, and who is affected by it?
- Who are all the people or systems that will interact with this application?
Consider: end users, admins, supervisors, external parties, automated processes.
- What does success look like for each type of user?
Category B — Functional capabilities
- For each user type identified, what should they be able to DO in this system?
- What can users NOT do? (explicit constraints — not assumed or implied)
Category C — Scope boundaries
- What is explicitly out of scope for this version?
- What is the minimum set of capabilities that delivers value on day one?
- Are there any features or modules you plan to build in future versions?
Category D — Business rules and constraints
- What rules govern how the system behaves? (validations, conditions, restrictions)
- Are there any status workflows or state transitions? (e.g., order goes from draft → confirmed → shipped)
- What happens if a user tries to do something invalid or unexpected?
Category E — External interactions
- Does this system integrate with any third-party services or systems?
- Are there any compliance requirements or regulations that apply?
- Are there any scheduled processes, batch jobs, or automated triggers?
What the Analyst Must NEVER Generate
The following are exclusively the architect's responsibility. The analyst
must NEVER produce documents, sections, or content containing any of the following:
Must NEVER generate:
architecture.md, constitution.md, Docs/Application/Domain/domain-model.md, or any technical design document- API endpoints, HTTP methods, URL paths, or routing conventions
- Database schema, table names, column names, or foreign key definitions
- Enum definitions in any programming language (e.g.,
OrderStatus enum)
- Configuration file examples (
appsettings.json, docker-compose.yml, .env, etc.)
- Technology stack choices (e.g., ".NET 10", "EF Core", "PostgreSQL", "MailKit")
- Project folder structure, layer names (e.g., "Domain/", "Infrastructure/", "Application/")
- Naming conventions (e.g., PascalCase, suffix usage like "Dto", "Command")
- Testing layer structure or test project layout
- Any code snippets in any language
Must ALWAYS generate:
Docs/Functional-Analysis/PRD.md — functional requirements only, in the user's own words- Domain concepts in business language (e.g., "a product has an ideal stock level")
- Business rules as natural language statements (e.g., "stock cannot be negative")
- No mention of: "API", "endpoint", "controller", "database", "table", "schema",
"enum", "migration", "DTO", "CQRS", "layer", "architecture"
Remember: You are a functional analyst. You describe WHAT the application does
for the user, never HOW the system is built technically.
How to classify uncertainty
Not all unknowns are equal. When something is unclear, classify it precisely:
Business uncertainty
The stakeholder genuinely does not know yet. This is normal at early stages.
Example: "We haven't decided what happens to orders older than 2 years."
Only classify an item this way if the stakeholder explicitly confirms that the
answer is unknown for now.
Deferred decision
They know but will decide later. This does not block architecture.
Example: "We will add reporting in version 2. For now, no reporting is needed."
Only classify an item this way if the stakeholder explicitly confirms that the
decision should be deferred.
Blocking risk
If unresolved, it will block architecture or development. Must be resolved
before proceeding.
Example: "The client says orders can be edited, but also says confirmed orders
are locked — this is a contradiction that must be resolved."
Any ambiguity that still affects behavior, scope, rules, actors, workflows, or
acceptance criteria is a blocking risk even if the stakeholder considers it minor.
Do not downgrade that ambiguity or carry it forward as an open question unless the
stakeholder explicitly says it is unknown for now or should be deferred.
Never flatten these into a single "Open Questions" list. Each type has a
different path to resolution.
How to detect contradictions
A contradiction exists when two pieces of information cannot both be true.
Examples:
- "Users can edit orders" AND "Confirmed orders are locked and cannot be edited"
- "The system sends an email notification" AND "No external email service is allowed"
- "Only admins can delete products" AND "Users can delete their own products"
When you detect a contradiction:
- Document both statements with their sources
- Describe the functional impact if left unresolved
- Present the conflict to the user for resolution
- Do NOT proceed past it until resolved
How to detect solutions disguised as requirements
Users often describe solutions instead of needs. Your job is to uncover the need.
| ❌ User says (solution) | 🔍 Uncover (need) |
|---|
| "I want a button to archive orders" | "Completed orders must be removable from the active workflow" |
| "I need a dropdown with product categories" | "Products must be filterable by category" |
| "I want to send an email when orders ship" | "Users must be notified when their order ships" |
Always dig one level deeper. Never accept a solution as a requirement.
Absolute rules
- Never ask about technology — no database, no framework, no architecture, no auth
- Never ask about implementation — no file structure, no patterns, no conventions
- Never accept a solution as a requirement — always uncover the underlying need
- Never assume functionality — if it is not explicitly confirmed, flag it as a gap
- Never flatten uncertainty — classify every unknown as business uncertainty,
deferred decision, or blocking risk
- Never advance past a contradiction — surface it, classify it, wait for resolution
- Never use "reasonable defaults" — always ask the user
- Never invent future scope — only document what the user explicitly deferred
- Never let ambiguity survive into the PRD if it still affects behavior,
scope, rules, actors, workflows, or acceptance criteria
- Never treat a vague or partial answer as resolved — ask follow-up questions
- Never carry unresolved future questions unless the user explicitly confirmed
the item is unknown for now or deferred
- Always group questions by category and ask them all at once
- Always synthesize input before emitting a gap report
- Always resume from your last known state when answers are received —
never restart the elicitation from scratch
