软件需求
§1摘要与结论
软件需求是「须被某物展现、以解决现实世界问题的属性」；它描述系统应满足的「什么（what）」而非「如何做（how）」，属于对解决方案的约束与对问题空间的陈述，而非设计决定。
别名：software requirement、requirement、需求、软件需求、需求即约束 | 英文：Software Requirement | 类型：方法原则 / concept
§2局部关系图
§3原理 · 为什么
软件之所以需要一个独立的需求概念，是因为问题空间与解决方案空间必须分开对待。需求刻画现实世界的问题及其解决判据，设计则在约束下选择实现手段；若二者混同，需求会把尚未论证的技术方案固化为前提，压缩后续设计的自由度，使错误选择难以纠正。需求被表述为「须被展现的属性」，是因为它必须能被客观判定是否达成，而判定只能针对系统可观察的行为或性质，无法针对实现内部。这一界定使需求天然带有约束属性：它限定可接受解的范围，却不指定具体实现。需求还是变化的载体，它连接业务目标与系统行为，任一端的改变都会传导为需求的改变。更深一层，把注意力放在属性而非功能上，可以避免把某一种惯用实现误当作需求本身，因为功能只是达成属性的手段之一。需求与业务目标之间还应保持方向一致，否则即使全部需求被满足，系统仍可能没有解决原本的问题。由此可见，需求概念的价值不在于形式上把 what 与 how 分开，而在于迫使团队在投入实现之前先对问题达成一致，从而把最昂贵的一类错误——解决了错误的问题——挡在早期，避免大量实现工作建立在对需求的误读之上。
§4机制 · 如何运作
需求通过把问题空间显式化来运作：先识别待解决的真实问题与判定成功的标准，再把这些标准转化为可被单独确认的陈述，逐条与业务目标对照。其内在结构包含稳定与易变两类信息——稳定的部分表达系统必须长期满足的属性，易变的部分随环境、认知与业务策略变化。区分「what 与 how」是贯穿始终的检验：陈述中若出现数据结构、算法、接口技术或部署方式，通常意味着设计决策混入，应被剥离到设计阶段。评价一条需求的过程本身也是澄清问题的过程：当一条需求难以被判定是否达成时，往往暴露的是问题尚未想清，而非措辞不当。需求的粒度同样影响可管理性：过大的需求难以验证与变更，过小的需求则会产生大量碎片与维护负担，因此需要在单一主张与可管理规模之间取得平衡。需求之间还存在依赖与派生关系，理清这些关系有助于判断变更的传播路径，而不是孤立地看待每一条陈述。需求陈述一旦能够被独立判定，就可以在后续的设计、实现与测试之间被反复引用而含义不漂移，这正是它作为共同对象能够贯穿全程的原因；反过来，含义游移的需求会让每个环节各自解释，最终拼出一个无人真正想要、也难以归责的系统。
§5工程 · 怎么落地
工程实践上，把每条需求写成单一主张，使用主动语态并明确行为主体与判定条件；坚持陈述需要什么而非如何实现，把实现选择留给设计。评审时逐条追问：它要解决什么现实问题、由谁判定成功、判据是什么、能否被独立验证。对含混的形容词与笼统措辞保持警惕，代之以可测量的阈值与条件。为每条需求保留来源与依据，使后续的取舍与变更可追溯。对相互矛盾的需求不急于合并，而应先回到业务目标判断优先级。把需求与设计分层管理，避免在同一层级混入不同抽象程度的信息，并为新出现的需求建立准入准则，防止范围无声扩张。对需求的措辞，团队应形成共同约定并写入检查清单，使评审有统一尺度；对反复出现的歧义模式，应沉淀为术语表与反例，降低后续同类问题的发生概率，使需求质量不依赖个人经验。把需求写入受控的单一位置并允许全员查阅，可以避免同一诉求在不同文档中各有说法，从源头上减少口头承诺与书面规格之间的落差，并使变更只需在一处发生即可传导到所有相关方。
§6权衡卡
需求定义的边界在学界仍有争议，有学者批评其过于宽泛而接近同义反复；实践中应认识到，需求文本的价值取决于它是否促成对问题的共同理解，而非篇幅或形式完整。
此外，需求工作的收益并不总能被立即度量，容易在交付压力下被压缩，但压缩需求澄清所节省的时间，往往在后期以更高的返工成本偿还，因此需要在项目节奏中为其保留稳定投入。
最终，需求工作的尺度应由返工风险决定：越难更改、代价越高的决策，越值得在需求阶段投入澄清；反之在易变且低廉的部分过度澄清，只会消耗本可用于交付的时间。
- 需求界定的严格程度存在张力。
- 规定得过细、混入实现选择，会限制设计并把尚可优化的方案提前锁死；规定得过粗、缺少判定条件，则无法验证也无法据以设计，最终所有分歧都被推迟到实现阶段并以返工收场。
- 把「what 与 how 分离」当作绝对教条同样危险：某些质量诉求只有在具体技术语境中才能被有效表达，强行抽象会丢失关键约束。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
OpenSpec 规约驱动解析
对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。
技术知识中枢交付法
从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。
§9信源与核验
核验结论：需求是须被某物展现、以解决现实世界问题的属性；功能只是其中一类，需求还包含质量属性与约束，并须可判定是否达成 [OFF-014]
核验结论：需求应陈述需要什么（what）而非如何做（how），不含设计决策；实现选择属于设计阶段 [PAP-019]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依据推导 | ← MTH-F-01 | 需求工程过程 E-306 | 需求工程过程以软件需求为工程对象 |
| 前置依赖 | → ESS-F-03 | 需求可追溯性与可验证性 E-303 | 明确需求对象是建立追溯与验证的前提 |
| 前置依赖 | → ESS-F-04 | 需求的不确定性与变更 E-304 | 需求概念是理解其不确定性与变更的基础 |
| 前置依赖 | ← ESS-F-02 | 干系人与需要 E-302 | 干系人需要是界定软件需求的来源 |