Files

314 lines
13 KiB
Markdown
Raw Permalink Normal View History

# URD 模板(User Requirements Document)
> **定位**:URD(用户需求文档,与 PRD 等价)是**产品级**需求描述——定义"产品是什么、为谁服务、用户要完成哪些任务、每个功能如何被用户感知和使用"。它是软件项目**一切后续文档的输入**:阶段 ① 需求规格(BR/E/AC)、② 架构、③ 详细设计、④ UI Spec、测试用例,都必须能追溯到本文档的功能条目。
> **适用**:本模板用于兴邦金租 AI 评审平台及新版 AI 预审的用户需求撰写;正文按业务人员语言描述,区分演示、真实数据试点与正式审批。
> **用法**:复制本文件为 `<产品名>-URD-<版本>-<日期>.md`,按占位符 `<...>` 填写;删除不适用章节并记录删除理由;编号规则见第 0 节,不得破坏。
---
## 0. 使用说明与编号规则(写文档前先读;成稿后可删)
### 0.1 文档关系
```text
商业/产品设想(PRD 草稿、口头想法)
│ 提炼、确认边界
▼
本 URD —— 用户可感知的功能需求(本文档)
│ 拆解为可实现的单点需求
▼
阶段①规格(BR/E/AC)→ ② 架构 → ③ 详细设计 → ④ UI Spec → 实现 → 测试
```
- URD 回答 **"用户要什么、为什么、长什么样、做到什么程度算好"**;
- 阶段 ① 规格回答 **"这一版改动具体怎么实现、怎么验收"**;
- URD 讲用户语言,不写内部实现(不写表结构、类名、内部工具调用);确有底层约束须写"约束与假设"。
### 0.2 编号规则(只追加、不重排、弃用标记 withdrawn)
| 前缀 | 含义 | 示例 |
|---|---|---|
| `MOD-xx` | 模块编号 | `MOD-03` |
| `FR-<模块简码>-<nn>` | 功能点编号(模块简码见 6.1 清单) | `FR-STU-04` |
| `EX-<模块简码>-<nn>` | 功能点的异常/边界场景 | `EX-DASH-02` |
| `NFR-xx` | 非功能需求 | `NFR-07` |
| `SEC-xx` | 安全/权限需求 | `SEC-03` |
| `AC-xx` | 端到端验收标准 | `AC-10` |
| `OQ-xx` | 待决策/开放问题 | `OQ-04` |
### 0.3 书写纪律(继承仓库阶段①规则)
1. 每条功能点 = **一个用户可感知的行为**,写成"用户可验证"的描述;散文式一段话超过 5 行 → 拆成行为列表。
2. 每个功能点必须写 **主流程**(happy path)与 **异常/边界**(用户会遇到的不顺路径),禁止只写 happy path。
3. 写不动的先 `TBD` / `OQ-xx`(带 owner 与期限),禁止编造。
4. 优先级统一 `P0`(MVP 必做)/ `P1`(近期待做)/ `P2`(远期)。
5. 所有状态、权限、阈值是可配置项时写明"默认值 + 可配置范围",不写死。
---
## 1. 文档控制
### 1.1 文档信息
| 项 | 内容 |
|---|---|
| 文档名称 | `<产品名> 用户需求文档(URD)` |
| 文档编号 | `URD-<产品简称>-<版本>` |
| 版本 / 日期 | `V<0.x> · <yyyy-mm-dd>` |
| 产品名称 / 版本 | `<对外名称> V<目标版本>` |
| 文档状态 | 草稿 / 评审中 / 已确认 / 已发布 |
| 作者 / 评审人 | `<姓名或角色>` |
| 维护位置 | `<仓库路径>` |
### 1.2 历史记录
| 日期 | 版本 | 作者 | 变更记录 |
|---|---|---|---|
| yyyy-mm-dd | V0.1 | xxx | 首次创建;<列出范围,如"第 1–3 章 + MOD-01" > |
### 1.3 评审与分发
| 角色 | 评审关注点 |
|---|---|
| 产品负责人 | 范围、优先级、验收标准是否符合商业意图 |
| 设计(UI/UX) | 功能点的用户流程与界面要求是否可实现 |
| 研发负责人 | 是否存在未定义边界或不可实现的约束 |
| 测试负责人 | 每条功能点是否可验证、异常是否齐全 |
| 市场/实施 | 话术与演示脚本是否与功能一致 |
---
## 2. 目的与范围
### 2.1 文档目的
> 一句话:本文档定义 `<产品名>` 的用户需求——`<它解决谁的什么问题,交付什么结果>`。
说明:本文档的读者(产品/设计/研发/测试/市场)、文档如何被使用(培训材料?需求基线?)。
### 2.2 产品定义
| 项 | 内容 |
|---|---|
| 一句话结论 | `<产品做什么、为谁做、交付物>` |
| 核心价值 | `<用户购买/使用它的理由,1–3 条>` |
| 交付结果 | `<安装包/服务/平台等>` |
### 2.3 目标范围(In Scope)
- `<范围一:……>`
- `<范围二:……>`
### 2.4 非目标(Out of Scope)——与范围同等重要,逐条写明排除理由
| 排除项 | 理由 | 可能时机 |
|---|---|---|
| `<明确不做的事>` | `<为什么本期不做>` | 后续版本 / 永不 |
| `<例如:开放第三方市场>` | `<例如:首版只支持受控模板>` | V2+ |
### 2.5 成功标准(产品级,一句话可判)
- `<首个版本成功的硬性标志,如:客户经理可完成一次带证据引用和补件清单的项目预审>`
---
## 3. 参考文献
| 文档/来源 | 版本/日期 | 与本文档的关系 |
|---|---|---|
| `<产品定义 PRD>` | V0.1 | 本文档的功能蓝本 |
| `<代码功能事实:codewiki / docs 架构文档>` | 生成日期 | 现状能力基线 |
| `<竞品/标准/协议>` | | 约束来源 |
| `<阶段①规格草稿>` | | 已确认决策的回写来源 |
---
## 4. 术语、角色与成功标准
### 4.1 术语表
| 术语 | 定义(用户语言,可配图) |
|---|---|
| `<领域词,如 Agent / 面板 / Scope>` | `<一句话说清>` |
### 4.2 用户角色
| 角色 | 画像 | 主要任务 | 成功标准 | 常用模块 |
|---|---|---|---|---|
| `<角色>` | `<谁,技术背景>` | `<日常要完成什么>` | `<做到什么算好>` | MOD-xx |
| 例:客户经理 | 熟悉融资租赁业务 | 提交材料并理解预审意见 | 明确项目障碍与下一步 | MOD-02/05 |
### 4.3 角色 × 模块 关注矩阵(可选)
| | MOD-01 | MOD-02 | MOD-03 | … |
|---|---|---|---|---|
| 角色 A | 使用 | 使用 | – | |
| 角色 B | – | 审核 | 使用 | |
---
## 5. 产品概览与核心体验
### 5.1 产品背景与目标
`<为什么做这个产品;本版本要证明什么(如:证明某类用户能独立完成某闭环)。>`
### 5.2 信息架构与模块关系
```text
一级入口/模块树(文字树或图)
├── <模块一>
│ ├── <子功能>
└── ...
```
`<模块之间的依赖与数据走向一句话说明。>`
### 5.3 核心用户流程(端到端)
`<步骤表:用户从进入到完成一次价值闭环的全过程>`(例:选择项目 → 确认材料 → 发起预审 → 查看证据 → 补件复核)
### 5.4 体验原则
1. `<先给结果,再邀请对话>`(示例原则,按产品改写)
2. `<每个结论可解释>`
3. `<异常与关键选择集中呈现,普通状态不打扰>`
4. `<任何能力可见、可停用、可替换>`
5. ...
### 5.5 交付面与平台约束
| 交付面 | 说明 | 优先级 |
|---|---|---|
| `<客户经理工作台 / 评审工作台 / 管理配置>` | `<项目权限、材料来源、运行状态、异常恢复>` | P0/P1 |
---
## 6. 功能模块需求(本文档主体)
### 6.1 模块清单与划分说明
> 划分原则:按**用户任务闭环**划分模块(不是按技术层);模块间尽量低耦合、每个模块有明确负责人与验收场景。
| 模块 | 模块名 | 一句话职责 | 主要角色 | 简码 | 优先级 |
|---|---|---|---|---|---|
| MOD-01 | `<名称>` | `<为谁解决什么>` | | `<STU/DASH…>` | P0 |
| MOD-02 | ... | | | | |
> 模块依赖图(可选):`MOD-02 依赖 MOD-01 的发布产物` 等。
### 6.2 各模块详细需求
> 每模块复制下面一节;模板中 MOD-xx 以 MOD-01 为例。
#### MOD-01 `<模块名>`
**模块概述**
| 项 | 内容 |
|---|---|
| 目的 | `<该模块在用户任务闭环中的位置与作用>` |
| 用户 | `<角色>` |
| 入口 | `<从哪个一级入口/页面进入>` |
| 依赖 | `<依赖哪些其他模块或外部系统>` |
| 核心对象 | `<用户在该模块操作的对象:如 Agent、面板、版本>` |
**功能点总览**
| 编号 | 功能名称 | 用户可完成的任务 | 优先级 |
|---|---|---|---|
| FR-XXX-01 | `<名称>` | `<一句话用户价值>` | P0 |
| FR-XXX-02 | ... | | P1 |
**功能点详述**
##### FR-XXX-01 `<功能名称>`(P0)
- **功能描述**:`<该功能是什么;用户可用它完成什么;关键行为逐条列出,如:>`
1. `<行为一>`
2. `<行为二>`
- **前置条件**:`<进入该功能前必须满足的条件,如已登录、已有数据源授权>`(无则写"无")
- **主流程**:
| 步骤 | 用户操作 | 系统响应 |
|---|---|---|
| 1 | `<操作>` | `<响应/界面变化>` |
| 2 | ... | |
- **行为规则与边界**:
- `<规则/边界一:如"默认展示最近 7 天,可配置 1–90 天">`
- **异常与边界场景**:
| 编号 | 场景 | 用户可见行为 | 后备方案 |
|---|---|---|---|
| EX-XXX-01 | `<如:数据源超时>` | `<提示什么>` | `<重试/降级显示陈旧数据并标注>` |
- **UI 与交互要求**:`<布局要点、状态(空/加载/错误/正常)、交互手势、可访问性>`(详见阶段 ④ UI Spec)
- **权限与安全**:`<该功能涉及的权限等级(见第 9 章 L0–L3)、确认点、审计>`(无则写"无额外要求")
- **验收要点**:`<该功能可验证的 3–6 条要点,对应第 11 章 AC>`:
- [ ] 要点一
- [ ] 要点二
- **关联与备注**:`<关联功能点/引用文献/开放问题 OQ-xx>`(无则写"—")
##### FR-XXX-02 …(复制上面小节)
---
## 7. 数据与内容需求(若产品以数据/面板/内容为核心)
### 7.1 数据类型与口径
| 内容 | 用户要定义什么 | 系统如何使用 |
|---|---|---|
### 7.2 内容/数据生成规则
### 7.3 展示与交互要求(数据面)
---
## 8. 非功能需求
| 编号 | 类别 | 需求 | 目标/阈值 |
|---|---|---|---|
| NFR-01 | 性能 | `<首屏/操作响应>` | `<如 ≤2s>` |
| NFR-02 | 可用性 | `<新用户无培训完成核心任务>` | `<如 ≤60 分钟>` |
| NFR-03 | 可靠性与离线 | `<数据源/服务不可用时的降级>` | |
| NFR-04 | 兼容性 | `<OS/浏览器/分辨率>` | |
| NFR-05 | 可访问性 | `<键盘/读屏/对比度>` | |
| NFR-06 | 国际化与本地化 | `<语言/时区/货币/格式>` | |
| NFR-07 | 数据与隐私 | `<数据保留/删除/导出>` | |
| NFR-08 | 可观测性 | `<日志/审计/用量统计>` | |
| NFR-09 | 安装升级 | `<安装包、升级与回滚>` | |
> 每行写清"可度量阈值",无阈值 = 不可验收。
---
## 9. 安全、权限与信任
### 9.1 用户可理解的动作等级
| 等级 | 含义 | 产品行为 | 示例 |
|---|---|---|---|
| L0 查看 | 只读取和展示 | 授权后自动运行,留读取记录 | |
| L1 准备 | 生成草稿不对外提交 | 可自动完成,用户可编辑 | |
| L2 确认后执行 | 改变外部系统/通知他人 | 必须展示详情由用户确认 | |
| L3 强确认 | 金钱/敏感/不可逆 | 二次确认或强身份验证,默认不批量 | |
### 9.2 必须由产品层提供的能力(按产品改写)
- `Scope 隔离 / 最小权限 / 凭证托管 / 执行确认 / 可撤销与熔断 / 全链路记录 / 发布前安全测试`
### 9.3 信任界面要求
- `<每个展示面与动作卡应呈现的信任信息:版本、数据时间、来源、权限等级、失败后果>`
---
## 10. MVP 范围与版本规划
### 10.1 MVP 目标与样板场景
| 目标 | 验证重点 | 最低闭环 |
|---|---|---|
### 10.2 P0 / P1 / P2 范围表
| 产品/模块 | P0(MVP) | P1 | P2(明确不做入近期) |
|---|---|---|---|
### 10.3 推荐交付阶段
| 阶段 | 产品结果 | 验收门 |
|---|---|---|
---
## 11. 验收标准与产品指标
### 11.1 端到端验收
| 编号 | 验收标准(按角色、可执行) |
|---|---|
| AC-01 | `<Given/When/Then 或可执行描述>` |
### 11.2 核心产品指标
| 指标 | 定义 | 目标 |
|---|---|---|
| `<首次价值时间>` | `<定义>` | `<阈值>` |
---
## 12. 假设与待决策事项
| 编号 | 事项 | V0.x 默认假设 | 需要的产品决策 | Owner | 期限 |
|---|---|---|---|---|---|
| OQ-01 | `<如:首端平台>` | `<默认>` | `<待决问题>` | | |
> 未决事项不阻止开始原型,但进入正式排期前必须关闭。
---
## 附录
### A. 功能点索引(全部 FR / EX 编号 → 模块位置,自动核对用)
| 编号 | 功能 | 模块 | 优先级 | 状态(草稿/已确认/withdrawn) |
|---|---|---|---|---|
### B. 产品话术与演示脚本(可选)
### C. 变更对照(本版相对上一版的增删)
---
> **模板维护**:本模板本身受仓库 ⑧ 学习与沉淀 约束——使用中发现结构缺陷,更新本文档并记入"变更记录"(放文末)。
## 兴邦填写约束(XB-1.0 · 2026-09-28)
- 写清主审 Agent、专项判断模型和正式审批的职责;不把 Jev 单题输出当作审批决定。
- 历史经验须描述争议、核查、证据和判断变化;仅有最终结果时标过程缺失。
- 每项功能明确材料来源、项目/数据域权限、模拟与正式结果边界、失败与人工复核路径。
- 没有真实校准数据时不承诺通过率、准确率或改善幅度;未决项有 owner 和进入阶段。
- 规格、架构、UI 和测试均回链到功能编号。可参考 [兴邦v2 URD](../../v2/URD.md)。