一页完整需求分析文档结构检查清单

前面我们把需求分析的关键环节逐一拆解：目标与场景、模块拆分、范围界定（必须做 / 后做 / 不做）、用户故事、功能清单、验收标准。整个需求分析文档的各个环节都已经分享了，每次都从头回忆，容易遗漏或顺序混乱。现在总结为一份检查清单。写 需求分析文档时可以对照着搭结构，写完后可以快速自检，评审时也可以直接当作对照表使用。

一、背景与目标（必须有）

• 一句话说明本次要解决的核心问题或目标
• 完成后希望看到的功能（1～3条成功标准）
• 目标是否足够清晰，能作为后续取舍的依据

二、用户与关键场景（必须有）

• 主要用户角色已明确（避免只写“用户”）
• 2～4个最核心的使用场景已描述（谁、什么时候、什么情况下、想完成什么）
• 场景能支撑后续模块与故事拆分

三、范围界定（必须有）

• 本期必须做：已列出，且数量受控
• 本期可后做：已列出（有余力才考虑，不承诺）
• 本期明确不做：已具体写出（避免“我以为会做”）
• 范围已与业务、开发确认，形成基线

四、功能模块与用户故事（必须有）

• 功能模块已按场景归类，每个模块有一句话说明
• 用户故事采用标准句式：作为【角色】，我想要【行动】，以便【价值】
• 故事粒度合适，能相对独立交付与验收
• 关键业务规则与主要异常已点明（不堆砌实现细节）
• 故事严格对应“本期必须做”，未夹带后做/不做内容

五、功能清单（必须有）

• 已整理成结构化清单（建议表格）
• 必要字段齐全：编号、功能名称、对应故事/模块、关键规则摘要、依赖、范围、验收要点
• 依赖关系已写清
• 粒度统一，可直接用于排期与跟踪

六、验收标准（必须有）

• 采用“在【前提】下，当【操作】时，系统应【可观察结果】”句式
• 覆盖正常路径 + 主要异常
• 结果可客观检查，无“流畅”“良好”等主观词
• 与对应的用户故事、功能清单保持一致

七、非功能与约束（建议有）

• 关键性能、安全、兼容性等约束已点明（如有）
• 数据量、响应时间、权限等影响实现的约束已说明

八、优先级与排期相关（建议有）

• 在“必须做”内部，已标出优先顺序或依赖顺序
• 有助于排期的信息已体现在功能清单中

九、基线与变更（必须有）

• 文档已与关键方确认，作为当前基线
• 变更规则已明确：新需求先判断属于必须做/后做/不做，再决定是否纳入使用时的几点提醒

1. 先保证“必须有”项完整，再考虑补充建议项。中小项目不必追求面面俱到。
2. 清单是检查工具，不是写作模板的全部。实际文档可以用自己的标题和详略，但内容应能覆盖清单上的关键点。
3. 范围、故事、清单、验收标准四处信息必须一致，避免出现多套说法。
4. 一页纸的价值在于可执行：打印或放在文档开头，写的时候和评的时候都能快速对照。

到这里，从认知到方法的核心链路已经收束成可直接使用的检查工具。实际写文档时，不必每次都长篇大论，但对照这份清单，能有效减少遗漏和返工。

下一篇，我们聊一个当前使用AI的普遍话题，如果你更关注 AI 辅助写作，也可以直接看“AI生成需求分析初稿后，分析师重点关注改什么”。