第一组房屋智能化电磨房需求分析

电磨房需求分析

一、项目背景

随着社会对节能环保意识的提升以及家庭和企业对用电成本控制需求的增加，广大电力用户在日常用电管理和信息获取方面遇到了诸多不便。传统查询电费、了解节能方法、办理电力相关业务的渠道往往操作繁琐、信息分散、体验不佳。用户缺乏一个便捷、集成化的工具来直观地了解自己的用电情况、潜在的节约空间（包括电费和电量），以及快速访问相关的电力服务。

特别是微信作为国民级应用，拥有庞大的用户基础，在此平台上提供电力服务具有天然的用户触达优势。然而，目前可能缺乏足够友好、功能全面的小程序来满足用户精细化管理用电的需求。

为了解决用户在用电管理中遇到的信息不对称、操作不便等痛点，并抓住移动互联网和节能趋势带来的机遇，特启动本 "电力魔方"（或"电魔房"）微信小程序的开发。

本项目旨在为用户提供一个集成化的移动用电管理平台，帮助用户方便地追踪用电数据、可视化地了解省钱和节能效果、便捷地办理相关电力业务，最终提升用户用电管理的效率和体验，促进节能减排意识的普及。

二、用户需求概述

角色 1：普通居民用户 (中产家庭)

日常工作任务或业务流程需求：

现状: 用户通常通过纸质账单、短信通知、或登录电力公司官网/APP (若有) 查询电费和用电量；了解节能知识主要靠自行搜索或经验积累；办理用电业务（如报修、咨询、缴费等）可能需要前往营业厅或拨打客服电话。整个过程可能比较分散、耗时，且难以直观了解详细的用电模式和节省潜力。

期望系统协助: 用户期望能通过本小程序一站式完成以下任务：

• 随时查看当前及历史用电量、电费明细。
• 方便地了解不同时段（峰谷平）的用电情况。
• 直观地看到采取某些节能措施（如更换电器、调整用电习惯）可能带来的省钱和节能效果估算。
• 获取个性化的节能建议和技巧。
• 在线便捷办理部分常用电力业务，如查询缴费记录、获取电子账单、甚至在线缴费或报修。

对系统功能的期望：

• 用电数据可视化查询： 提供清晰的图表（如曲线图、柱状图）展示日/月/年用电量及费用趋势，区分峰谷用电量。
• 电力资讯与节能贴士： 提供官方发布的电价政策、停电通知、以及实用的家庭节能技巧。

角色 2：（普通用户）

说明：根据现有信息，主要用户群体是普通居民。未来若扩展功能，可能包含如小型商户、小区物业管理员等角色，他们的需求会在电量更大、计费方式更复杂、或需要管理多个账户等方面有所不同。例如，小型商户可能更关注生产用电成本分析，物业管理员可能需要查看公区用电等。

整理各角色需求的共性与差异，强调核心需求点：

共性需求： 核心共性需求在于透明化、便捷化地获取用电信息。无论是哪个角色，都希望能方便地了解用了多少电、花了多少钱，并希望获得如何节省的有效信息。对简化业务办理流程、提高互动效率也有共同期待。

差异性需求（潜在）： 不同角色（如居民 vs. 商户）在用电规模、计费复杂性、关注点（生活成本 vs. 生产成本）上存在差异，导致对数据分析的深度、业务办理的具体类型需求不同。

核心需求点：

• 数据可及性与可视化： 让用户能轻松看懂自己的用电数据和账单。
• 价值反馈（省钱/节能）： 清晰展示用户的节省潜力或成果，提供决策支持。
• 服务便捷性： 简化用户与电力服务相关的互动流程。

这些核心需求点，特别是数据可视化、节能省钱效果估算、以及服务便捷化，应作为本项目功能设计的重点方向，引导后续的功能规划和优先级排序。

三、功能性需求

功能模块 1：用电数据查询与分析

功能 1.1：历史用电量查询

描述： 用户可以查询指定时间范围内的详细用电量数据。

输入： 用户选择查询周期（如按日、按月、按年）、起止时间。

操作流程： 用户在界面上选择时间维度和范围 -> 系统根据用户身份和选择的范围，向后端请求对应的用电量数据（可能包含总用电量、峰时段用电量、谷时段用电量、平时段用电量等）。

输出结果： 系统以列表和图表（如曲线图、柱状图）的形式清晰展示所选时间范围内的用电量数据及趋势。

功能 1.2：历史电费账单查询

描述： 用户可以查询历史月份的电费账单详情。

输入： 用户选择需要查询的账单月份。

操作流程： 用户在界面上选择账单月份 -> 系统根据用户身份和选择的月份，向后端请求对应的电费账单详细信息。

输出结果： 系统展示该月份的详细电子账单，包括总电费、用电量明细、电价构成（阶梯电价各档用量及电价）、缴费状态等。

功能 1.3：用能分析报告查看

描述： 系统为用户提供多维度的用能情况分析。

输入： 用户进入用能分析报告页面。

操作流程： 系统自动或根据用户请求，基于历史用电数据进行分析，可能包括与上期/去年同期对比、峰谷用电比例分析、用电异常提示等。

输出结果： 展示分析结果、图表以及可能的节能建议。

与其他功能模块的交互：

• 为 "用户中心/首页" 模块提供关键数据的概览。
• 为 "节能省钱测算" 模块提供计算所需的基础用电数据。
• "个人设置" 模块的用户绑定信息是本模块获取正确数据的前提。

功能模块 2：节能省钱测算

功能 2.1：节能潜力测算

描述： 帮助用户估算采取特定节能措施（如更换电器）后的潜在节电量。

输入： 用户选择或输入假设的节能措施信息，例如：

• 选择要更换的电器类型（可能来自 deviceChoose 页面的列表）。
• 输入旧电器的功率、每日使用时长。
• 选择或输入新电器的功率、每日预估使用时长。

操作流程： 用户在界面输入或选择相关参数 -> 系统根据用户输入的参数以及可能的默认用电模式，计算更换电器前后的小时/日/月/年耗电量差异。

输出结果： 展示预估的节电量（例如：预计每年可节省 XX 度电）。

功能 2.2：省钱潜力测算

描述： 帮助用户估算采取特定节能措施或调整用电习惯后的潜在电费节省额。

输入：

• 可以直接基于 "功能 2.1 节能潜力测算" 的结果（节电量）。
• 用户也可以输入其他假设条件，如将多少度高峰用电转移到低谷。

操作流程： 系统获取预估的节电量（分峰谷时段更佳）-> 结合从后端获取的用户当前执行的电价方案（阶梯电价、峰谷电价）-> 计算预估节省的电费金额。

输出结果： 展示预估的电费节省金额（例如：预计每月可节省 XX 元）。

与其他功能模块的交互：

• 可能需要从 "用电数据查询与分析" 模块获取用户的历史用电模式作为计算基准。
• deviceChoose 页面可能作为电器选择的输入来源。
• 测算结果（sdfResult, jnyResult）可能在本模块显示，或传递给 "用电数据查询与分析" 模块的报告部分。
• 需要从 "个人设置" 或后端获取用户的电价信息。

功能模块 3：电力业务服务

功能 3.1：业务介绍与指南

描述： 向用户展示电力公司提供的各项服务信息、政策解读、办事指南等。

输入： 用户选择浏览相关信息分类或具体业务介绍。

操作流程： 用户点击相应链接或菜单 -> 系统展示预先配置好的静态或动态内容（图文信息）。

输出结果： 显示相关的业务介绍、办理条件、流程说明等。

功能 3.2：在线业务申请/办理

描述： 提供部分常用电力业务的在线申请或办理入口。

输入： 用户选择要办理的业务类型（如故障报修、电费缴纳、电子账单订阅、联系方式变更等），并按要求填写表单信息。

操作流程： 用户选择业务并填写表单 -> 系统校验表单数据 -> 将申请信息提交至电力公司后端业务系统处理。

输出结果： 提交成功提示，可能包含业务流水号供后续查询；或提交失败及原因提示。

功能 3.3：常见问题 (FAQ)

描述： 提供常见用电问题的解答库。

输入： 用户通过关键词搜索或按分类浏览。

操作流程： 用户输入关键词或选择分类 -> 系统从 FAQ 数据库中检索匹配的问题和答案。

输出结果： 展示相关问题列表及答案详情。

与其他功能模块的交互：

• 需要用户登录/绑定信息（来自 "个人设置"）才能办理大部分业务。
• 业务办理结果的状态更新可能触发 "消息通知" 模块发送通知。

功能模块 4：消息通知

功能 4.1：接收推送消息

描述： 用户可以接收来自系统的各类推送通知。

输入： 系统后台事件触发（如新账单生成、缴费到期、停电公告发布等）。

操作流程： 后台系统根据业务规则生成通知内容 -> 通过微信消息推送接口发送给绑定的用户。

输出结果： 用户在微信中收到服务通知或模板消息。

功能 4.2：消息中心

描述： 提供一个集中的地方查看历史接收到的通知。

输入： 用户进入消息中心页面。

操作流程： 系统从数据库中读取该用户的历史通知记录。

输出结果： 按时间倒序列出历史通知列表，用户可点击查看详情。

与其他功能模块的交互：

• 接收来自 "用电数据查询与分析"（如账单生成）、"电力业务服务"（如业务办理状态更新）等模块的触发信号。
• 用户是否接收及接收哪些通知，受 "个人设置" 模块中的偏好设置影响。

功能模块 5：个人设置

功能 5.1：用电户号绑定/管理

描述： 用户可以将自己的微信账号与一个或多个电力用户户号进行绑定，以便查询和管理。

输入： 用户输入电力户号、户主姓名、预留手机号等信息，可能需要接收短信验证码。

操作流程： 用户提交绑定信息 -> 系统调用电力公司提供的接口进行验证 -> 验证通过则建立绑定关系；用户也可在此解绑或切换当前管理的户号。

输出结果： 绑定/解绑成功或失败的提示信息；显示已绑定的户号列表。

功能 5.2：联系方式管理

描述： 允许用户修改在电力公司登记的联系手机号码（如果接口允许）。

输入： 用户输入新的手机号码，可能需要短信验证。

操作流程： 用户提交新号码 -> 系统调用接口更新电力公司后端数据。

输出结果： 更新成功或失败的提示。

功能 5.3：消息通知设置

描述： 用户可以自定义愿意接收哪些类型的系统通知。

输入： 用户勾选或取消勾选各类通知选项（如账单提醒、缴费提醒、活动通知等）。

操作流程： 用户修改设置 -> 系统保存用户的偏好配置。

输出结果： 设置保存成功的提示。

与其他功能模块的交互： 户号绑定是所有需要用户特定数据的功能模块（如数据查询、业务办理）正常运行的基础。设置直接影响 "消息通知" 模块的行为。

 

四、非功能性需求

性能需求

响应时间

• 常规操作： 页面加载、数据查询（如当月用电量、最近账单）等常规用户交互，在正常网络条件下，响应时间应不超过 3 秒。
• 数据密集型操作： 查询较长历史跨度的数据（如年度用电趋势）、执行节能/省钱测算等，响应时间应不超过 5 秒。
• 高峰时段： 在预估的业务高峰期（如月初/月底账单查询高峰），系统主要功能（查询、展示）的响应时间应维持在 5 秒以内。

吞吐量

• 系统应能支持至少 [待定，根据预估用户量设定，例如：100] 个并发用户同时进行常规查询操作。
• 系统应能稳定处理每日至少 [待定，例如：10,000] 次的核心数据查询请求。

数据存储与读取效率

• 历史用电数据（如按日、按月）查询应进行优化，即使存储数据量达到 [待定，例如：3 年] 以上，查询近一年数据的效率不应显著下降。
• 后端数据库应对常用查询字段（如用户标识、时间戳、户号）建立索引，提高读取效率。

安全需求

用户身份验证

• 利用微信小程序的 wx.login 获取用户临时凭证，结合后端服务换取用户唯一标识（openid 或 unionid）作为小程序内的身份识别基础。
• 户号绑定时，必须采用多因素验证，至少需要正确的电力户号、户主姓名（或身份证后几位），并通过向在电力公司预留的手机号码发送短信验证码进行校验，确保用户身份的真实性。

数据加密

• 所有小程序前端与后端服务器之间的数据传输必须使用 HTTPS 协议进行加密。
• 用户敏感数据（如电力户号、用户姓名、身份证信息片段、详细住址、手机号码）在数据库存储时应进行加密处理（例如使用 AES 等行业标准对称加密算法），密钥需妥善管理。
• 微信 openid 等身份标识符应视为敏感信息，避免在前端日志或不安全渠道泄露。

访问控制

• 严格遵循最小权限原则。普通用户登录后只能访问和操作与其绑定的电力户号相关的数据和功能。
• 后端 API 接口必须对用户身份进行校验，确保请求者有权访问所请求的数据或执行操作。禁止未授权的跨用户数据访问。
• 未来若引入管理员等其他角色，需建立独立的、基于角色的访问控制（RBAC）机制。

安全审计

• 系统后端应记录关键的安全相关事件日志，包括但不限于：用户登录尝试（成功/失败）、户号绑定/解绑操作、敏感信息修改尝试、重要业务办理请求、API 异常访问尝试。
• 日志应包含时间戳、操作用户标识、事件类型、源 IP 地址（若适用）等信息，以便于安全审计和问题追踪。

易用性需求

界面设计

• 遵循 微信小程序官方设计指南，保持界面风格统一、简洁、直观。
• 信息层级清晰，导航明确，常用功能应放置在易于访问的位置。
• 数据可视化（如图表）应清晰易懂，关键信息突出。
• 操作流程应尽可能简化，减少用户输入步骤。对用户的操作给予及时的、明确的反馈（如加载提示、成功/失败提示）。

操作指南

• 在关键或复杂功能点（如节能测算）提供内嵌的操作提示或信息图标 (?) 说明。
• 提供一个“帮助与反馈”入口，包含常见问题解答 (FAQ)。
• 考虑提供指向在线客服或客服电话的便捷链接。

多终端支持

• 小程序需在主流 iOS 和 Android 操作系统上稳定运行，兼容近两年发布的微信主要版本。
• 界面元素应能自适应不同尺寸的手机屏幕，保证显示效果和操作体验良好。

兼容性需求

微信客户端兼容

• 明确支持的最低微信客户端版本号（例如：要求微信版本 8.0.0 及以上）。需在多个主流手机品牌和型号上进行测试，确保兼容性。

软件 / 硬件兼容

• 除对微信客户端本身的要求外，目前未明确依赖特定硬件。
• 需确保后端接口与电力公司提供的业务系统接口版本兼容，接口变更时需同步更新和测试。

五、系统架构需求

总体架构设计

架构模式描述：

本项目采用经典的 前后端分离 的 分层架构 (Layered Architecture) 模式，结合微信小程序的生态特点进行设计。

客户端 (Client-Side - 微信小程序)

作为 表现层 (Presentation Layer)，运行在用户的微信环境中。负责：

• 用户界面的展示 (WXML, WXSS)。
• 用户交互的响应 (JavaScript)。
• 调用后端 API 获取数据和提交请求。
• 利用微信提供的能力 (如登录、支付、消息通知等)。

后端服务 (Server-Side - 应用服务器)

作为主要的 业务逻辑层 (Business Logic Layer) 和 数据访问层 (Data Access Layer)。负责：

• 提供 RESTful API 接口供小程序调用。
• 处理核心业务逻辑，如用户身份验证、户号绑定、数据查询聚合、节能省钱计算、业务流程处理等。
• 与 内部数据库 交互，存储和读取用户信息、绑定关系、配置、缓存数据等。
• 与 外部电力公司系统接口 交互，获取实时的用电数据、账单信息，并提交业务办理请求。后端内部可进一步细化分层，例如：

API/Controller 层:

接收请求，参数校验，调用服务。

Service 层:

实现核心业务逻辑。

Repository/DAO 层:

封装数据访问操作（数据库和外部 API）。

数据存储 (Data Storage)

• 内部数据库: (例如 MySQL, PostgreSQL) 存储小程序自身管理的数据。
• (可能) 缓存服务: (例如 Redis) 用于缓存热点数据，提高响应速度。

外部依赖 (External Dependencies)

• 微信平台 API: 用于登录、支付、消息推送等。
• 电力公司业务系统 API: 获取核心电力数据和处理业务的核心依赖。

选择该架构的原因：

• 前后端分离： 使得前端（小程序界面交互）和后端（业务逻辑数据处理）可以独立开发、测试和部署，提高开发效率和灵活性。
• 分层清晰： 各层职责明确，降低了系统的耦合度，便于维护和扩展。表现层专注于用户体验，业务逻辑层关注核心流程，数据访问层处理数据持久化和外部交互。
• 技术成熟： 是构建 Web 和移动应用的标准且成熟的架构模式，有大量的最佳实践和工具支持。
• 适应小程序： 符合微信小程序通过 API 与后端服务通信的开发模式。

扩展性需求

功能扩展

未来方向： 系统未来可能需要扩展以下功能：

• 更详细的用能分析，如基于时间段的电器能耗估算。
• 与智能家居设备的联动，实现用电优化控制。
• 在线缴纳电费功能。
• 引入积分、勋章等用户激励体系。
• 提供更复杂的在线业务办理流程（如过户、改类等）。
• 针对不同用户类型（如商业用户）提供定制化功能。

架构支持：

• 后端服务应采用模块化设计，将不同业务领域（如用户管理、数据查询、业务办理、节能计算）的功能封装在独立的模块或服务中。
• 定义清晰、稳定的 API 接口规范，方便新增功能模块或未来可能的微服务化改造。
• 关键业务流程节点预留扩展点或钩子 (Hooks)，允许在不修改核心代码的情况下增加附加逻辑。

性能扩展

增长预期： 随着用户量和推广力度的增加，系统并发访问量和存储的历史数据量将持续增长。

扩展策略：

• 后端服务： 设计为无状态服务，以便通过水平扩展 (Horizontal Scaling) （增加服务器实例数量）来提高处理能力。需配合使用负载均衡器 (Load Balancer) 将请求分发到不同的实例。
• 数据库：
  • 初期可通过垂直扩展 (Vertical Scaling) （提升服务器配置）应对增长。
  • 长期需考虑数据库优化（如索引优化、SQL 调优、慢查询分析）。
  • 引入缓存机制 (Redis等) 缓存热点数据，减轻数据库压力。
  • 对于读密集型场景，可考虑读写分离架构，设置只读副本。
  • 数据量极大时，可能需要考虑分库分表 (Sharding) 方案（复杂度较高，后期考虑）。
• 异步处理： 对于非实时、耗时较长的操作（如生成复杂报表、批量通知），应采用消息队列 (Message Queue) 实现异步处理，避免阻塞主业务流程。
• 外部接口调用： 对电力公司接口的调用需实现合理的超时、重试机制，并考虑限流，避免因外部系统缓慢或故障影响自身稳定性。

• 

   

六、数据需求

数据实体

实体 1：用户 (User)

字段名	描述
user_id	用户唯一标识符 (Primary Key, 数值型或 UUID)
wechat_openid	微信 OpenID (文本型, 唯一, 必需, 索引) - 用于关联微信用户。
wechat_unionid	微信 UnionID (文本型, 唯一, 可选, 索引) - 用于跨公众号/小程序识别用户。
nickname	用户昵称 (文本型, 可选) - 从微信获取。
avatar_url	用户头像 URL (文本型, 可选) - 从微信获取。
phone_number	用户手机号 (文本型, 可选, 索引) - 用户自行提供或微信授权获取，可能需验证。
registration_time	注册时间 (时间戳, 必需) - 用户首次授权登录时间。
last_login_time	最后登录时间 (时间戳) - 用户最近一次登录时间。
notification_preferences	消息通知偏好 (JSON 或 文本型, 可选) - 存储用户对不同类型通知的接收设置。

实体 2：电力户号 (ElectricityAccount)

字段名	描述
account_id	电力户号内部标识符 (Primary Key, 数值型或 UUID)
account_number	电力用户号 (文本型, 唯一, 必需, 索引) - 电力公司分配的官方用户编号。
account_holder_name	户主姓名 (文本型, 加密存储, 必需) - 用于验证绑定。
account_address	用电地址 (文本型, 加密存储, 可选) - 用户的用电地址信息。
tariff_plan_info	电价方案信息 (文本型或 JSON, 可选) - 描述用户当前的电价类型（如阶梯、峰谷）及相关参数，可能从外部接口获取。
verification_phone	验证手机号 (文本型, 加密存储, 必需) - 在电力公司登记的用于接收验证信息的手机号。
creation_time	记录创建时间 (时间戳) - 该户号记录在本系统创建的时间。
last_update_time	最后更新时间 (时间戳) - 户号相关信息（如电价方案）最后更新的时间。

实体 3：用户户号绑定关系 (UserAccountBinding)

字段名	描述
binding_id	绑定关系唯一标识符 (Primary Key, 数值型或 UUID)
user_id	用户标识符 (Foreign Key, 关联 User 实体的 user_id, 索引)
account_id	电力户号标识符 (Foreign Key, 关联 ElectricityAccount 实体的 account_id, 索引)
binding_time	绑定时间 (时间戳, 必需) - 用户成功绑定该户号的时间。
is_default	是否默认户号 (布尔型, 默认 false) - 标记是否为用户管理多个户号时的默认显示户号。
status	绑定状态 (文本型, 例如 'Active', 'Inactive', 必需) - 当前绑定关系的有效状态。

实体 4：用电数据记录 (ElectricityUsageData)

字段名	描述
usage_id	用电数据记录唯一标识符 (Primary Key)
account_id	电力户号标识符 (Foreign Key, 关联 ElectricityAccount, 索引)
record_datetime	记录时间点或日期 (时间戳或日期类型, 索引) - 数据对应的时间。
usage_type	数据类型 (文本型, 例如 'Daily', 'Monthly', 'Hourly', 必需) - 数据的统计粒度。
total_consumption	总用电量 (数值型, decimal)
peak_consumption	峰时段用电量 (数值型, decimal, 可选)
valley_consumption	谷时段用电量 (数值型, decimal, 可选)
flat_consumption	平时段用电量 (数值型, decimal, 可选)
fetch_time	数据获取时间 (时间戳) - 本次数据从外部接口同步或缓存的时间。

实体 5：电费账单 (ElectricityBill)

字段名	描述
bill_id	账单唯一标识符 (Primary Key)
account_id	电力户号标识符 (Foreign Key, 关联 ElectricityAccount, 索引)
billing_period	账单周期 (文本型, 例如 'YYYY-MM', 索引) - 账单对应的月份。
total_amount	账单总金额 (数值型, decimal)
payment_status	缴费状态 (文本型, 例如 'Unpaid', 'Paid', 'Overdue')
issue_date	账单出具日期 (日期类型)
due_date	缴费截止日期 (日期类型)
bill_details	账单明细 (JSON 或文本型, 可选) - 存储详细的电量电费计算构成。
fetch_time	数据获取时间 (时间戳) - 本次账单数据同步或缓存的时间。

实体 6：消息通知 (Notification)

字段名	描述
notification_id	通知唯一标识符 (Primary Key)
user_id	用户标识符 (Foreign Key, 关联 User, 索引)
notification_type	通知类型 (文本型, 必需, 例如 'BillGenerated', 'PaymentDue', 'SystemUpdate')
title	通知标题 (文本型, 可选)
content	通知内容 (文本型, 必需)
send_time	发送时间 (时间戳, 必需)
read_status	阅读状态 (布尔型, 默认 false)
related_entity_id	关联实体 ID (数值型或文本型, 可选) - 指向触发通知的具体实体，如账单 ID。
related_entity_type	关联实体类型 (文本型, 可选) - 说明 related_entity_id 指向的实体类型，如 'Bill'。

数据关系

• 用户 (User) 与 用户户号绑定 (UserAccountBinding): 一对多 (One-to-Many)。一个用户可以绑定多个电力户号，每个绑定记录只属于一个用户。
• 电力户号 (ElectricityAccount) 与 用户户号绑定 (UserAccountBinding): 一对多 (One-to-Many)。一个电力户号理论上可以被多个用户绑定（如家庭成员共享），每个绑定记录只关联一个电力户号。
• 用户 (User) 与 电力户号 (ElectricityAccount): 多对多 (Many-to-Many) 关系，通过 UserAccountBinding 这个中间表（连接实体）实现。
• 电力户号 (ElectricityAccount) 与 用电数据记录 (ElectricityUsageData): 一对多 (One-to-Many)。一个电力户号对应多条不同时间或粒度的用电数据记录。
• 电力户号 (ElectricityAccount) 与 电费账单 (ElectricityBill): 一对多 (One-to-Many)。一个电力户号对应多个账单周期的电费账单。
• 用户 (User) 与 消息通知 (Notification): 一对多 (One-to-Many)。一个用户可以接收多条系统或业务相关的消息通知。

约束条件

• 在 UserAccountBinding 表中，user_id 和 account_id 的组合应该是唯一的，防止同一用户重复绑定同一户号。
• 所有外键 (Foreign Key) 关系应强制实施，确保数据引用的完整性。删除用户或电力户号时，需要考虑如何处理关联的绑定记录、数据记录和通知（例如级联删除或设置为无效状态）。

七、项目进度安排

需求调研与分析阶段

时间区间： 第 1 天 - 第 2 天上午

关键里程碑： 核心 MVP (Minimum Viable Product) 需求列表确认。

主要任务： 快速与关键干系人沟通，聚焦最核心、必须上线的功能；快速记录并确认核心需求清单或用户故事。省略详细文档撰写，以口头或简要书面形式确认。

输出物： 确认的核心功能列表/核心用户故事。

系统设计阶段

时间区间： 第 2 天下午 - 第 3 天

关键里程碑： 核心架构决策、关键 API 定义、基础数据库模型确认。

主要任务： 快速确定技术选型和基础架构；定义核心模块间的关键 API 接口；设计满足核心功能的基础数据库表结构；界面设计可能采用标准模板或极简方案。省略详细设计文档，以关键图表和核心定义为主。

输出物： 简化的架构说明、核心 API 列表、基础 E-R 图/表结构定义。

开发阶段

时间区间： 第 4 天 - 第 8 天

关键里程碑： 核心 MVP 功能前后端代码实现、主要接口初步联调通过。

主要任务： 7 名开发人员高度并行开发各自负责的核心功能模块（前后端可能需要分组并行）；进行快速迭代和集成；开发过程中进行基本的开发者自测。代码审查可能简化或集中进行。

输出物： 核心 MVP 功能的可运行代码。

测试阶段

时间区间： 第 9 天 (可与开发阶段最后一天部分重叠)

关键里程碑： 核心功能冒烟测试通过、阻塞性 Bug 修复。

主要任务： 集中进行核心功能路径的快速测试和验证；主要关注阻塞性 Bug 和主要流程的可用性；性能、安全、完整兼容性测试将非常有限或省略。

输出物： 简要的 Bug 列表及修复状态、核心功能通过验证的确认。

上线部署阶段

时间区间： 第 10 天

关键里程碑： 系统部署到预生产/生产环境、小程序提交审核（注意：微信审核时间不可控，通常需要额外几天）。

主要任务： 快速将代码部署到服务器；进行基本的上线后检查；准备小程序提审材料并提交。用户培训和详细文档将省略或延后。

输出物： 已部署的系统、提交审核的小程序版本。

项目进度甘特图

说明： 在此时间表下，绘制的甘特图将显示出极高程度的并行性，尤其是在开发阶段。多个任务条会紧密重叠。由于资源（7人）相对固定，任务的并行主要体现在不同功能模块的同时开发上。

关键特征：

• 极短的需求和设计阶段。
• 开发阶段占据大部分时间，且内部任务高度并行。
• 测试阶段非常短，且与开发末期重叠。
• 部署阶段压缩到最短。

目的： 即使是示意性的甘特图，也能直观地展示出这个计划的紧迫性和高强度并行工作的特点。

重要风险提示

功能牺牲： 必须大幅削减原定功能，仅保留 MVP 核心。

质量风险： 测试时间严重不足，潜在 Bug 和稳定性问题风险高。

文档缺失： 几乎没有时间编写详细文档，对后期维护不利。

返工风险： 快速推进可能导致早期决策失误，后期返工成本高。

外部依赖： 微信审核时间、电力公司接口稳定性等外部因素会严重影响最终上线时间。

团队压力： 对团队成员的能力、经验和抗压能力要求极高。

强烈建议： 在启动前，务必与所有相关方就缩减后的功能范围、可接受的质量标准以及潜在风险达成一致。

八、项目风险评估与应对

识别项目实施过程中可能面临的各类风险：

技术风险

电力公司 API 不稳定或复杂性高：

(可能性：高，影响：高) - 获取核心用电数据和业务办理依赖外部接口，接口的稳定性、性能、文档清晰度、对接复杂度是重大技术风险点。

性能瓶颈：

(可能性：高，影响：高) - 在极度压缩的开发周期内，可能没有足够时间进行充分的性能测试和优化，导致在高并发或大数据量查询时出现响应缓慢甚至服务不可用。

前后端及外部接口集成困难：

(可能性：高，影响：高) - 时间紧迫，各部分并行开发，接口定义或实现上的微小偏差都可能导致集成阶段耗费大量时间调试。

技术选型或实现方案的短期决策失误：

(可能性：中，影响：高) - 为了赶进度可能采用不熟悉或不成熟的技术方案，或做出临时的、有缺陷的设计决策，留下技术债，影响长期维护和扩展。

微信平台 API/政策变更：

(可能性：中，影响：中/高) - 微信官方的 API 行为变更或审核政策调整可能影响小程序功能或上线流程。

技术风险应对

• 电力 API: 尽早（第 2-3 天）与电力公司接口进行联调测试，若无法联调则快速开发 Mock Server 模拟接口；设计时考虑接口异常处理和用户友好提示；若有联系渠道，保持沟通。
• 性能: 优先保障核心查询和展示功能的性能；采用成熟稳定的技术栈；上线后根据实际情况快速迭代优化。
• 集成: 明确并尽早（第 3 天）冻结核心 API 接口定义；加强前后端开发人员的日常沟通和代码集成频率（每日构建/集成）。
• 决策失误: 承认短期技术债，优先保证核心功能可用性；关键技术决策由经验丰富的成员快速拍板；对已知的设计缺陷做简要记录，纳入后续优化计划。
• 微信平台: 关注微信官方开发者社区公告；基于稳定版本的 API 开发；小程序提审前仔细核对最新的审核规范。

需求变更风险

MVP 范围界定不清或蔓延：

(可能性：高，影响：极高) - 在 2 周内完成，必须严格控制范围。任何对核心 MVP 范围的模糊理解或在开发过程中增加“小”功能，都可能导致项目延期或失败。

对核心需求理解偏差：

(可能性：中，影响：高) - 时间紧迫导致需求沟通不充分，开发出的功能与关键干系人的预期不符，需要返工。

需求变更风险应对

• 范围蔓延: 在项目启动时（第 1 天）即确定绝对核心的 MVP 功能列表，并获得关键干系人签字确认 “除此列表外，本次不上线任何其他功能”；指定项目负责人或产品经理作为唯一的需求变更入口，并坚决拒绝所有非阻塞性的变更请求，将其放入后续迭代计划。
• 理解偏差: 保持高频、简短的沟通，如每日站会和快速演示；鼓励开发人员在不确定时立即提问。

人力资源风险

团队成员倦怠或生病：

(可能性：高，影响：高) - 超高强度的工作压力显著增加成员 burnout 或因病缺勤的风险，7 人团队缺少任何一人都会对进度产生严重影响。

关键技能瓶颈：

(可能性：中，影响：高) - 特定模块（如复杂的前端交互、后端与电力接口对接）可能高度依赖个别成员的技能，若该成员遇到困难或缺勤，则对应模块受阻。

沟通效率低下或冲突：

(可能性：高，影响：中) - 高压环境下，沟通不畅、信息传递错误或团队内部摩擦的可能性增加。

关键人员依赖：

(可能性：中，影响：高) - 项目进度可能过度依赖某位核心开发或项目负责人。

人力资源风险应对

• 倦怠/生病: 设定切合实际（虽然仍极具挑战）的每日目标；项目负责人关注团队状态，鼓励适时休息（即使很短）；准备好在成员缺勤时快速调整任务分配的预案。
• 技能瓶颈: 鼓励结对编程或快速知识分享；识别关键任务，考虑安排备份人员或交叉培训（尽管时间有限）。
• 沟通: 每日固定简短站会；使用高效的即时通讯工具和任务看板；确保信息透明。
• 关键人员: 鼓励关键人员简要记录核心工作内容或配置，确保基础的可接手性。

外部因素风险

微信小程序审核延迟或被拒：

(可能性：高，影响：高) - 审核时长不可控，且可能因各种原因被拒（功能、内容、合规性等），直接影响最终上线时间。

电力公司接口临时变更或不可用：

(可能性：中，影响：高) - 外部接口的维护、升级或故障可能导致开发受阻或已上线功能中断。

服务器或网络环境问题：

(可能性：中，影响：中) - 开发、测试或生产环境出现故障。

外部因素风险应对

• 微信审核: 提前（第 8-9 天）准备好所有提审所需材料；了解常见拒绝原因并自查；设置合理的上线预期，告知干系人审核时间不可控。
• 电力接口: 实现对外部接口调用的熔断、降级和重试机制；缓存可行的数据以减少依赖；提供清晰的用户提示。
• 环境问题: 使用可靠的腾讯云服务提供商。