mbx/mb-ms-doc.git

			@@ -1,10 +1,12 @@
			# 需求规范
			# 需求规范

			创建人员：Codex
			文件职责：定义通用需求文档写法、需求审核流程、需求进入编码阶段的条件。
			管理规范/模板：../../全局规范.md；产品规范.md；产品审核规范.md；需求文档范本.md。
			引用文件：产品规范.md；产品审核规范.md；需求文档范本.md；../dev-doc/编码规范.md。
			管理规范/模板：../../全局规范.md；需求规范.md；需求审核规范.md；需求文档范本.md。
			引用文件：需求规范.md；需求审核规范.md；需求文档范本.md；../dev-doc/编码规范.md。
			记录方式：全局需求写作规范；需求写法、需求审核流程或进入编码阶段的条件变化时更新。

			统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地需求规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。

			## 1. 目标

			@@ -89,12 +91,12 @@

			需求按规模分两类处理，不要把所有需求都套进重流程。

			需求文档进入审核前，必须先判断上游产品流程：
			需求文档进入审核前，必须先判断上游需求流程：

			1. 大量产品修改：必须先有产品方案文档，且产品审核通过。
			2. 少量产品修改：可以直接改需求文档，但必须记录修改背景和一致性检查结论。
			3. 第一版复杂产品交付：必须先有架构文档、模块说明文档、核心流程文档，且产品审核通过。
			4. 第一版轻量产品交付：可以直接进入需求文档书写流程。
			1. 大量需求修改：必须先有需求方案文档，且需求审核通过。
			2. 少量需求修改：可以直接改需求文档，但必须记录修改背景和一致性检查结论。
			3. 第一版复杂需求交付：必须先有架构文档、模块说明文档、核心流程文档，且需求审核通过。
			4. 第一版轻量需求交付：可以直接进入需求文档书写流程。

			如果对应上游文档不存在，需求文档必须说明“不适用”和原因，不能假装已经参考。

			@@ -163,7 +165,7 @@
			3. 写清输入、输出、字段、状态、错误处理。
			4. 写清核心处理流程和不做事项。
			5. 写清验收标准，区分主流程必过项和外部诊断项。
			6. 对照产品方案或三大文档做一致性检查。
			6. 对照需求方案或三大文档做一致性检查。
			7. 检查需求之间是否存在冲突或重复定义。
			8. 交审核员审核。
			9. 审核员通过后，需求完成。
			@@ -379,29 +381,29 @@

			如果实现者可能按两种方式理解，就还不是合格需求。

			## 13A. 产品上游一致性检查
			## 13A. 需求上游一致性检查

			无论新写需求还是修改需求，都必须做产品上游一致性检查。
			无论新写需求还是修改需求，都必须做需求上游一致性检查。

			检查对象：

			1. 产品方案文档：有就参考，没有就说明不适用。
			1. 需求方案文档：有就参考，没有就说明不适用。
			2. 架构文档：有就参考，没有就说明不适用。
			3. 模块说明文档：有就参考，没有就说明不适用。
			4. 核心流程文档：有就参考，没有就说明不适用。
			5. 产品总纲里的目标、背景、边界和关键聊天要求。
			5. 需求总纲里的目标、背景、边界和关键聊天要求。
			6. 相关旧需求文档。

			检查结论必须能回答：

			1. 需求是否和产品方案一致。
			1. 需求是否和需求方案一致。
			2. 需求是否和架构、模块说明、核心流程一致。
			3. 是否有冲突。
			4. 是否漏写必须实现的需求。
			5. 是否引入产品文档没有授权的新口径。
			5. 是否引入需求文档没有授权的新口径。
			6. 是否把小需求写成重型系统。

			推荐在需求文档中增加“产品上游一致性检查”小节。轻量需求也要写，但可以很短。
			推荐在需求文档中增加“需求上游一致性检查”小节。轻量需求也要写，但可以很短。

			## 14. 公式、规则和阈值