干系人与需要
§1摘要与结论
干系人是对系统或其具备满足其需要与期望的特性拥有权利、份额、主张或利益的个人或组织；需要是对其 needs、wants、desires、expectations 与感知约束的引出，需求则由需要转化而来。
别名：stakeholder、stakeholder needs、干系人、干系人需要、利益相关者 | 英文：Stakeholder and Needs | 类型：方法原则 / concept
§2局部关系图
§3原理 · 为什么
需求的最终来源不是系统自身，而是受系统影响或能影响系统的人与组织。干系人概念把这一来源显式化：任何对系统拥有权利、份额、主张或利益者，都可能带来必须被考虑的期望与约束。关键在于区分「需要」与「需求」两个层级：需要是主观、宽泛、面向目的与行为的期望集合，需求则是对需要的客观、充分、结构化的转化结果。二者混同会导致两种失败——把早期模糊愿望直接当作可实现的规格，或把技术上已规格化的陈述误认为已捕获真实诉求。识别干系人还意味着承认视角的多样性：不同角色对同一系统的期望可能相互冲突，冲突本身是需要被显式记录与权衡的信息，而非应被掩盖的噪音。由于各方对系统的影响方式不同，干系人分析还必须区分「表达诉求」与「承担后果」两类关系，避免只听见前者而忽略后者。由此，干系人视角把需求从「系统应该做什么」扩展为「谁在其中受益、承担与受阻」，使需求工作从一开始就带有利益与责任的维度，而不再被视为纯粹的技术翻译工作。
§4机制 · 如何运作
其运作遵循「来源—引出—转化—确认」的链条：先识别受影响的个人与组织，覆盖用户、运维、开发、采购、监管等多类角色，再引出其需要、期望与感知到的约束，随后把需要转化为结构化、可验证的需求陈述，并回到干系人处确认转化未失真。需要聚焦系统目的与行为，并须在具体运行环境与条件下描述，脱离语境的愿望无法转化为设计依据。复杂度来自覆盖度与代表性：遗漏关键干系人会带来后期返工，而过度收集会让需求失去焦点。因此识别是持续活动，随系统边界与组织变化而更新，而非项目初期的一次名单。需要之间可以彼此冲突，其一致性通常在更高层的系统需求上建立，而不是在来源层强行统一；转化过程也必须保留来源的可追溯性，否则一旦需求被质疑，团队将无从判断其原始意图。当需要被转化为需求时，应保留「谁的什么需要在何种语境下被表达」的元信息，否则后续在优先级与冲突裁决中会失去判断依据，也无法追溯某条需求究竟代表哪一方的诉求。
§5工程 · 怎么落地
实践中先在项目启动阶段建立干系人清单并分析其关注点、影响力与受系统影响的方式，为每类干系人选择适当的引出方式与参与深度。让真实使用者与运维人员尽早参与，而不是仅由委托方转述诉求。对每个需要记录其来源、背景与依据，以便在冲突出现时追溯。把需要与由其导出的需求建立双向链接，避免转化过程中含义漂移。对监管、法律、安全等约束型干系人，应单独列出其强制要求。定期复核干系人名单，尤其当系统边界、组织或业务模式变化时。将冲突显式登记并交由其共同的上层目标裁决，避免由单一角色垄断解释权。对无法直接参与的间接干系人，应通过代理角色或调研方式补足其视角。对远程或间接干系人，可借助代理代表、调研或公开征求意见的方式补充视角，避免其诉求因无法直接到场而被遗漏，并在决策记录中说明其参与方式与采纳情况。
§6权衡卡
扩大干系人参与有助于减少遗漏，但会抬高协调成本、拖慢决策，甚至因各方诉求彼此牵制而陷入僵局；参与不足则关键诉求在晚期才浮现，造成大范围返工。
转化过程同样两难：过于忠实原话会保留模糊与矛盾，过度提炼又可能篡改真实意图。
因此干系人工作应以「是否降低了因诉求遗漏或误读造成的重大风险」为判据，而非以名单长度衡量；名单本身不是成果，被正确理解并纳入决策的诉求才是。
- 识别活动还应防止形式化——把名单列全却不让关键角色真正参与，只会制造已覆盖的假象。
- 由于干系人的权力与受影响程度并不对称，一味追求全员一致既不现实也未必公正；需要依据影响程度与责任边界确定参与优先级，并对被排除者说明理由。
- 归根结底，干系人工作的质量不取决于采集了多少意见，而在于关键诉求是否被正确理解并进入决策；这需要判断力而非流程本身，也需要对「谁的声音被放大了、谁的被忽略了」保持警觉。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
OpenSpec 规约驱动解析
对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。
技术知识中枢交付法
从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。
§9信源与核验
核验结论：干系人还包括开发、生产、维护、处置、采购、操作、供应方与监管机构等；凡对系统拥有权利、份额、主张或利益者均属之 [OFF-012]
核验结论：需要是对 needs/wants/desires/expectations 的引出；需求由需要转化而来，是客观充分、结构化且更正式的陈述 [OFF-011]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依据推导 | ← MTH-F-02 | 需求获取 E-307 | 需求获取以干系人需要为源头 |
| 依据推导 | ← MTH-F-03 | 干系人识别与分析 E-308 | 干系人识别与分析以干系人概念为依据 |
| 前置依赖 | → ESS-F-01 | 软件需求 E-302 | 干系人需要是界定软件需求的来源 |
| 前置依赖 | ← ESS-F-05 | 业务与任务价值 E-301 | 业务与任务价值是引出干系人需要的上游依据 |