校园网认证系统的建设项目启动后，多数学校的第一反应是组织产品演示、对比功能清单。这本身没错，但需求阶段如果只盯着功能列表做选择题，后面实施和运维阶段会反复返工。本文围绕需求梳理阶段容易跳过的三个环节展开。

一、账号生命周期管理的前置约定

认证系统最核心的操作对象是"人"——学生、教职工、访客、临时人员。不同角色的账号从创建到注销，经历的时间跨度和管理规则完全不同。

学生账号最典型的是"入学开通、毕业注销"。看起来简单，但中间夹杂着休学、复学、延期毕业、交换生、联合培养等变体。如果需求阶段没有把这些状态变化对应的认证策略约定清楚，上线后就会出现"休学学生仍然能登录校园网"或者"交换生无法获取临时账号"之类的问题。

教职工账号更复杂。合同制教师、返聘教授、访问学者、后勤外包人员，每个人群的开通条件和权限范围可能都不一样。有的学校人事系统和认证系统是两套独立运行的软件，账号同步靠人工 Excel 导入，这在需求阶段如果没被识别为风险点，后面运维成本会很高。

访客账号则牵涉到时效性和审批流。短期访客的账号有效期设多长？谁有权限审批？是自助申请还是管理员统一创建？这些细节如果在需求文档里只有一句"支持访客管理"而没有展开，供应商交付的很可能只是一个简陋的"手动创建临时账号"功能，离实际使用场景差得很远。

需求梳理阶段的建议做法是：让教务、人事、后勤、信息中心各自列出一份角色清单，把每个角色的账号开通条件、权限范围、有效期规则、注销条件逐条写下来。这份清单会成为后面验收测试的重要依据。

二、网络架构层面的先决条件

认证系统不是孤立运行的。它要和现有的网络基础设施协同工作，包括核心交换机、汇聚层设备、无线控制器、出口网关等。如果需求阶段没有对网络架构做一个全面的摸底，后面会发现很多"理论上支持、实际上不兼容"的情况。

第一个容易遗漏的点是 VLAN 规划。有些学校的历史 VLAN 划分是按楼栋或按楼层来的，并没有把一个楼栋里的不同用户角色拆到不同 VLAN。认证系统如果要基于用户角色下发不同的网络策略，就要求 VLAN 划分能够支撑这种策略的落地。如果 VLAN 架构和认证策略对不上，就需要在需求阶段明确是要调整网络架构，还是调整认证策略的粒度。

第二个点是无线网络的 SSID 规划。很多学校同时有多个 SSID，比如面向学生的、面向教职工的、面向访客的。认证系统需要知道用户从哪个 SSID 接入，才能判断应该调哪个认证页面、用哪种认证方式。需求阶段如果不把 SSID 和认证方式的映射关系定清楚，上线后可能出现"学生连了教职工的 SSID 也能上网"这种策略上的漏洞。

第三个点是出口带宽和审计要求。认证系统上线后，用户上网行为会有更精细的记录，这对满足审计要求是好事，但同时对日志存储和带宽管理提出了更高要求。需求阶段应该结合学校的出口链路情况和审计合规要求，评估日志保留周期和存储容量需求。

三、用户体验层面的隐性需求

功能层面的需求通常比较容易被捕捉到，但用户体验层面的需求经常被忽视，而这些恰恰是上线后师生投诉最集中的地方。

认证页面加载速度是一个典型问题。很多学校的认证页面是 Portal 方式弹出来的，用户在浏览器里输入任意网址，先跳转到认证页面。如果这个跳转过程超过三到五秒，在移动端体验就会很差。需求阶段如果能明确提出"认证页面加载时间不超过 X 秒"这样的性能指标，供应商在方案设计时就会考虑页面资源优化、CDN 部署等手段。

认证方式的选择也需要结合用户习惯。用户名密码认证是最传统的方式，但学生更习惯扫码或者短信验证码。不同认证方式的技术实现难度不一样，需求阶段应该让信息中心和师生代表一起讨论，而不是信息中心单方面决定。

还有一点容易被忽略的是自助服务。学生忘记密码、更换设备、查看上网记录这些场景，如果都需要打电话给信息中心解决，服务台的压力会非常大。需求阶段如果能明确自助服务需要覆盖哪些场景，就能倒逼供应商在方案里把这些功能做进去。

这些用户体验层面的需求写不进招标参数里，但上线后直接影响师生对信息中心工作的评价。需求梳理阶段专门花一点时间讨论这些点，比上线后被动应对投诉划算得多。

需求梳理不是走形式，而是把后续实施和运维阶段可能遇到的坑提前排查一遍。跳过这三个环节的代价，通常是在上线前加班填坑。