上个月去一家职业院校聊认证计费系统的项目，对方信息化主任开口第一句话是："我们想做一套，你们报个方案。"我问他现在用什么，他说"没用系统，手工登记"，问他有多少学生，他说"大概五千吧，具体数字要问后勤"。那天我在会议室坐了两个小时，把需求一条一条聊出来，发现他们真正需要的跟他一开始想的完全不是一回事。

第一步：搞清楚"谁在用"比"多少人用"重要得多

很多人做需求调研，第一件事是问"并发多少""峰值多少"，其实更应该先搞清楚用户构成。学生、教职工、临时访客、合作单位人员，这几类人的上网行为完全不同。学生宿舍是长时间在线、流量大、账户共享问题突出；教学楼是短时在线、认证频次高、对速度敏感；访客区域是流动性强、不需要计费、但审计要求高。

我见过一个项目，前期调研只问了"学校一万两千人"，没细分用户类型，结果系统上线后宿舍区半夜高峰期天天掉线，因为认证服务器配置的并发连接数按教职工场景设计的。后来排查了三天才发现，问题不在硬件性能，而在用户行为模型完全没搞对。

所以现在我去现场，会先要一张"网络使用场景分布表"——不一定非要正式表格，口头聊也行，但必须把这四类人各自的大致人数、上网时长、主要用途摸清楚。这个事情看起来基础，但漏掉了后面全歪。

第二步：现有网络拓扑和网络设备的"真实情况"

客户给你的网络拓扑图，和实际部署情况，经常是两回事。我养成了一个习惯，需求调研阶段一定要去机房看一下，最好是带着笔记本电脑现场测一下。有些老楼层的接入交换机，说明书上写的是支持802.1X，实际固件版本太老，配了也不生效。还有些场景，核心交换机下面是多级级联，中间某一级不支持DHCP Option，导致IP+MAC绑定方案直接废掉。

另外一个容易忽略的点是"有没有在用其他认证手段"。比如有些学校宿舍区已经装了PPPoE拨号，教学区用的是Web认证，这两套如果要统一到一套认证计费系统里，迁移方案就得提前想好。我一般会问清楚：哪些区域是必须保留原有认证方式的，哪些是可以一刀切升级的，过渡期怎么处理。

这个步骤花的时间多一点，但省下来的是后面实施阶段的返工成本。我算过一笔账，需求阶段多花两天做网络实地核查，后面实施阶段平均能少掉三次回现场。

第三步：计费策略的"真实业务逻辑"而不是"理想方案"

很多客户在需求调研阶段会说"我们要支持多种计费模式"，然后列出一堆：按时长、按流量、包月、包学期、按带宽档次等等。但你要继续问下去："现在的收费是怎么操作的？财务流程是什么？学生通过什么渠道缴费？"你会发现，有些业务逻辑比技术实现复杂得多。

比如有一个高校，想做"按实际使用时长计费"，技术上讲不难，但他们的财务制度要求"预收费+定期结算"，而且学生缴费必须通过学校统一支付平台，不能让认证计费系统自己收钱。这种情况下，"按实际时长计费"的业务闭环就做不到，因为系统没法实时扣费，只能做"先买套餐、后认证上网"的模式。

所以计费策略的需求调研，不能只停留在"支持哪些计费模式"这个层面，必须摸到背后的资金流、票据流、对账流程。我通常会请客户安排一次财务处的人一起参与调研，不谈技术细节，只聊业务流程。

第四步：与现有信息化系统的对接边界

认证计费系统很少是一个孤立系统。它至少要跟几个系统打交道：统一身份认证（单点登录）、宿舍管理系统（新生入住自动开通账户）、一卡通系统（充值消费记录打通）、教务系统（教职工身份同步）。

对接这件事，需求调研阶段就要把边界划清楚。不是所有对接都要做，也不是所有对接都能做。比如"跟一卡通对接"，客户说的可能是"学生充值后自动开通上网权限"，但技术实现上，是一卡通系统主动推送充值记录给认证计费系统，还是认证计费系统定时去一卡通数据库里拉数据，这两种方案工作量差很多。

我一般会在这个环节请客户把相关系统的运维负责人一起拉进来开个会，当面对齐：哪些数据要同步、同步频率是多少、接口是谁来开发、有没有现成的API文档。有一次我疏忽了这一步，到了实施阶段才发现客户那里的"统一身份认证"是他们自己找外包公司开发的一个简单登录页面，根本没有标准接口，最后对接方案全部推倒重来。

第五步：运维团队的真实技术能力评估

这一点很多集成商不愿意直面，但我觉得非常重要。认证计费系统上线之后，日常运维是谁来做？是信息化中心的专职网管，还是临时指定一个老师兼着？他们对Linux命令行的熟悉程度怎么样？有没有用过类似系统的后台？

我见过一个项目，系统选型阶段选了一套功能非常强大的产品，支持各种高级特性：多VLAN按需下发、基于应用层的策略路由、实时流量计费等。结果上线后，客户的运维人员只会用Web管理界面的最基础功能，那些"强大功能"全部闲置。更麻烦的是，有一次系统出了点小问题，运维人员不敢动，等厂家技术支持远程处理，结果等了两天。

所以现在需求调研，我会专门留出一个环节，跟后续负责运维的人聊一聊，甚至现场让他操作一下测试环境。如果评估下来运维团队能力有限，我会在方案中明确写出"建议配置哪些简化运维的功能"，比如自动告警、图形化排障工具、详细的操作日志等。

第六步：安全合规和审计要求的"本地化"差异

网络安全法、等级保护2.0，这些大框架客户一般都知道，但具体到落地执行，每个地方的要求不完全一样。比如有些省市的网安部门要求认证计费系统必须保留用户上网日志不少于六个月，而且日志必须能按"用户账号+时间段"快速检索。有些则还要求支持与网安部门的数据接口对接，能够按计划上报异常上网行为。

这些要求，如果在需求调研阶段没问出来，后面验收的时候就是坑。我通常会直接问客户："上次网络安全检查或等保测评，有没有提过跟认证计费相关的整改项？"如果客户说"没有"或者"想不起来了"，我会建议他们先去问一遍网安或信息化主管部门，把要求拿回来，我们再对应到系统功能里。

另外还有一个容易被忽略的点：等保测评不是一次性的，是周期性复评。系统上线的时候是符合的，但过了一两年，测评标准升级了，或者客户自己网络规模扩大了，可能就不符合了。这个风险要在需求阶段就跟客户说清楚，有些客户会选择"先做基础合规，后面再升级"，有些则希望一步到位。

第七步：项目时间表和"不可控因素"预判

最后这一步，是把前面所有调研结果转化成项目计划。但需求调研阶段做时间预估，不能只算"系统安装调试要几天"，必须把那些"不可控因素"也考虑进来。

什么是不可控因素？比如：客户方负责对接接口的开发人员刚好那段时间要参加考试，可能没时间配合；暑假期间学生宿舍要装修，网络要断网，系统上线时间就得避开；学校采购流程比较长，设备到货可能比预期晚两周；还有最经典的——"领导出差了，验收要等他回来"。

我做项目计划，一般会留出30%的缓冲时间。有些客户觉得我"把工期估长了"，但做过几个项目之后，他们反而会说"还是你当初留的时间余地够"。认证计费系统这个项目，技术难度不是最大的，但涉及部门多、业务流程长，任何一个环节卡住，整体进度就停了。

调研结束的时候，我会给客户提交一份需求确认书，不是那种几十页的正式文档，就是两页纸，把前面七个步骤聊出来的关键结论列出来，请他们确认。这个结果不作为最终验收标准，但作为后续方案设计和实施的基准。如果后面需求有大的变更，我们再来走变更流程。

说实话，需求调研这件事，没有太多高深的理论，就是耐心和细心。但你省掉的步骤，后面一定会以另一种方式还给你。