「我需要一台好点的交换机」不能拿去询价，要拆成一条条能判「满足或不满足」的项。 需求分必选、可选、不需要三档；必选项超过 8 条，市场上经常一个型号都没有。
上一节定了「买哪几类」，这一节把「类别」变成「具体型号」。 中间那一步就是需求清单：它是采购流程里唯一一份「技术说了算」的文件。
一、需求必须可判定
一条需求合格的标准是：任何人看了都能回答「满足」或「不满足」。 「性能要好」不合格，「吞吐不低于 100 Gbps」合格。
所以写需求时要把形容词换成数字或名称： 「稳定」→「支持双电源、双主控」；「好管理」→「支持 SNMPv3 与集中配置下发」。
这一步看着啰嗦，但它决定了后面能不能自动化筛选： 能判定的需求可以列成表打勾，不能判定的只能开会吵。
二、三档分野
每一条需求都要标档次，三档的含义与写错的后果完全不同：
档次 含义 写错的后果
必选 不满足就不能用 写成可选，会买到不能用的 可选 有更好，没有也能接受 写成必选，会筛掉全部型号 不需要 明确不要，避免为它付钱 不写，会为用不到的功能付费
第二行和第一行是一对反向陷阱：把可选项写成必选，会「筛得只剩一个型号」，询价变成走过场； 把必选项写成可选，会「买回来才发现不能用」，返工成本更高。
第三行最少人写，但它最省钱：明确「不需要三层路由」，就不会为用不到的功能付钱。 而销售最喜欢推的正是「什么都有」的那一档。
三、用必选项筛型号
四条必选就够筛掉一大半。拿一个真实的接入交换机需求看：
需求项 档次 A 型 B 型 C 型 D 型
48 个千兆电口 必选 满足 满足 满足 满足 4 个万兆 SFP+ 必选 满足 满足 满足 满足 支持 802.1X 必选 满足 满足 — 满足 PoE+ 总预算不低于 740 瓦 必选 满足 — 满足 满足 支持堆叠 可选 满足 满足 满足 满足 支持三层静态路由 可选 — — 满足 满足
四条必选筛完，只剩 A 型与 D 型。 B 型输在 PoE 总预算，C 型输在不支持 802.1X。
这一步的价值不是「选出最好的」，而是「把不可用的先删掉」： 剩下的两个再比价格、比支持、比交期，讨论范围小了一个量级。
两条硬经验：必选项超过 8 条，市场上经常一个都没有——这时要回去砍需求，不是继续找； 必选项里不要写「支持某某专有特性」，那等于指定品牌。
四、动手 Demo：功能需求怎么汇总成「能询价的清单」
这段把七条需求分成必选与可选两档，再用四个型号逐个打勾，看四条必选能把候选集缩到多小。
must_idx = [i for i, (_, m) in enumerate(req) if m]
alive = []
for name, flags in models.items():
if all(flags[i] for i in must_idx):
alive.append(name)
P(u"**四条必选筛完，剩下 %d 个型号：%s。**" % (len(alive), u"、".join(alive)))
实跑输出：
--------------------------------------------------------------------
功能需求怎么汇总成「能询价的清单」
--------------------------------------------------------------------
**「我需要一台好点的交换机」不能拿去询价。**
**要把它拆成一条条可以判「满足或不满足」的项。**
**需求分三档，这三档决定后面筛掉多少型号**：
档次 含义 写错的后果
--------------------------------------------------------------------
必选 不满足就不能用 写成可选，会买到不能用的
可选 有更好，没有也能接受 写成必选，会筛掉全部型号
不需要 明确不要，避免为它付钱 不写，会为用不到的功能付费
**拿一个真实的接入交换机需求做筛选**：
需求项 档次 A 型 B 型 C 型 D 型
--------------------------------------------------------------------------------
48 个千兆电口 必选 满足 满足 满足 满足
4 个万兆 SFP+ 必选 满足 满足 满足 满足
支持 802.1X 必选 满足 满足 — 满足
支持 PoE+ 且总预算不低于 740 瓦 必选 满足 — 满足 满足
支持堆叠 可选 满足 满足 满足 满足
支持三层静态路由 可选 — — 满足 满足
支持 25G 上行 可选 — — — 满足
**四条必选筛完，剩下 2 个型号：A 型、D 型。**
B 型被筛掉，因为它 PoE 总预算不够——插满 48 口供不上电。
C 型被筛掉，因为不支持 802.1X，认证方案就得换。
**这就是「必选项」的作用：它把讨论范围从「哪个好」缩到「哪几个能用」。**
**两条经验，都很硬**：
必选项超过 8 条，市场上经常一个型号都没有——这时要回去砍需求，不是继续找。
必选项里不要写「支持某某专有特性」，那等于指定品牌，询价就变成走过场。
**清单要能拿去询价，标准是「任何一家销售看了都知道该报哪个型号」**。
**做不到这一点，说明需求还没写清。**
注意这段代码里没有任何「评分」：它只做一件事——把不满足必选项的型号删掉。
这是刻意的：筛选和评分要分两步，不能混在一起。 混在一起的结果是「某项分数低但可以接受」被当成「不满足」，或者反过来。
筛完之后才轮到评分（价格、交期、支持各占权重），而评分的权重应该由业务定，不是由技术定。 这也是为什么需求清单要技术人员写、评分表要业务人员写。
30 秒实验
- 把「我需要一台好点的交换机」改写成三条可判定的需求。
- 给你手上的设备清单补一列「这条是必选还是可选」。
- 想一想：为什么「必选项超过 8 条」就该回去砍需求？
常见误区
- 以为需求写得越全越好。必选太多会筛掉全部型号，反而卡住流程。
- 以为「性能好」是需求。它不可判定，只能变成开会吵架的素材。
- 以为筛选和评分是一件事。先筛掉不能用的，再给能用的打分。
自测三问（点开对答案）
1. 一条合格的需求长什么样？ —— 任何人看了都能回答「满足」或「不满足」，即把形容词换成数字或明确名称。 2. 需求的三档是哪三档？写错各有什么后果？ —— 必选、可选、不需要；必选写成可选会买到不能用的，可选写成必选会筛掉全部。 3. 为什么「不需要」这一档也要写？ —— 明确不要的功能，才不会为它付钱；销售最喜欢推「什么都有」的那一档。下一节：清单有了，怎么跟厂商打交道——从 RFI 说起。
- ☐ （本节完，下一节 07.03.01 RFI与RFP）