2. 统一管理平台需求分析：业务需求梳理、功能需求定义、非功能性需求

好，咱们进入第二章。需求分析，说白了就是搞清楚「我们要做什么」。

我见过不少项目，一上来就画界面、写代码，结果做到一半发现方向错了。嗯，那真是灾难。所以，咱们先把需求这块地基打牢。

2.1 业务需求梳理：先搞清楚「谁在用」和「用来干嘛」

我个人习惯，做任何系统之前，先画一张「用户地图」。PIS 统一管理平台，表面上看是管屏幕的，实际上它服务的角色很杂。

• 运营调度员：他们最关心「当前所有线路的屏幕是不是都正常？」。一旦有故障，得立刻知道是哪块屏、在哪站。
• 维护工程师：他们需要远程诊断、重启设备、查看日志。总不能每条线路都派人跑现场吧？
• 内容编辑：负责发布紧急通知、节假日祝福、广告。他们希望「一次编辑，多线发布」。
• 管理层：看报表、看统计、看KPI。比如「本月全线网PIS可用率是多少？」。

我在项目中遇到过，有个客户非要加一个「乘客留言反馈」功能。后来发现，这根本不是PIS该管的，那是客服系统的事。所以，业务需求梳理的第一步，就是划清边界。

2.2 功能需求定义：把业务需求翻译成系统功能

业务需求是「人话」，功能需求是「系统话」。咱们一条条拆。

2.2.1 线路与设备管理

说白了，就是给每条线路、每个车站、每块屏幕建个「身份证」。

• 支持线路的增删改查
• 支持车站的分组管理（比如按行政区、按线路编号）
• 设备注册与注销，记录设备型号、IP、安装位置

2.2.2 实时监控与告警

这是核心中的核心。你想想看，调度员盯着大屏，如果某块屏黑了，系统得在3秒内弹窗报警。

• 设备在线/离线状态实时刷新
• 播放内容截图回传（确认屏幕到底在播什么）
• 告警分级：紧急（设备离线）、警告（网络延迟）、提示（日志异常）

2.2.3 内容发布管理

编辑们最爱的功能。支持图文、视频、滚动字幕。

• 支持模板化编辑（比如「紧急通知」模板，一键套用）
• 支持按线路、按车站、按时间段发布
• 支持发布审核流程（避免误发）

2.2.4 日志与报表

出了问题，得有据可查。

• 操作日志：谁、在什么时间、做了什么操作
• 设备日志：设备重启记录、播放异常记录
• 报表导出：支持Excel、PDF格式

2.3 非功能性需求：决定系统「好不好用」

功能需求决定「能不能用」，非功能性需求决定「好不好用」。很多项目死就死在非功能需求上。

2.3.1 性能需求

我习惯用「3-5-10」原则来定指标：

场景	指标	说明
页面加载	≤3秒	首屏加载时间，包含所有静态资源
设备状态刷新	≤5秒	从设备上报到界面更新
告警响应	≤10秒	从故障发生到告警弹出
并发用户	≥200	同时在线操作不卡顿

2.3.2 可用性需求

轨道交通系统，7×24小时不能停。你想想看，早高峰的时候系统宕机了，那画面太美我不敢看。

• 系统可用性：≥99.9%（每年宕机时间不超过8.76小时）
• 数据持久性：关键数据（设备状态、发布记录）实时备份
• 故障恢复：主备切换时间≤30秒
• 容错设计：单点故障不影响整体系统运行

2.3.3 安全性需求

PIS系统虽然不直接控制列车，但它连着运营网络。一旦被攻击，后果很严重。

• 身份认证：必须使用强密码策略，支持双因素认证
• 权限控制：基于角色的访问控制（RBAC），比如编辑不能看到运维菜单
• 数据传输：所有API通信必须使用HTTPS加密
• 审计日志：所有敏感操作（如删除设备、修改发布内容）必须记录
• 防篡改：发布的内容在传输过程中要有完整性校验

2.4 需求优先级排序：先做「雪中送炭」的

需求永远做不完。我习惯用「MoSCoW法则」来排优先级：

• Must have（必须有）：实时监控、告警、设备管理、内容发布
• Should have（应该有）：报表导出、日志查询、权限管理
• Could have（可以有）：大屏可视化、移动端APP
• Won't have（这次不做）：AI智能排班、客流预测（这些是其他系统的活）

嗯，需求分析这块，咱们就聊到这儿。记住一句话：需求分析不是写文档，而是和用户一起把「模糊的想法」变成「清晰的边界」。

下一章，咱们开始聊系统架构设计。到时候我会分享一个我踩过的坑——关于「微服务拆分粒度」的教训。