第二章：APP需求分析——用户画像、核心功能模块与非功能性需求

好，咱们正式开始动手之前，得先把「我们要做什么」这件事彻底想清楚。

我见过太多团队，一上来就画界面、写代码，结果做到一半发现需求没对齐，推倒重来。说白了，需求分析就是给整个项目打地基。地基歪了，上面盖的楼再漂亮也没用。

这一章，我们就来聊聊虚拟电厂聚合控制APP的需求分析。我会从三个角度切入：用户画像、核心功能模块、非功能性需求。嗯，这三个东西搞明白了，你的APP骨架就有了。

2.1 用户画像：谁在用你的APP？

你想想看，一个虚拟电厂的APP，使用者肯定不是普通老百姓。我把它分成三类核心用户：

• 调度员：坐在监控中心，盯着大屏，负责实时决策的人。
• 运维工程师：跑现场或者远程维护设备，处理告警和异常。
• 电厂管理者：看报表、做分析、向上汇报的决策层。

这三类人的需求完全不同。调度员要的是「快」——信息刷新快、操作响应快。运维要的是「准」——故障定位准、指令下发准。管理者要的是「全」——数据全面、报表清晰。

所以，做需求分析的第一步，就是先问自己：这个功能，到底是为谁做的？

2.2 核心功能模块：三大支柱

功能模块我把它分成三大块：监控、控制、报表。这三块缺一不可，而且有严格的先后依赖关系。

2.2.1 监控模块——看得见

监控是APP的「眼睛」。没有监控，你就像在黑暗中开车。

监控模块需要包含：

• 实时数据看板：展示各分布式资源的实时功率、电压、电流、频率等关键参数。刷新间隔建议≤1秒。
• 设备状态总览：用颜色标识设备运行状态（绿色=正常，黄色=告警，红色=故障）。
• 告警推送：当参数越限或设备异常时，APP必须第一时间推送通知。我曾经遇到过告警延迟超过30秒的情况，差点导致一次甩负荷事故。
• 地理分布图：在地图上展示所有接入资源的位置和实时出力情况。

2.2.2 控制模块——管得住

控制是APP的「手」。光能看不能动，那跟看监控视频有什么区别？

控制模块的核心功能：

• 远程启停：对单个设备或设备组进行远程启动/停止操作。注意，这个操作必须有二次确认机制。
• 功率调节：下发有功/无功功率设定值。支持百分比和绝对值两种模式。
• 策略下发：将预定义的调度策略（如削峰填谷、需求响应）一键下发到聚合单元。
• 操作日志：每一次控制操作都必须记录，包括操作人、时间、操作内容、执行结果。

这里我要特别强调一下安全性。控制模块是APP里最敏感的部分。我建议所有控制指令都走「双通道校验」——APP端发指令，云端确认，设备端再回执。三步缺一不可。

2.2.3 报表模块——说得清

报表是APP的「嘴」。你做了多少事，效果怎么样，都得靠报表来说话。

报表模块需要支持：

• 日/周/月/年报表：自动生成各时间维度的运行报表，包含发电量、用电量、调节次数、收益等关键指标。
• 对比分析：支持同期对比、环比分析，用柱状图或折线图展示趋势。
• 导出功能：支持导出为PDF或Excel格式，方便向上汇报。
• 自定义报表：允许用户拖拽选择指标，生成自己想要的报表格式。

2.3 非功能性需求：看不见但很重要

功能需求决定了APP「能不能用」，非功能性需求决定了APP「好不好用」。我把它归纳为五个维度：

维度	具体要求	我的建议值
性能	页面加载速度、数据刷新延迟、操作响应时间	首页加载≤2秒，数据刷新≤1秒，操作响应≤500ms
可靠性	系统可用性、数据不丢失、指令不遗漏	可用性≥99.9%，指令送达率100%
安全性	身份认证、权限控制、数据加密、操作审计	必须支持多因子认证，控制指令必须加密传输
易用性	界面简洁、操作路径短、学习成本低	核心操作不超过3步，新用户30分钟内可上手
可扩展性	支持新增设备类型、新增功能模块	采用插件化架构，新增功能不影响现有模块

2.4 知识体系结构图

下面这张图，我把本章的核心逻辑画出来了。你可以把它当作整个需求分析的「导航图」。

2.5 本章小结

需求分析这件事，说白了就是回答三个问题：

• 谁在用？——用户画像决定了你的设计方向。
• 做什么？——监控、控制、报表，三大模块一个都不能少。
• 做到什么程度？——非功能性需求决定了用户体验的底线。

我个人习惯在需求分析阶段花至少30%的时间。别急着写代码，先把这些问题想清楚。你想想看，如果方向错了，跑得再快也是白费力气。

好，这一章就到这里。下一章我们开始聊技术选型——用什么框架、什么协议、什么数据库。嗯，那才是真正动手干活的时候。

---