Requirements Analysis
Purpose
Turn a request into a clear requirement baseline: what must be true for success, for whom, under what constraints — with confirmed facts, assumptions, and blocking questions kept explicitly separate.
When to Use
- After
request-classification, before application selection.
- When a request's scope, users, or success criteria are not yet explicit.
- Not for a fully-specified trivial change with obvious acceptance criteria.
Inputs
- Classified request and attached context.
- Existing-repo audit findings (if any) from
existing-project-audit.
Discovery Questions
- Who are the users/actors, and what do they need to accomplish?
- What does success look like (measurable where possible)?
- What are the hard constraints (platform, timeline, budget, compliance, existing systems)?
- What is explicitly out of scope?
- Any non-functional needs (performance, security, availability, accessibility)?
Responsibilities
- Extract functional and non-functional requirements.
- Produce three explicit lists: Confirmed facts, Assumptions, Open questions.
- Define success criteria that later acceptance criteria can trace to.
- Flag risks and unknowns that affect application/stack choices.
Required Workflow
- Read the classified request + audit findings.
- Draft functional + non-functional requirements.
- Sort every statement into Confirmed / Assumption / Question.
- Define success criteria.
- Surface blocking questions to the user; proceed on stated assumptions for non-blocking gaps.
- Record the baseline in
../../projects/current/.
Decision Rules
- A statement is Confirmed only if the user stated it or the repo proves it; otherwise it's an Assumption.
- Ask only questions whose answers change the plan; document the rest as assumptions.
- Non-functional requirements (security, PII, scale) feed phase and testing generation — never drop them.
Rules
- Keep the three lists distinct and visible through planning.
- Do not invent requirements to fill gaps — mark them assumptions.
- Tie success criteria to observable outcomes.
Anti-Patterns
- Blending assumptions into "facts."
- Endless clarifying questions that block progress on non-blocking points.
- Gold-plating: adding requirements the user never asked for.
Validation Checklist
Definition of Done
A recorded requirement baseline with success criteria and the three separated lists, sufficient for application-selection and stack-recommendation to proceed.
Related Skills
request-classification, existing-project-audit, application-selection, stack-recommendation, project-orchestrator.
Related Knowledge
../../knowledge/ (domain glossary/business rules, if present).
Related References
Relevant ../../references/<topic>/ only if a domain needs grounding.
Context Loading Guidance
- Requires: the classified request, audit findings (if any), success-criteria intent.
- Does not require: stack details, other skills' bodies, unrelated references.
- May load:
existing-project-audit output; a single domain reference folder if needed.
- Stop when: the baseline and three lists are recorded.
Token Efficiency Guidance
Summarize source material into the three lists rather than quoting it wholesale. Load a reference folder only if the domain is genuinely unclear.
1---2name: requirements-analysis3description: Use after classification to extract goals, constraints, users, and success criteria from a request, and to separate confirmed facts from assumptions and open questions. Produces the requirement baseline the rest of the plan depends on.4---56# Requirements Analysis78## Purpose910Turn a request into a clear requirement baseline: what must be true for success, for whom, under what constraints — with confirmed facts, assumptions, and blocking questions kept explicitly separate.1112## When to Use1314- After `request-classification`, before application selection.15- When a request's scope, users, or success criteria are not yet explicit.16- **Not** for a fully-specified trivial change with obvious acceptance criteria.1718## Inputs1920- Classified request and attached context.21- Existing-repo audit findings (if any) from `existing-project-audit`.2223## Discovery Questions2425- Who are the users/actors, and what do they need to accomplish?26- What does success look like (measurable where possible)?27- What are the hard constraints (platform, timeline, budget, compliance, existing systems)?28- What is explicitly out of scope?29- Any non-functional needs (performance, security, availability, accessibility)?3031## Responsibilities3233- Extract functional and non-functional requirements.34- Produce three explicit lists: **Confirmed facts**, **Assumptions**, **Open questions**.35- Define success criteria that later acceptance criteria can trace to.36- Flag risks and unknowns that affect application/stack choices.3738## Required Workflow39401. Read the classified request + audit findings.412. Draft functional + non-functional requirements.423. Sort every statement into Confirmed / Assumption / Question.434. Define success criteria.445. Surface blocking questions to the user; proceed on stated assumptions for non-blocking gaps.456. Record the baseline in `../../projects/current/`.4647## Decision Rules4849- A statement is **Confirmed** only if the user stated it or the repo proves it; otherwise it's an **Assumption**.50- Ask only questions whose answers change the plan; document the rest as assumptions.51- Non-functional requirements (security, PII, scale) feed phase and testing generation — never drop them.5253## Rules5455- Keep the three lists distinct and visible through planning.56- Do not invent requirements to fill gaps — mark them assumptions.57- Tie success criteria to observable outcomes.5859## Anti-Patterns6061- Blending assumptions into "facts."62- Endless clarifying questions that block progress on non-blocking points.63- Gold-plating: adding requirements the user never asked for.6465## Validation Checklist6667- [ ] Functional requirements captured.68- [ ] Non-functional requirements captured (security/PII/scale/etc.).69- [ ] Confirmed / Assumptions / Questions lists explicit.70- [ ] Success criteria defined and measurable where possible.71- [ ] Blocking questions raised; assumptions stated for the rest.7273## Definition of Done7475A recorded requirement baseline with success criteria and the three separated lists, sufficient for `application-selection` and `stack-recommendation` to proceed.7677## Related Skills7879`request-classification`, `existing-project-audit`, `application-selection`, `stack-recommendation`, `project-orchestrator`.8081## Related Knowledge8283`../../knowledge/` (domain glossary/business rules, if present).8485## Related References8687Relevant `../../references/<topic>/` only if a domain needs grounding.8889## Context Loading Guidance9091- **Requires:** the classified request, audit findings (if any), success-criteria intent.92- **Does not require:** stack details, other skills' bodies, unrelated references.93- **May load:** `existing-project-audit` output; a single domain reference folder if needed.94- **Stop when:** the baseline and three lists are recorded.9596## Token Efficiency Guidance9798Summarize source material into the three lists rather than quoting it wholesale. Load a reference folder only if the domain is genuinely unclear.
ahtishamshahzad