# 需求分析文档

> **事实纪律**:目标、角色、规则和指标必须来自用户或现状证据。未知项写“待确认”并保留责任人；合法不适用项写 `N/A（原因）`，不得猜测补齐。

> **产物定位**:design 能力域的需求澄清产出。把"做什么"想清楚,不是"怎么做"。
> **核心纪律**:先暴露阻塞困惑,禁止把模糊需求直接转成方案;区分事实/假设/需确认。需求声明要有来源证据。
> **反退化纪律**:功能点清单/非功能需求/角色 等表格必须逐条填写真实内容,禁止空表、禁止只填示例行后省略、禁止「…」占位。
> **完成判定**:见文末,不满足不算交付。

## 1. 需求来源
- 需求文档/原型链接:
- 提出人:
- 优先级:使用当前项目已确认的优先级体系；没有既有体系时写“待确认（负责人）”
- 业务目标/价值:

### 1.1 根本目标(fundamental_need)

**用户需要达成什么?(非解决方案描述)**

fundamental_need:
confirmed_by:

> 填写前阅读 skill 的 `examples.md`。正式产物只保留当前项目的真实目标和确认依据。

## 2. 功能点清单

| 编号 | 功能点 | 影响面 | 页面/接口 | 业务规则 | 关联角色 | 前置依赖 | 验收标准 | 状态 |
|------|--------|--------|----------|---------|---------|---------|---------|------|
| | | | | | | | | |

> `影响面` 只填写当前 REQ 实际涉及的稳定 token：`frontend`、`api`、`persistence`、`domain`、`integration`，多个用 `/` 分隔。不要为了通过门禁把所有维度都勾上；API/数据追溯只要求各自适用的 REQ。

## 3. 术语表
| 术语 | 含义 | 同义词（统一为） |
|------|------|----------------|

## 4. 未确认项
| 编号 | 问题 | 影响范围 | 阻塞程度 | 负责人 |
|------|------|---------|---------|--------|
| | | | 阻塞/非阻塞 | |

> 阻塞级未确认项不解决不得进入实现(思考先行)。

## 5. 冲突与越界项
| 项 | 类型（冲突/越界） | 来源 | 处理方式 |
|----|-----------------|------|---------|
| | | | 排除/延期/升级确认 |

## 6. 非功能需求

| 编号 | 类别 | 要求描述 | 验收指标 | 优先级 | 来源 |
|------|------|---------|---------|--------|------|
| | | | | | |

> 需求来源未给出 NFR 时，只记录能从当前项目基线、风险或用户确认中得到的要求；不得为填表虚构类别或通用数值。无法合理数字化时写可复现的验证方法、判定人和证据要求。

## 7. 用户角色与权限
| 角色名称 | 角色描述 | 关联功能 | 数据权限范围 |
|---------|---------|---------|------------|

## 8. 外部接口与集成
| 外部系统 | 接口类型 | 用途 | 数据流向 | 可用性要求 | 负责方 |
|---------|---------|------|---------|----------|--------|
| | | | | | |

> 若系统无外部依赖,显式标注"本系统无外部接口依赖"。

## 9. 系统形态与交付边界

> 决定系统长什么样:是否前后端分离、几个端、各端技术栈。这是下游架构“前端架构/端模块清单”(`FE-*` 端 ID)的依据,**须与用户研讨确认(非 AI 代决)**。
> 没有前端时，端清单写 `N/A（scope.frontend=false，具体原因）`，不要虚构前端端。

- 系统形态：填写当前项目真实形态，例如服务/API、前后端、多端、桌面、CLI、库或组合形态
- 是否有前端:是/否

### 端清单(有前端时逐端填写,每端对应架构“前端架构/端模块清单”的一个 FE-* 端模块)

| 端 ID（FE-*） | 端名称 | 形态 | 技术栈 | 职责 | 本期交付 |
|--------------|--------|------|--------|------|---------|
| | | | | | |

> 端 ID 使用稳定且唯一的 `FE-{语义标识}-{序号}`；语义标识可含多个连字符段，但必须在需求、架构和 `intent.projects` 中逐字一致。
> 无前端时删除空表行，并在本小节写 `N/A（scope.frontend=false，具体原因）`；不要用一排 N/A 冒充端清单。

### 交付边界
- 本期交付的端:
- 后续迭代的端:
- 跨边界契约方式：填写实际采用的 HTTP/GraphQL/RPC/事件/CLI/SDK/文件或其他契约；无跨边界契约写 `N/A（原因）`

## 完成判定

- [ ] “系统形态与交付边界”已填写(形态/端清单/技术栈已与用户研讨确认;涉及前端时须有研讨记录)
- [ ] `fundamental_need` 是用户目标而非解决方案,且 `confirmed_by` 已标记
- [ ] 每个 REQ 有验收标准(可验证,非"功能正常"模糊表述)
- [ ] 阻塞级未确认项已解决或已升级
- [ ] NFR 有可验证指标或明确的验证方法与判定责任
- [ ] 无证据的需求声明已标注来源/不确定
- [ ] 各表格逐条填写真实内容,无空表/无示例行后省略/无「…」占位