宿舍WiFi网络计费系统要采购，招标需求书是第一道关口。需求书写得含糊，厂商就能往自己擅长的方向引，最后中标的方案看着漂亮，落地却一堆坑。我们替不少学校审过标书，最常见的毛病是：把厂商的宣传话术抄进需求，或者只写功能清单不写约束条件。这样的标书招来的，往往是最会包装的那家，不是最适合的那家。所以需求书怎么写，决定了后面几年舒不舒服。

需求要从自己的摸底数据倒推

前面说的现状摸底，这时候就派上用场了。需求书里写并发能力，别写支持万人并发这种空话，要写基于实测晚高峰并发多少、开学峰值多少，要求系统在该峰值下认证成功率不低于某个值。写容量，要附上实测的日均流量和楼栋数，要求按这个规模部署。我们见过需求书通篇没提自己学校任何数字，厂商按最小可用配置报价中标，上线一压测就垮。需求书的根，必须是你自己的数据，不是厂商的样例。

把对接和迁移写成硬指标

对接统一身份认证、迁移历史账号和账单，这两件事最容易在合同里被模糊处理，变成验收时的扯皮点。需求书要把它们写成硬指标：必须对接学校指定的认证协议、必须提供增量同步机制、历史账单迁移的准确率和时限要明确。我们建议把对接和迁移单独列一节，写清输入是什么、输出是什么、验收怎么测。含糊一句支持对接，厂商就能以接口不全为由加钱或者延期。把边界写死，后面才不会被拿捏。

计费和账务规则要写细

计费模式、套餐档位、月度封顶、超额计价、退款规则，这些必须写进需求书作为系统的强制能力，而不是让厂商自行设计。我们见过标书只写支持灵活计费，结果中标的系统只能做固定包月，学校想要的混合模式要做二次开发、另外收费。需求书最好把学校打算用的几种计费场景列成验收用例，比如包月超额断网、按量封顶提醒、退款原路返回，要求厂商现场演示通过才算达标。规则写细，厂商就绕不过去。

运维和权限要提要求

很多需求书重建设轻运维，结果系统建成了，日常怎么盯、权限怎么分、故障怎么告警全没要求。我们建议需求书单列运维章节：要求提供按楼栋的实时监控、支付与账单的每日对账、角色分级权限、关键故障的告警推送。这些不是锦上添花，是系统能不能长期跑下去的关键。把运维要求写进标书，厂商交付时就会把这些做成标配，而不是等你用了半年才发现根本没有。

验收标准要可测量

最后，需求书里的每一条，最好都能对应一个可测量的验收动作。支持高并发，那验收就压测；保障数据安全，那验收就查密码是否明文存储、日志是否留痕；跨楼漫游，那验收就真拿设备走两栋楼。我们帮学校改标书时，最核心的一件事就是把形容词换成动词和数值。需求书一旦可测量，厂商就不敢用话术填空，评标时也能横向比出真假。标书写得硬，后面几年都省心。

别被演示掩盖真实能力

评标时厂商的现场演示往往挑最顺的流程走，很多问题被藏起来了。我们建议需求书里写明，演示必须用学校自己提供的真实场景和数据，而不是厂商准备的完美样例。比如故意给一个异常账号、一笔退款、一次跨楼漫游，看系统能不能真处理。演示环境越接近真实，中标的系统落地越稳。被包装过的演示，是招标里最该警惕的东西。

售后响应要写进合同

系统建成之后的运维支持，必须在合同里写死响应时限和责任。我们见过标书只写提供售后服务，没写时限，结果系统半夜出问题，厂商第二天才回，学校自己熬了一夜。需求书要把关键故障的响应时间、到场时间、备用方案都列明，并且和付款挂钩。售后是长年累月的事，写进合同才约束得住，别指望厂商的口头善意。

留出二次开发的边界

再好的标准系统，学校也难免有个性化需求。需求书要写清哪些能力支持二次开发、接口是否开放、定制要不要额外收费。我们建议要求厂商提供标准的对接接口文档，学校自己的开发人员或者第三方能在此基础上扩展，不被锁死。留出二次开发的边界，等于给未来留了余地，学校不至于想加个小功能都得求着原厂商、还得挨一刀。