requirements-design

name	requirements-design
description	Clarify business context, business architecture, rough non-functional requirements, and detailed functional requirements for staged software projects. Use when a user gives a vague project idea, needs requirement elicitation, needs business workflows, user roles, acceptance criteria, or implementation-driving requirement slices before architecture or coding.

Requirements Design

Purpose

Use this skill to transform vague project ideas into clear business context and later into detailed implementation-driving requirements.

Two-Pass Requirements

Run requirements in two passes:

1. Business discovery before technology selection.
2. Detailed functional requirements after business architecture and technical architecture are roughly settled.

Business Discovery Questions

When the idea is vague, ask focused questions about:

• Business domain and core problem.
• Target users and user roles.
• System surface: backend API only, web application, admin console, public website, mobile/H5, mini program, desktop/client, integration service, batch/data processing, or mixed.
• Frontend/backend scope: backend required, frontend required, mobile required, open API required, or prototype only.
• User boundary: internal users, external users, partners, public visitors, or mixed.
• Core business capabilities.
• Main workflows and business objects.
• Expected scale after surface is clear: users, traffic, data volume, concurrency, latency.
• Security, audit, compliance, and data sensitivity.
• Existing systems, interfaces, databases, middleware, and deployment constraints.
• Success criteria and out-of-scope items.

Ask only the questions needed for the next decision. Do not turn discovery into a long questionnaire.

Discovery Question Order

Use this order for vague ideas:

1. What kind of system is it and who uses it?
2. Does it need backend, web frontend, mobile/H5, mini program, open API, or only a prototype?
3. Is it internal, external, partner-facing, or public-facing?
4. What are the top 3-5 business capabilities?
5. What are the main workflows and business objects?
6. What rough scale and non-functional requirements matter?
7. What enterprise technology constraints already exist?

Business Architecture Output

Produce docs/00-discovery/project-brief.md and support docs/00-discovery/business-architecture.md with:

• Business background.
• Goals and non-goals.
• User roles.
• Core business capabilities.
• High-level business workflow.
• Main business entities.
• Rough functional scope.
• Rough non-functional requirements.
• Known constraints and open questions.

Use Mermaid for simple workflows when helpful.

After producing the project brief or business architecture, stop and request explicit user review. Do not proceed to technical architecture, stack selection, or detailed requirements until the user approves the current artifact.

Detailed Requirements Output

After architecture and stack direction exist, produce docs/04-requirements/requirements-detail.md with:

• Feature slices.
• User stories or use cases.
• Preconditions and postconditions.
• Business rules.
• Acceptance criteria.
• Permission requirements.
• Data requirements.
• API/database implications.
• Testable scenarios.

After producing detailed requirements, stop and request explicit user review. Do not proceed to API/database design until the user approves the requirements.

Gate Checks

Business discovery is not complete until:

• The system type is clear.
• Users and core workflows are clear.
• Rough scale and non-functional needs are known.
• Major enterprise constraints are known.
• Open questions are explicit.

Detailed requirements are not complete until each critical feature has acceptance criteria and testable scenarios.