---
name: requirement-and-invariants
description: 定义期第 1 步，需求与不变式：把需求说成用户得到的能力与系统前后的差别，再和人一起列出系统永远要守住的不变式。人提出新需求、新能力，说「先把需求定清楚」「不变式是什么」，或流走到第 1 步时加载。已有不变式清单、进入领域分析后不加载。
---

# 需求与不变式

定义期的第一步，由人主导，代理协助把话说准。产出两样：用户可见差异的描述，不变式清单。两样都是后面每一步的输入，不变式还是后面每个设计和实现决定的试金石。

这两样就是一程的应然，思维模型 `think-ought-vs-is` 的第一问在这里答：从要回答的问题推出，不从打算用的实现手段推出。

## 先复述，再问值不值得做，再追问

1. 代理先用自己的话复述用户的目标和要解决的问题，让用户纠正。加载技能 `pstack:in-your-own-words`。
2. 复述对齐后，先问这个需求值不值得做：有没有人真要，今天怎么应付，最小做到哪。先查再问，一轮问齐，给一个结论，人定了就照做。看到人这一侧的风险就说一次：提醒、依据、建议、选择。做法加载技能 `candid-friend`。结果写进需求单的「值不值得做」一节；修复类的需求不问，写「不问：修复」。
3. 人定了要做之后，围绕三问追问到答案具体为止。加载技能 `mattpocock-skills:grilling`，一次一问。

次序不能反：先问清楚怎么做，等于默认了它值得做。

## 需求的三问

| 问 | 要得到的 | 不算答案的 |
| --- | --- | --- |
| 给用户什么能力 | 用户能做一件以前做不了或做不好的事，用用户的话写 | 技术特性、模块名 |
| 系统实现前后有什么区别 | 一组可观察的差异：以前怎样，以后怎样，谁看得见 | 「更好」「更快」这类没有对照的形容 |
| 谁受益，谁可能受损 | 受益的角色与场景；被改变行为的现有用户或集成方 | 没有角色的「所有人」 |

列差异与受益者时，按角色、场景与情形交叉着列，不凭感觉列；空着的格就是漏掉的差异。先拆出独立变化的轴，交叉成表逐格看。做法加载技能 `think-orthogonal`。

三问写进[需求与不变式单](requirement-template.md)的前半。

## 什么算不变式

不变式是系统在这个需求落地后永远要守住的性质，不是功能，也不是实现约束。判据：

- 违反它会造成用户可见的错误、数据损坏、安全或租户边界的破坏，或者让别的领域的承诺失效。
- 它在任何实现方案下都成立，换一种实现它还在。
- 它能被验证：能写成测试、证明、类型或门禁。

不算不变式的：性能目标（那是需求）、「代码要整洁」（那是品味）、「用某个库」（那是选型）。这些各归各处。

每条不变式写三栏：性质本身、违反时的后果、谁守。「谁守」先写领域或边界，不写模块或文件，模块到细化设计才定。

## 产出

填[需求与不变式单](requirement-template.md)。单子填完的判据：

- 「值不值得做」一节有代理的结论与人的决定，或写明「不问：修复」。
- 三问各有具体答案，没有空栏，没有「待定」。
- 不变式每条都能说出违反的后果和验证方式。
- 用户看过并认可。这一步由人主导，代理不替人认可。

## 下一步

单子认可后进入 `domain-impact-analysis`。