Requirements design

Requirements Design

<!-- 中文说明: 这个 skill 负责先把“做什么系统、给谁用、规模多大、有哪些约束”问清楚，避免技术选型过早。 -->

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.