SBE (Specification by Example) 工作规范与完整性校验标准

核心宗旨： 本规范旨在建立单一事实来源（Single Source of Truth）。规范（Specification）、验收测试（Test）与文档（Documentation）必须三位一体。通过实例协作，确保构建正确的产品。

1. 全生命周期处理流程 (Process Patterns)

所有需求必须严格遵循以下七个步骤进行流转，严禁跳过。

阶段	责任人	核心动作与产出
1. 目标衍生范围 Deriving Scope	PO/BA	动作：拒绝直接接受“功能列表”。询问“为什么？”和“谁受益？”。产出：明确了业务价值的用户故事（User Story）。
2. 协作制定 Collaborating	三剑客	动作：开发、测试、业务人员共同讨论（Three Amigos Meeting）。禁令：严禁开发或测试独自闭门造车编写规范。
3. 举例说明 Illustrating	三剑客	动作：使用具体例子而非抽象描述。要求：覆盖Happy Path及关键Edge Cases。
4. 提炼规范 Refining	QA Dev	动作：将草图转化为结构化文档（Gherkin/Markdown）。原则：规范描述“做什么”，不是脚本描述“怎么做”。
5. 自动化验证 Automating	Dev	动作：编写Fixture代码连接规范与系统。原则：不改变规范内容，在代码层处理复杂性。
6. 频繁验证 Validating	CI系统	动作：纳入持续集成流水线，确保100%通过率。处理：失败测试必须立即修复或移入“已知回归”队列，严禁直接禁用。
7. 演进活文档 Living Doc	全员	动作：功能上线后，将规范按功能区域归档，而非按迭代归档。

2. 规范编写格式要求 (Specification Standards)

使用统一语言 (Ubiquitous Language)：严禁出现技术术语（如JSON, Database ID, Click Button）。必须使用业务术语（如“提交订单”、“注册用户”）。
数据真实性 (Realistic Data)：使用具体的数值（如 5 books），严禁使用抽象描述（如 count > min）或无意义字符（如 foo/bar）。
自解释性 (Self-explanatory)：业务人员必须能在不需解释的情况下读懂文档。

3. 自动化实施与数据规范

4. 完整性严格校验清单 (Integrity Checklist)

在代码评审（Code Review）或合并请求（Merge Request）阶段，必须逐项核对以下指标。任何一项不合格，严禁合并。

版本控制：规范文件是否已提交至与代码相同的Git仓库？（严禁存于Wiki/Word）

可执行性：规范是否已连接自动化层并在CI中运行通过？

"Show and Keep Quiet"测试：在不口头解释的情况下，业务人员能否完全看懂？

去脚本化：是否已剔除所有UI操作词汇（点击、输入、打开）？

数据具体化：是否使用了具体的业务场景数据，而非抽象类或变量名？

语言一致性：文档中的术语是否与代码中的领域模型（Domain Model）完全一致？

霰弹枪手术检查：业务规则的微小变更，是否只需修改当前这一个文件？

组织结构：文件是否已按“功能模块”归档，而不是按“Sprint/Story”归档？

Specification by Example (SBE) 标准化工作手册