一、目前前沿软件工程更看重哪些“前置文档”
当前比较前沿的软件工程趋势，普遍会把这些能力前置到立项和设计阶段：
- 需求对齐前置：先明确业务目标、用户问题、成功指标，再谈功能。PRD/SRS 仍然核心。(atlassian.com)
- 架构与质量属性前置：不只写功能，还要在设计阶段写清可扩展性、可靠性、性能、成本、运维方式。Azure 和 Google Cloud 都强调功能与非功能需求要一起进入架构设计。(Microsoft Learn)
- 安全前置（Shift Left Security）：威胁建模在设计阶段开展，而不是上线前临时补安全。Microsoft SDL 明确把 threat modeling 放在前期设计流程里。(Microsoft)
- 决策可追溯：越来越多团队用 RFC + ADR 组合，先讨论方案，再沉淀最终决策，避免“为什么这么做”日后说不清。(Spotify Engineering)
- 轻文档、持续维护：现代工程不鼓励一次写完就废弃的大文档，而强调文档要清晰、可维护、跟随系统变化更新。(atlassian.com)
- AI 协作背景下更重“边界与标准”：GitHub 对 Copilot 的公开建议也强调，团队需要明确规范、审查和验证，说明前置文档对 AI 辅助开发反而更重要。(GitHub Docs)
二、项目开发前建议准备的核心文档，以及各自职责
1. 立项说明 / 项目章程（Project Charter）
职责：回答“为什么要做这个项目”
通常包括：
- 项目背景
- 业务目标
- 范围边界
- 关键干系人
- 预算/周期/资源约束
- 里程碑
它的主要作用不是写技术，而是确定项目是否值得做，以及谁拍板、谁负责、做到什么程度算成功。 这类文档能防止项目一开始就目标模糊、职责不清，后续 PRD 和设计文档都应以它为上位依据。关于文档需要支持跨团队沟通和共同语言，Google Cloud 的文档与架构指导有明确强调。(Google Cloud Documentation)
一句话职责： 立项说明管“立不立、谁负责、做到哪一步”。
2. 需求文档（PRD / BRD / SRS）
职责：回答“要做什么”
这是开发前最核心的一份文档，但不同组织名称不同：
- BRD：偏业务需求，讲商业目标和业务流程
- PRD：偏产品需求，讲用户、功能、行为、验收目标
- SRS：偏系统/软件需求，强调清晰、完整、可验证
Atlassian 把 PRD 定义为用于说明产品目的、功能、行为和成功标准，帮助跨职能团队对齐；IBM 和 Perforce 都强调“好需求”应当清晰、可验证，并能作为后续设计、计划、测试的依据。(atlassian.com)
通常应包含：
- 背景与目标
- 目标用户与场景
- 核心功能需求
- 非功能需求概要
- 不做什么
- 验收标准
- 成功指标（如 DAU、转化率、响应时间）
一句话职责： 需求文档管“做什么、不做什么、做到什么算达标”。
3. 范围说明 / 版本范围文档（Scope / Release Scope）
职责：回答“这次到底做哪一部分”
很多项目失败不是因为没需求，而是需求太多、边界不清。 所以在 PRD 之外，现代团队常单独维护一份范围文档，明确：
- MVP（最小可用版本）范围
- 本期版本范围
- 延后项 / Backlog
- 依赖项
- 风险项
- 上线前必须完成 vs 可后补
Atlassian 的 PRD 模板也强调 assumptions、scoping、user stories 等内容需要显式化。(atlassian.com)
一句话职责： 范围文档管“这次上线到底交付哪些内容”。
4. 方案讨论文档（RFC）
职责：回答“几个可选方案里，应该优先讨论哪一个”
RFC（Request for Comments）在现代工程团队里很常见，尤其是平台、中后台、架构调整、基础设施升级、跨团队技术变更。Spotify 的公开实践就提到，团队通常通过 RFC 先展开讨论，再把最终决定沉淀为 ADR。(Spotify Engineering)
RFC 一般包括：
- 问题定义
- 目标与非目标
- 候选方案
- 方案对比
- 风险与取舍
- 征求意见对象
- 最终建议
RFC 的重点不是“定案”，而是让意见在决策前暴露出来。
一句话职责： RFC 管“把重要技术问题拿出来讨论透”。
5. 技术设计文档 / 详细设计文档（Technical Design Doc）
职责：回答“系统具体怎么设计和实现”
这是开发前技术团队最关键的落地文档之一。Google 的工程实践和 Azure Well-Architected 都非常强调设计文档的作用：用它收集反馈、对齐实现方案，并说明设计选择及其依据。(google.github.io)
通常包含：
- 系统目标
- 架构图、模块划分
- 数据流 / 调用链
- 数据模型
- 接口设计
- 异常处理
- 可观测性设计
- 容灾、扩容、回滚
- 与现有系统的集成方式
Azure 还特别强调，设计规格不仅要覆盖功能选择，也要覆盖非功能设计以及日常、临时、应急运维场景。(Microsoft Learn)
一句话职责： 技术设计文档管“工程上怎么搭、模块怎么分、接口怎么连”。
6. 架构设计说明 / 非功能需求文档（Architecture Spec / NFR）
职责：回答“系统要达到怎样的质量水平”
这是很多团队最容易漏掉、但最影响后期质量的一份。 前沿工程实践里，非功能需求不会再被当作附录，而是要在架构设计里明确写出来。Google Cloud、Azure、AWS 都强调，要在设计阶段考虑可靠性、性能、成本、运维效率、安全等质量属性及其权衡。(Google Cloud Documentation)
典型内容：
- 性能目标：响应时间、吞吐量、并发
- 可靠性目标：SLA/SLO、RTO/RPO
- 扩展性：水平扩展策略
- 安全：权限、加密、审计
- 成本约束
- 运维要求：告警、日志、监控、值班
一句话职责： NFR/架构规格管“系统不仅要能用，还要好用、稳、快、安全、可运维”。
7. 安全文档 / 威胁建模（Threat Model / Security & Compliance）
职责：回答“系统会被怎样攻击，我们怎么提前防”
这是现代软件工程里最明显的“前置化”文档之一。 Microsoft SDL 指出，威胁建模是核心环节，要尽早识别威胁、漏洞和对策，从而降低后期修复成本。(Microsoft Learn)
通常包含：
- 资产识别
- 攻击面
- 信任边界
- 数据流图
- 潜在威胁（如伪造、篡改、越权、泄露）
- 风险等级
- 缓解措施
- 合规要求
这类文档尤其适用于：
- 涉及用户数据
- 涉及支付、身份认证
- 面向公网
- 有第三方接入
- AI/数据平台项目
一句话职责： 安全文档管“提前发现风险，别把漏洞带进开发和上线”。
8. 架构决策记录（ADR）
职责：回答“为什么最终选了这个方案”
ADR 不是用来讨论，而是用来记录已经做出的关键决策。Google Cloud 和 AWS 都明确指出，ADR 用于记录关键选项、决策背景和后果，帮助团队追踪架构演进。(Google Cloud Documentation)
典型内容：
- 决策标题
- 背景
- 可选方案
- 决策结果
- 原因
- 影响与后果
- 状态（提议/接受/废弃）
例如：
- 为什么选 PostgreSQL 而不是 MongoDB
- 为什么采用事件驱动而不是同步调用
- 为什么先单体后拆微服务
一句话职责： ADR 管“把重要决定和理由留下来，防止团队遗忘”。
9. 测试策略 / 验收方案（Test Strategy / UAT Plan）
职责：回答“怎么证明它真的满足要求”
虽然测试通常在开发后期执行，但测试策略最好在开发前就定。 因为需求是否可验证，会直接影响设计质量。IBM 和 Perforce 都强调需求应当可验证；AWS 也强调非功能测试应评估性能、可靠性、可用性等质量属性。(IBM)
可包含：
- 测试范围
- 测试层次（单元、集成、端到端）
- 验收标准
- 性能/安全/可靠性测试要求
- 测试环境
- 发布门禁
一句话职责： 测试策略管“以后怎么验收、怎么证明设计没问题”。
10. 交付计划 / 实施计划（Delivery Plan）
职责：回答“按什么节奏落地”
它一般包括：
- 里程碑
- 人员分工
- 风险与依赖
- 发布计划
- 回滚计划
- 沟通机制
这份文档偏项目管理，但对工程落地很重要。 否则即使需求、设计都完整，也容易因为依赖、资源、节奏问题失控。
一句话职责： 交付计划管“谁在什么时候交付什么”。
三、这些文档之间的关系
可以把它们理解成一条链：
项目章程 → 说明为什么做、谁负责
需求文档（PRD/SRS） → 说明做什么、目标是什么
范围文档 → 说明这次版本做多少
RFC → 讨论可选技术/方案
技术设计文档 / 架构规格 → 说明怎么实现、质量要求是什么
安全文档 / 威胁建模 → 说明主要风险与安全控制
ADR → 记录最终关键决策
测试策略 / 交付计划 → 说明怎么验证、怎么落地
四、不同规模项目，文档要求也不一样
小型项目 / 教学项目 / 原型
可以最小化为 4 份：
- 项目说明
- 需求清单
- 技术设计简稿
- 测试与上线清单
中型业务系统
建议至少 6 份：
- 项目章程
- PRD/SRS
- 范围文档
- 技术设计文档
- 安全文档/威胁建模
- 测试策略
大型平台 / 金融 / 医疗 / 政务 / AI 系统
建议完整配置：
- 项目章程
- BRD/PRD/SRS
- RFC
- 架构规格
- NFR
- 安全文档
- ADR
- 测试策略
- 发布/回滚方案
- 合规与审计材料
五、一个很实用的职责划分办法
你可以用下面这个标准区分文档，不容易写重：
- PRD/SRS：定义问题与需求
- 设计文档：定义实现方案
- NFR/架构规格：定义质量目标
- 安全文档：定义风险与控制
- ADR：定义“为什么这么选”
- 测试策略：定义“怎么验证”
- 交付计划：定义“怎么推进”
这样就不会出现一份文档又写需求、又写架构、又写计划，最后谁都看不懂。
六、给你的最终建议
如果你想按照目前较前沿的软件工程实践来组织项目启动前文档，我建议采用这套“最实用组合”：
- 项目章程：统一目标、范围、角色
- PRD/SRS：统一需求与验收标准
- 技术设计文档：统一实现方式
- NFR + 安全文档：统一质量底线
- ADR：沉淀关键技术决策
- 测试策略 + 发布计划：保证能验证、能交付
这套组合的优点是： 既不臃肿，又覆盖现代工程最重视的需求、架构、安全、决策追踪和交付控制。
如果你愿意，我可以下一步直接帮你整理成一张**“项目开发前文档清单表（文档名 / 核心内容 / 负责人 / 输出时机）”**，适合你拿去教学或团队内部使用。