PPI — 需求分析方法论（真正有效的需求分析）¶
概述¶
- 作者: Robert J. Halligan, FIE Aust CPEng IntPE(Aus)，PPI公司董事总经理
- 核心论点: 需求问题是系统与软件项目成本超支、进度延迟和能力损失的最大单一贡献因素——影响范围从10%到80%以上。而改进需求质量的成本仅为总开发成本的0.1-2%。
- 方法论定位: 需求分析（通过对问题域的分析来捕获和验证需求）提供了将不充分需求转化为充分需求的工具。该方法不依赖需求引出（elicitation）本身（既不高效也不有效），而是依赖从利益相关方获取对特定需求问题的回应。
需求充分性标准¶
一组需求的充分性标准: 如果需求集被满足，与未能满足利益相关方需求相关的风险水平很低——通常期望价值损失为2%-3%或更低。需求随时间变化（问题空间真正变化，以及"技术上可能"触发有效新需求），所以需求分析必须是持续活动。
需求缺陷的12种类型¶
| 缺陷类型 | 描述 |
|---|---|
| a. 正确性 | 需求中不存在事实性错误 |
| b. 完整性（单个） | 包含所有必要信息，满足需求即满足需要 |
| b. 完整性（集合） | 包含足够需求，满足集合则因遗漏造成的期望损失很小 |
| c. 一致性 | 需求之间不冲突，内部不自相矛盾 |
| d. 清晰性 | 无需语义分析即可轻松理解 |
| e. 非歧义性 | 仅有一种语义解释 |
| f. 连通性 | 所有术语充分链接到其他需求和定义 |
| g. 单一性 | 不能合理表达为具有不同主体/动作/对象的两个或多个需求 |
| h. 可验证性 | 存在有限、客观的过程以提供需求被满足的充分证据 |
| i. 可修改性 | 必要变更可完整一致地进行；同一需求只规定一次 |
| j. 可行性（单个） | 存在某种满足需求的手段 |
| j. 可行性（集合） | 存在某种将需求作为集合满足的手段 |
| k. 平衡性 | 需求集是最优的——构成上层物理级问题的最优解的一部分 |
| l. 功能导向 | 规定系统要做什么、做得多好、外部接口特性、环境条件、外部资源约束、物理特性等；设计需求仅限于可客观论证的设计指令（仅限获取方比开发者更专业的领域，或标准化的净收益） |
需求分析方法论——13种技术¶
流程概览¶
从初始利益相关方需求出发，经过: 识别利益相关方 → 阅读评估输入 → 规划系统需求分析 → 情境分析 → 功能分析 → 其余场景分析 → 解析分析 → 超出范围分析 → ERA分析 → 清理 → 测量需求质量 → 通过AI征求需求 → 设计需求分析 → 其他约束搜索 → 验证需求开发 → OCD/CONUSE开发 → 利益相关方价值分析。
输出: 精炼的系统需求规格、验证需求规格、操作概念描述、价值模型。
核心分析技术详解¶
a. 利益相关方识别: 识别潜在的需求"所有者"或可促进需求沟通的人——后续鼓励他们输入需求、就需求问题参与咨询、在需求子集上"签署"
b. 文档审查: 检查包含/涉及预期用途、需求和目标的文档，识别需求分析推进前需与利益相关方解决的关键问题
c. 情境流分析: 在全生命周期基础上追踪系统外部世界状态——从系统摇篮到坟墓。所有需求（一类例外）都源于这些情境。利益相关方被映射到情境，通常导致识别出额外利益相关方。工作产品后续用于结构化分析工作、检查和与利益相关方对话。
涵盖9个情境: 被生产 → 被测试 → 被交付 → 被安装 → 被使用 → 被支持 → 被废弃物移除 → 被处置 → 再次被测试
d. 情境分析: 识别/验证主要是外部接口需求。帮助识别额外利益相关方: 互操作系统所有者、将与系统交互的个人、系统将与之接口的组织实体。为后续功能需求的捕获和验证奠定基础。
e. 状态与模式分析: 高ROI分析——建立系统需要的大局动态（状态和模式）。通常识别重大需求问题。为后续在其他分析中捕获的需求提供精确和简洁规定的前提条件。使用状态转换图表达: 必需转换、允许但不必须的转换、禁止的转换。
f. 功能分析: 在建模边界内进行，封装足够的问题（包括作战场景的功能方面），捕获和验证所需的系统功能和性能需求。结果: 足够完整且在恰好正确抽象层级的功能和性能需求集——不过宽也不过深。用例是功能分析的基本形式；更稳健的功能建模技术可用于更要求的应用。使用功能流框图表达。
g. 其余场景分析: 与功能分析迭代进行，识别/验证环境需求、物理需求、资源需求，并贡献额外内容到外部接口需求。
h. 实体关系属性(ERA)分析: 为外部接口需求的额外信息内容捕获/验证提供输入。最适用于面向数据的系统。
i. 解析分析: 文本分析技术，识别文本化需求中的错误、不完整性、不一致性、不清晰性、歧义、不可验证性和不可行性。解析模板元素:
| 元素 | 内容 |
|---|---|
| 1. 主体 | 执行动作的系统/组件 |
| 2. 动作条件 | 动作发生的前提状态 |
| 3. 动作 | 应执行的操作 (shall) |
| 4. 动作约束1 | 对动作的约束 |
| 5. 动作对象 | 动作施加的对象 |
| 6. 动作约束2 | 更多约束（时间/标准/精度） |
| 7. 对象细化 | 对对象的进一步限定 |
| 8. 动作约束3 | 源/目标/路由约束 |
| 9. 动作例外 | 不适用的情况 |
| 10. 其他 | — |
该模板也是首次写好需求和重写有缺陷需求的极佳辅助工具。
j. 超出范围分析: 捕获和验证与缺陷输入/输出或异常使用/保障/处置条件相关的需求。这些需求决定系统在现实世界有效还是仅在理想世界有效。
k. 其他约束搜索: 寻找"自上而下"规定的需求——来自成文法、适用法规、政策、治理标准、指令等。
l. 清理: 验证精炼后的需求集，寻找分析工作产品中的残留缺陷。使用关键词搜索结合具体验证标准。
AI集成¶
方法论明确纳入了AI辅助: - 通过AI征求需求 - 用AI支持编写需求
与MOSA的关系¶
- 情境流分析天然识别系统的模块化边界——在全生命周期情境中，哪些功能隔离、哪些功能需要跨模块交互
- 功能分析在"恰好正确抽象层级"捕获需求的原则，直接对应MOSA的分解深度——不过宽（不缺失接口需求）也不过深（不预设实现方案）
- 解析模板的"可验证性"元素，直接对应MOSA的一致性认证要求
- 功能导向原则对设计需求的限制，与MOSA不规定模块内部实现的"灰盒概念"一致
- ERA分析对外部接口信息内容的关注，直接支撑ICD的制定
笔记¶
- Halligan的核心洞察: "需求引出"本身既不高效也不有效——正确的方法是分析问题域，识别具体需求问题，再向利益相关方征求回应。这在MOSA语境中意味着: 不要问"你想要什么模块"，而是分析作战情境、识别功能边界，再验证。
- 12种缺陷类型可映射到MOSA标准合规检查——特别是连通性（术语一致→接口语义一致）、可验证性（接口可测试）、功能导向（设计需求限制→实现无关）。
- 状态与模式分析（高ROI）在MOSA中对应模块在不同作战模式下的行为差异，是识别接口需求触发条件的关键技术。
- "超出范围分析"对军事系统尤其重要——模块在降级、干扰、损伤条件下的行为需求往往被忽略，但这是模块化系统韧性的关键。