知识卡片
场景通过具体化暴露需求的真实模糊性
内容
需求文档里”系统必须能处理故障”这类句子看起来清晰，其实什么都没约束——直到写成具体场景：”汇总数据库写入失败时，系统应停止处理、保留旧数据、记录诊断日志”，才会发现需求根本没说清失败时该怎么办，甚至设计出的行为不够健壮。发散：场景的价值不在于自我证明写得好，而在于用具体情境倒逼抽象需求现出原形，尽早在便宜阶段暴露遗漏，而非留到上线后才发现。
参考来源
- 位置：第10章《识别并使用场景》10.4节「捕获场景」汇总数据库实例故障示例（源文件：_epub-src/OEBPS/text00107.html附近）
- 结论依据：原文用"汇总数据库实例故障"场景把模糊需求具体化为系统状态/环境变化/所需行为三要素，并明确指出通过编写场景才能让"必须处理故障条件"这类空泛需求现出原形，直接支持卡片结论。
- 原始内容："汇总数据库实例故障……环境变化：在把汇总统计数据写入数据库的时候，系统收到异常，显示写入失败（例如，数据库已满）。所需系统行为：系统应该可以停止处理进行中的统计数据集，并把进程中的所有工作延后……通过编写这个场景，你现在就有了具体的案例来和利益相关者讨论，从而帮助你知道需求文档中'必须处理故障条件'这句话的真实意义所在。"