# Requirements Analysis

> 从产品原型或用户描述中梳理功能点与细节要求，产出结构化需求文档。全栈工作流第 1 阶段。

- Skill: `rainlib/requirements-analysis` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add rainlib/requirements-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rainlib/requirements-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RainLib (https://skillmd.com/u/rainlib)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rainlib/requirements-analysis

---


# 需求分析

## 何时使用

- 用户描述了产品想法、提供了原型文档或需求草稿，需要整理成可执行需求时。
- 全栈工作流第 1 阶段，由编排器调用。

## 与用户交流（必须）

本阶段在**主对话中执行**，需与用户多轮对话，不得臆造需求。

### 交互原则

- 对模糊点**必须**用 1～3 轮提问补全，**等待用户回复后再写入文档**。
- **所有决策点都应以结构化选项呈现**，让用户选择而非自由输入。例如向用户提供编号选项（"请选择 1/2/3"），可同时选多个时说明"可多选"。
- 允许用户在选项之外补充说明（如选了"其他"后追加描述）。
- 一次不要问超过 3 个问题，避免用户信息过载。

## 执行要点

1. **原型/文档识别**：若用户提供了产品原型截图、PRD 文档或草稿，先提取其中的功能描述与页面流程。
2. **功能点梳理**：按「功能模块 → 功能点」提取列表，不遗漏、不臆造。每个功能点含简要描述与输入输出。
3. **用户故事**：核心功能点转写为用户故事格式（As a ... I want ... So that ...）。
4. **验收标准**：每个功能点附 1～3 条验收标准（Given/When/Then 或要点式）。
5. **细节追问**：对模糊点（角色、边界、数据来源、异常情况）用 1～3 轮简短提问补全，**等待用户回复后再写入**。
6. **输出格式**：使用 [templates/requirements-template.md](templates/requirements-template.md) 填写并产出需求文档。

## 结构化提问引导

以下每组为一轮提问。每轮向用户呈现**结构化选项**，用户选择后再进入下一轮。

### 第 1 轮：基础信息

向用户确认以下内容（可合并为一组选项）：

**Q1 — 是否有原型图或设计稿？**
- A. 有（原型图/设计稿/Figma 链接等）
- B. 有参考网站或竞品
- C. 都没有，从零开始

**Q2 — 项目涉及哪些端？**
- A. 前端 + 后端（全栈）
- B. 仅前端
- C. 仅后端

**Q3 — 用户角色？**（可多选）
- A. 仅单角色（无权限区分）
- B. 普通用户 + 管理员
- C. 多角色（3 种及以上），请简要说明

### 第 2 轮：前端 UI/UX 偏好（Q1 选 C 时必问）

若用户没有原型图/设计稿，向用户呈现以下选项：

**Q4 — 整体风格？**
- A. 现代简约（参考 Linear / Notion）
- B. 商务正式（参考企业后台）
- C. 科技感 / 仪表盘风格
- D. 其他（请补充或提供参考网站）

**Q5 — 主色调？**
- A. 蓝色系
- B. 绿色系
- C. 紫色系
- D. 暗色系（深色背景）
- E. 其他（请说明色值或偏好）

**Q6 — 布局方式？**
- A. 侧边栏导航（左侧菜单 + 右侧内容）
- B. 顶部导航栏
- C. 无导航（单页/落地页）
- D. 其他

**Q7 — 响应式需求？**
- A. 仅桌面端
- B. 桌面 + 平板
- C. 全端适配（桌面 + 平板 + 手机）
- D. 移动端优先

**Q8 — 是否需要暗色模式？**
- A. 需要
- B. 不需要
- C. 后续再说

### 第 3 轮：后端架构偏好（项目涉及后端且未明确时必问）

**Q9 — API 风格？**
- A. RESTful
- B. GraphQL
- C. 无偏好，你来推荐

**Q10 — 认证方式？**
- A. JWT（无状态）
- B. Session（有状态）
- C. OAuth2 第三方登录
- D. 暂不需要认证

**Q11 — 数据库偏好？**
- A. MySQL
- B. PostgreSQL
- C. MongoDB
- D. SQLite（轻量/嵌入式）
- E. 无偏好

**Q12 — 是否需要 API 文档自动生成（Swagger/OpenAPI）？**
- A. 需要
- B. 不需要
- C. 后续再说

### 第 4 轮：补充确认

根据用户前面的回答，对仍有模糊的业务流程、异常分支、非功能需求进行针对性追问。此轮可使用开放式问题。

## 辅助资料

- 完整示例输出：[examples/sample-output.md](examples/sample-output.md) — 展示一份合格需求文档的完整结构与内容深度
- 编写参考：[reference.md](reference.md) — 用户故事 INVEST 原则、验收标准写法、常见追问清单

## 产出

- 一份按模板填写的需求文档，供「技术选型」与后续阶段使用。

## 文档与状态

- 产出写入 `docs/{current_iteration_id}/requirements-{requirements_id}.md`。
- 开始前：调用 `history-manager` skill 的 `get-phase requirements` 和 `check-file` 确认是否已完成。
- 完成后：调用 `history-manager` skill 的 `set-phase requirements {requirements_id}` 记录并推进状态。