从十大领域到需求文档结构:为什么不同项目不应该使用同一套模板?

前一篇文章中，我整理了“企业软件解决方案设计的十大领域”。

它试图回答一个基础问题：

设计企业软件解决方案时，我们需要从哪些专业维度思考，才能避免只看页面和功能，而忽略流程、数据、规则、状态、集成和控制？

随后，我又把十大领域转化成了一张产品需求文档（PRD）和功能需求文档（FRD）的设计思考框架。

它进一步回答：

面对一个具体需求，我们应该按照什么路径提出问题，才能逐步形成完整、可开发、可测试的系统方案？

但真正开始写FRD时，还会遇到第三个问题：

不同项目的FRD，应该使用完全相同的结构吗？

实际项目中，新建系统、现有系统增强和系统替换迁移，承担的设计任务并不相同。

同样，一个以状态流转为核心的需求，与一个以数据、计算或系统集成为核心的需求，需要展开的内容也不会完全一样。

如果所有项目都套用同一份模板，通常会产生两个相反的结果。

一种是文档包含大量看似完整的章节，却没有回答当前项目真正困难的问题。

另一种是文档只记录页面、字段和几个功能点，没有覆盖数据、规则、状态、权限、异常和验收。

FRD需要稳定的专业底座，但不应该有一套对所有项目完全相同的目录。

比较合理的结构是：

• 所有FRD都需要具备的固定结构。

• 由项目性质决定的变更模式。

• 从十大领域中选择的可选深化内容。

最终形成：

固定结构＋一种变更模式＋若干可选深化包＝当前项目适用的FRD结构。

一、先把三层知识框架连接起来

在继续讨论FRD结构之前，需要先说明十大领域、PRD／FRD思考框架和本文之间的关系。

它们不是三套彼此独立的方法，而是同一棵知识树的三个层级。

1．十大领域是一张知识地图

企业软件解决方案设计的十大领域包括：

• 业务流程方案。

• 功能与业务规则。

• 数据方案。

• 工作流与状态管理。

• 集成方案。

• 权限与安全控制。

• 交互与用户体验。

• 报表与分析。

• 自动化与智能化。

• 非功能需求与技术约束。

这十个领域回答的是：

一个完整的企业软件解决方案，需要具备哪些方面的专业知识？

它们是横向的知识分类，帮助我们从不同角度观察同一个需求。

例如，一项审批功能表面上属于工作流与状态管理，但同时会涉及：

• 业务流程中的责任分工。

• 功能与业务规则中的审批条件。

• 数据方案中的审批记录。

• 权限与安全控制中的职责分离。

• 自动化与智能化中的通知和超时处理。

因此，十大领域不是十个彼此隔离的模块，而是十个相互关联的设计视角。

2．PRD／FRD思考框架是一条分析路径

PRD／FRD设计思考框架把十大领域重新组织成六个分析阶段：

• 方向与范围。

• 端到端业务与协作。

• 功能、规则与状态。

• 数据与用户体验。

• 集成、权限与控制。

• 输出、自动化与交付质量。

这六个阶段回答的是：

在分析一个具体需求时，应该按照什么顺序把问题想清楚？

因此：

十大领域说明要掌握什么，PRD／FRD思考框架说明怎样把这些知识应用到具体需求中。

3．FRD结构配置解决怎样落到文档

本文继续向下回答：

当分析完成以后，应该怎样根据项目性质，把结果组织成适合当前项目的FRD？

这一步不再增加新的知识领域，而是解决文档结构选择问题。

整条知识路径可以概括为：

二、所有FRD都应该具备什么

FRD可以根据项目调整，但不能完全自由发挥。

无论项目属于哪一种变更模式，都有一些内容必须经过判断。这些内容构成FRD的固定结构。

固定不等于每个部分都要写得很长，而是不能在没有判断的情况下直接遗漏。

如果某项内容不适用，可以明确说明原因。

1．文档信息与变更记录

至少应该包括：

• 文档版本。

• 当前状态。

• 负责人。

• 修改日期。

• 本次主要变化。

• 评审和确认状态。

对于持续更新的FRD，这些内容不是行政信息。

它们决定团队看到的是不是同一版本，也帮助开发、测试和业务识别哪些决定已经改变。

2．背景、目标与范围

这一部分需要回答：

• 为什么做。

• 要解决什么业务问题。

• 谁会使用或受到影响。

• 期望产生什么业务结果。

• 本次做什么。

• 本次不做什么。

• 存在哪些假设、约束和依赖。

“提升效率”“优化体验”“加强管理”不构成完整目标。

即使暂时无法量化，也应该说明希望改变什么可观察的业务结果。

3．用户、角色与业务场景

FRD不能只有功能清单，还需要说明功能出现在哪个业务场景中。

至少应该回答：

• 谁触发业务。

• 什么事件触发。

• 业务从哪里开始。

• 经过哪些关键步骤。

• 最终产生什么业务结果。

• 有哪些正常、替代和异常场景。

如果一项功能找不到明确的使用者、触发事件和业务结果，它很可能还没有被真正定义。

4．端到端业务流程与系统边界

这一部分承接十大领域中的“业务流程方案”。

它需要说明：

• 业务如何端到端运行。

• 哪些步骤由用户完成。

• 哪些步骤由当前系统完成。

• 哪些步骤由外部系统完成。

• 每个环节的输入和输出是什么。

• 系统责任从哪里开始，到哪里结束。

• 上下游团队或系统分别负责什么。

这部分不一定需要非常复杂的流程图，但必须让读者理解功能为什么存在于当前流程中。

5．功能与系统行为

每项核心功能至少需要说明：

• 谁或什么系统触发。

• 触发事件是什么。

• 前置条件是什么。

• 用户执行什么动作。

• 系统作出什么响应。

• 输入和输出是什么。

• 数据和状态发生什么变化。

• 最终产生什么业务结果。

FRD不能只写“支持新增、修改、删除、提交和审批”。

这些词只说明了操作名称，没有说明：

• 什么情况下允许操作。

• 什么情况下禁止操作。

• 操作以后系统发生什么变化。

• 失败以后如何处理。

功能名称不是功能设计，系统行为才是功能设计。

6．数据、规则、状态和权限影响

并不是每个需求都需要完整的数据模型、状态机或权限矩阵，但每个需求都应该扫描这些方面是否受到影响。

至少需要判断：

• 是否新增或修改业务对象。

• 是否新增或修改字段。

• 是否改变计算或判断规则。

• 是否改变对象状态。

• 是否改变角色和操作权限。

• 是否影响上下游系统。

• 是否需要留下新的审计证据。

简单需求可以在功能说明中回答。

复杂需求则需要调用相应的可选深化包。

7．异常、纠错与恢复

正常路径能够运行，不代表方案已经完整。

FRD至少应该判断：

• 输入错误怎么办。

• 重复提交怎么办。

• 权限不足怎么办。

• 当前状态不允许操作时怎么办。

• 系统处理中断怎么办。

• 外部系统失败怎么办。

• 部分成功怎么办。

• 用户撤回或业务驳回怎么办。

• 取消、作废和冲销以后怎么办。

• 是否允许人工补救。

更重要的问题是：

处理失败、撤销或冲销以后，数据和状态应该回到哪里？

8．非功能需求与技术约束

这一部分承接十大领域中的“非功能需求与技术约束”。

至少应该判断：

• 响应时间。

• 数据量。

• 并发。

• 可用性。

• 可靠性。

• 安全。

• 可维护性。

• 可扩展性。

• 兼容性。

• 现有平台和架构限制。

如果暂时没有明确指标，可以标记为待确认，但不应使用“响应快速”“性能良好”“系统稳定”等无法验证的表达。

9．验收标准与未确认问题

每项关键需求都应该能够回答：

• 如何证明已经实现。

• 正常路径如何验证。

• 禁止路径如何验证。

• 异常和恢复如何验证。

• 权限差异如何验证。

• 数据和业务结果如何核对。

同时，需要区分：

• 已确认的决定。

• 暂时采用的假设。

• 尚未回答的问题。

• 已识别的风险。

• 需要谁继续确认。

不能被验证的需求，通常还不是一项完整的系统要求。

三、三种变更模式分别改变什么

固定结构保证FRD具备基本专业质量，变更模式则决定FRD还需要承担什么额外任务。

三种变更模式不是新的解决方案领域。

它们回答的是：

当前项目面对的是什么性质的改变？

1．新建系统或新模块

新建系统没有稳定的目标行为可以参考。

FRD需要帮助业务、产品、开发和测试建立共同理解。

除了固定结构以外，通常还需要增加：

• 目标业务模式。

• 核心业务概念和术语。

• 完整功能地图。

• 用户角色和职责。

• 完整的端到端目标流程。

• 业务对象及其关系。

• 对象生命周期。

• 初始权限模型。

• 系统边界和上下游关系。

• 初始配置和基础数据。

• 上线后的运营与支持方式。

它主要回答：

这个系统从一开始应该怎样成立？

新建系统中，很多争议并不是字段应该放在哪里，而是业务本身尚未形成统一定义。

如果业务对象、责任和规则没有先定义清楚，页面写得越详细，返工可能越多。

2．现有系统增强或修改

已有系统已经存在稳定的用户、数据、代码和运行方式。

FRD不一定需要重新描述整个系统，但必须把变化及其影响讲清楚。

除了固定结构以外，通常还需要增加：

• 当前系统行为。

• 当前存在的问题。

• 当前与目标差异。

• 功能变更摘要。

• 受影响流程。

• 受影响字段、规则和状态。

• 受影响接口和报表。

• 必须保持不变的行为。

• 旧记录兼容方式。

• 回归测试范围。

• 发布和启用方式。

• 必要时的回退方案。

它主要回答：

具体改变什么，会影响什么，什么必须保持不变？

现有系统增强可以采用差异方式编写，但不能因为只写变化而失去必要上下文。

字段设计也不能因为属于旧系统改造而自动简化。只要字段的来源、校验、联动、权限或生命周期发生变化，就仍然需要详细定义。

旧系统代码可以帮助还原当前行为，但不能自动成为未来需求。

代码中可能包含：

• 真实业务规则。

• 旧平台限制。

• 临时补丁。

• 历史兼容逻辑。

• 已经不再合理的处理方式。

FRD需要区分哪些应该保留，哪些应该重新设计。

3．系统替换与迁移

系统替换既不是单纯定义新系统，也不是修改旧系统。

它同时面对两个问题：

• 未来应该怎样运行。

• 现有业务怎样安全地进入未来方案。

除了固定结构以外，通常还需要增加：

• 旧系统能力盘点。

• 新旧方案差距分析。

• 保留、替换、重新设计和废弃决定。

• 新旧业务对象映射。

• 新旧字段映射。

• 数据转换和清洗规则。

• 历史数据范围。

• 未完成业务处理。

• 余额和关联关系处理。

• 新旧规则生效边界。

• 数据核对与业务对账。

• 上线切换。

• 并行运行。

• 回退方案。

• 旧系统停用和历史查询。

它主要回答：

目标方案怎样运行，以及当前业务怎样安全地走到目标方案？

迁移项目中最危险的误区，是只设计未来状态，却没有定义现在怎样过去。

一个设计正确的新系统，并不自动意味着它可以安全上线。

四、八个可选深化包来自哪里

变更模式决定项目是在定义、改变还是转换，但不能决定所有FRD内容。

同样是现有系统增强，有的项目主要修改状态流程，有的主要调整数据和计算规则，有的则主要涉及系统集成。

因此，需要根据当前项目的主要设计复杂度，从十大领域中选择需要深入展开的内容。

本文将这些内容称为“可选深化包”。

它们不是新的知识分类，也不是对十大领域的替代。

十大领域中的“业务流程方案”和“非功能需求与技术约束”已经进入FRD固定结构。

“功能与业务规则”中的基本功能行为同样属于固定内容，而复杂规则、计算和配置则按需要继续深化。

由此形成八个可选深化包。

1．功能与业务规则深化包

适用于存在复杂计算、资格判断、额度、优先级或可配置规则的需求。

通常需要增加：

• 业务规则清单。

• 条件和结果。

• 决策表。

• 计算公式。

• 输入参数。

• 精度和舍入。

• 规则优先级。

• 规则冲突处理。

• 生效日期和适用范围。

• 参数配置。

• 修改权限和审批。

• 规则版本。

• 计算示例。

• 零值、负数、空值和边界值处理。

如果规则可能发生变化，需要进一步判断：

这项规则应该写入程序，还是由授权用户进行配置？

2．数据方案深化包

适用于主数据、交易数据、复杂表单、历史数据、数据迁移和数据质量要求较高的场景。

通常需要增加：

• 核心业务对象。

• 对象定义。

• 对象之间的关系。

• 唯一标识。

• 重复判断依据。

• 权威数据来源。

• 数据所有权。

• 字段字典。

• 必填、默认值和自动带值。

• 字段校验和联动。

• 生效与失效。

• 作废、归档和删除。

• 历史版本。

• 数据质量。

• 数据保留要求。

字段字典不应该只有字段名称和类型。

它还应该说明字段代表什么业务事实、从哪里来、由谁维护，以及在什么条件下允许变化。

3．工作流与状态管理深化包

适用于审批、工单、订单、任务、多阶段处理和对象生命周期。

通常需要增加：

• 状态名称和业务含义。

• 状态进入与退出条件。

• 允许和禁止的状态转换。

• 状态转换矩阵。

• 不同角色在不同状态下允许的操作。

• 任务分配和待办。

• 通知、超时和升级。

• 撤回、驳回和重新打开。

• 并行任务。

• 流程完成后的状态恢复。

状态设计不能只画一张正常路径图。

真正的风险通常存在于非法跳转、重复触发、并发操作和异常恢复中。

4．集成方案深化包

适用于接口、文件交换、消息、批量任务和跨系统数据同步。

通常需要增加：

• 上下游系统和责任边界。

• 调用方向。

• 触发时点。

• 实时或批量处理。

• 请求和响应。

• 字段映射。

• 编码、币种和单位转换。

• 成功确认。

• 重复控制和幂等。

• 超时、重试和补发。

• 部分成功。

• 错误记录。

• 接口对账。

• 监控与告警。

• 身份验证和授权。

• 集成失败后的业务状态。

接口能够传送数据，只能证明技术连接存在。

业务是否完整，还要看失败以后怎样处理，以及两边的数据能否长期保持一致。

5．权限与安全控制深化包

适用于财务、审批、敏感数据、多公司、多组织和受监管业务。

通常需要增加：

• 角色权限矩阵。

• 公司和组织范围。

• 数据权限。

• 状态权限。

• 操作权限。

• 字段权限。

• 职责分离。

• 禁止自批。

• 代理和紧急授权。

• 特殊修改。

• 审计日志。

• 原值和新值。

• 操作原因。

• 敏感数据保护。

• 数据保留要求。

权限不能只控制用户能否打开页面。

还要控制用户能看到什么数据、在什么状态下执行什么操作，以及关键操作是否留下足够证据。

6．交互与用户体验深化包

适用于复杂表单、大量人工操作、移动端、搜索选择和容易误操作的任务。

通常需要增加：

• 用户任务流。

• 页面入口。

• 页面状态。

• 字段显示和联动。

• 必填、默认值和只读条件。

• 搜索、筛选和选择。

• 排序和分页。

• 批量操作。

• 错误提示。

• 防误操作。

• 空状态和加载状态。

• 成功反馈。

• 设备和可访问性要求。

用户体验不能代替业务规则，但不合理的交互可能导致正确的规则被错误执行。

7．报表与分析深化包

适用于查询、报表、管理看板、异常监控和数据导出。

通常需要增加：

• 输出使用者。

• 使用目的。

• 支持什么业务判断。

• 指标定义。

• 计算口径。

• 数据来源。

• 统计时间点。

• 更新频率。

• 查询维度和筛选条件。

• 逐层查看。

• 导出和订阅。

• 数据权限。

• 异常阈值。

报表需求不能止于“需要一张报表”。

首先需要确认：

使用者准备根据这份输出作出什么决定，或者采取什么行动？

8．自动化与智能化深化包

适用于自动编号、自动计算、自动匹配、自动分派、智能推荐和人工智能（AI）判断。

通常需要增加：

• 自动化触发条件。

• 自动执行内容。

• 输入数据。

• 判断依据。

• 输出结果。

• 阈值或置信度。

• 人工确认点。

• 无法判断时的替代路径。

• 人工覆盖权限。

• 覆盖原因。

• 错误结果纠正。

• 审计和可追溯。

• 质量监控。

• 反馈闭环。

自动化设计不能只描述系统在理想情况下做什么。

它还需要回答：

系统什么时候不应该自动决定，以及人如何发现、解释和纠正错误结果？

五、为什么不能把选中的内容简单相加

三种变更模式和八个可选深化包，并不意味着需要维护二十四套FRD模板。

变更模式是单选，可选深化包通常是多选。

一个系统替换项目可能同时涉及：

• 数据方案。

• 工作流与状态管理。

• 功能与业务规则。

• 集成方案。

• 权限与安全控制。

如果把不同深化包直接拼接，文档会产生大量重复。

1．按照业务决定合并

例如：

• 工作流与状态管理会问某个状态下允许什么操作。

• 权限与安全控制会问什么角色可以执行该操作。

• 数据方案会问什么状态下哪些字段可以修改。

这三个问题不应该分别回答，而可以合并成一张：

角色、状态、操作和字段权限矩阵。

类似的合并还包括：

• 数据方案与集成方案合并为接口字段映射。

• 数据方案与功能规则合并为字段校验和计算规则。

• 工作流状态与异常处理合并为状态恢复矩阵。

• 权限控制与审计要求合并为权限和证据矩阵。

• 报表分析与数据方案合并为指标定义和数据来源。

• 系统迁移与数据方案合并为新旧对象映射和迁移核对。

专业的FRD结构不是模块的简单堆叠，而是把相互关联的设计决定放进同一个可验证的表达中。

2．按照依赖关系补充

某些内容即使没有被主动选择，也可能因为项目特征而成为必要内容。

例如：

• 工作流与状态管理通常需要检查状态权限和审计。

• 集成方案必须检查字段映射、重复控制和失败恢复。

• 自动化与智能化必须检查人工干预和错误纠正。

• 报表与分析必须检查指标口径和数据来源。

• 数据迁移必须检查核对和回退。

• 审批必须检查职责分离和禁止自批。

依赖检查的目的不是扩大范围，而是防止方案只完成一半。

3．按照理解和交付顺序重组

最终FRD不应该按照可选深化包的选择顺序排列。

更合理的阅读顺序通常是：

• 为什么做。

• 做什么和不做什么。

• 当前如何运行。

• 目标如何运行。

• 用户和系统执行什么操作。

• 数据、规则和状态如何变化。

• 权限、集成和控制如何工作。

• 异常和失败以后如何恢复。

• 历史业务如何迁移。

• 系统需要达到什么运行标准。

• 如何测试和验收。

这个顺序更接近业务确认、开发理解和测试验证系统的方式。

六、实际项目中怎样选择FRD结构

不需要在项目开始时把所有深化包都选上。

更实用的做法，是从项目最主要的设计任务和风险开始。

1．先确定变更模式

先回答：

• 这次是在定义一个新系统吗？

• 是在改变一个已有系统吗？

• 还是在用新方案替换旧方案，并处理迁移？

如果三种情况同时存在，选择对FRD结构影响最大的模式作为主模式，其他情况作为附加条件处理。

2．保留固定结构

无论项目时间多紧，至少需要覆盖：

• 背景、目标与范围。

• 用户、角色与场景。

• 端到端业务流程。

• 功能与系统行为。

• 数据、规则、状态和权限影响。

• 异常、纠错与恢复。

• 非功能要求与技术约束。

• 验收标准和未确认问题。

内容可以精简，但关键问题不能在未经判断的情况下被省略。

3．选择主要深化包

根据需求判断复杂度主要来自哪里：

• 功能与业务规则。

• 数据方案。

• 工作流与状态管理。

• 集成方案。

• 权限与安全控制。

• 交互与用户体验。

• 报表与分析。

• 自动化与智能化。

深化包应该由真实风险触发，而不是为了让文档看起来完整。

4．执行依赖检查

检查已经选择的内容是否自然触发其他设计要求。

依赖检查后，可以出现三种结果：

• 必须补充的设计内容。

• 建议进一步考虑的内容。

• 当前明确不适用的内容。

不是每个依赖都需要增加完整章节。有时只需要在现有章节中增加一个必要的控制点。

5．合并重复并删除无关内容

结构形成以后，再反向检查：

• 这个章节是否影响方案决定？

• 开发是否需要它？

• 测试是否需要它？

• 业务是否需要确认它？

• 如果删除，会不会增加误解或风险？

如果答案都是否定的，就不应该为了模板完整而保留。

高质量FRD不是内容最多的文档，而是在当前项目中没有关键遗漏，也没有无效负担的文档。

七、这套方法真正稳定下来的是什么

FRD不应该完全固定，但也不能每次从空白开始。

真正应该稳定下来的，是三个层次。

1．稳定的知识地图

十大领域帮助我们持续扫描：

• 流程。

• 功能和规则。

• 数据。

• 状态。

• 集成。

• 权限。

• 用户体验。

• 报表。

• 自动化。

• 非功能要求。

无论项目怎样变化，这张知识地图都不需要重新发明。

2．稳定的分析路径

PRD／FRD思考框架帮助我们从：

• 为什么做。

• 为谁做。

• 业务怎样运行。

• 系统做什么。

• 数据和状态怎样变化。

• 系统怎样协作和控制。

• 最终怎样验证。

逐步形成完整方案。

3．可以调整的文档结构

固定结构保证基本质量。

变更模式决定FRD是在定义、改变还是转换。

可选深化包决定哪些知识领域需要展开到足够深度。

因此，FRD结构可以变化，但背后的判断逻辑应该稳定。

八、最后的判断

FRD既不是页面说明书，也不是把所有需求材料集中到一份文档中。

它应该建立一套从业务决定到系统行为的可执行关系：

• 为什么需要这个能力。

• 谁在什么场景下使用。

• 系统允许什么、禁止什么。

• 数据和状态怎样变化。

• 出错以后怎样恢复。

• 如何证明结果正确。

在这套知识树中：

• 十大领域帮助我们看见完整的解决方案。

• PRD／FRD思考框架帮助我们按照业务逻辑逐层提出问题。

• 三种变更模式帮助我们判断文档是在定义、改变还是转换。

• 八个可选深化包帮助我们决定哪些领域需要进一步展开。

• 固定结构保证FRD具备最基本的专业质量。

最终，我们不需要为每一种项目建立一份新的模板。

真正需要建立的是一套能够根据项目性质选择内容、发现遗漏、合并重复并形成可交付结构的方法。

FRD的结构不应该由过去的模板决定，而应该由当前项目必须作出的设计决定来决定。