团队作业3--需求改进&系统设计
🚀 团队随笔：eSIM 在线售卖平台——需求迭代、设计深化与 Alpha 冲刺启动！
| 项目 | 详情 |
|---|---|
| 这个作业属于哪个课程 | 计科23级12班 |
| 这个作业要求在哪里 | 作业要求链接 |
| 这个作业的目标 | 对现有项目进行设计和需求&原型改进，进行Alpha任务分配 |
作者：e脉相传团队
发布时间：2025-11-19
标签：需求改进 / 系统设计 / Alpha计划 / 测试策略 / 项目迭代 / 课堂反馈
一、需求&原型改进
1.1 针对课堂讨论的修改
在上周课堂讨论中，老师针对我们的选题和需求提出了宝贵建议。我们认真梳理并进行了针对性修改，以提升项目的实用性和完整性。本次更新特别结合老师在提问环节指出的核心问题：运营商对接挑战和家庭功能打磨，进行针对性优化。
| 问题 | 修改 |
|---|---|
| 选题过于聚焦“出境旅客”，忽略了国内用户（如远程工作者）的潜在需求，可能导致用户基数受限。 | 扩展目标用户群，新增“国内远程办公/跨省出差用户”场景，支持国内漫游套餐（如中国大陆+港澳台），并在需求中添加“多区域切换”功能，确保平台覆盖全球+国内需求。 |
| 原型中“家庭共享子码”功能描述模糊，未说明子码生成上限和安全机制，易引发滥用风险。 | 明确子码上限为5张/订单，添加“子码激活追踪”机制（每个子码独立签名验证），更新到功能需求FR-O6，并强化安全需求中的“子码防转发”。 |
| 需求规格说明书中缺少对“库存管理”的详细描述，容易出现超卖风险。 | 在管理后台添加FR-A5：实时库存监控与警报（Redis扣减+阈值通知），并在验收标准中增加“库存超卖测试场景”。 |
| 最大的问题是如何与运营商对接？ | 我们的想法是先进行售卖这一块的工作、营销工作，让功能基本比较完善。如优先开发售卖核心闭环，使用模拟SM-DP+接口测试对接流程；新增营销模块FR-M1：促销码生成与应用（支持折扣活动），FR-M2：用户推荐系统（基于浏览历史推送套餐）。将真实运营商对接移至Beta阶段，先完善模拟环境下的售卖、支付、激活功能，确保MVP可用。 |
| 特色是家庭功能，具体是怎么体现？如何再打磨？ | 细化后台家庭共享功能，添加FR-A6：子码审批模拟接口（运营商端审核子码派发），并在设计中加强后台与SM-DP+的交互逻辑（如批量生成子码API）。前端保持二维码分享UI，后台增加日志追踪以打磨稳定性。 |
1.2 加分部分：目标用户调研与原型展示
为进一步理解需求，我们选取了3位目标用户（一位留学生、一位背包客、一位出差党）进行原型展示和访谈。使用Axure高保真原型演示“选套餐-支付-激活”流程，记录他们的痛点、场景，并对比使用前后变化。调研采用线上视频会议+问卷形式。
痛点与场景分析
参考《构建之法》第10章典型用户和场景，我们定义了典型用户画像：
| 用户 | 痛点 | 场景 |
|---|---|---|
| 留学生（小张，22岁） | 落地后办卡排队2小时，语言障碍；实体卡易丢失。 | 飞英国前，在机场用手机浏览平台，选30天英国套餐，支付宝支付，落地扫码激活，立即上网联系家人。 |
| 背包客（小李，28岁） | 多国旅行需多次买卡，切换麻烦；信号不稳。 | 东南亚4国游，一次下单多国套餐，平台自动生成切换二维码，边境过关时无缝上网。 |
| 出差党（小王，35岁） | 公司报销需发票；临时需求响应慢。 | 出差前快速购买，平台生成电子发票+订单行程单，激活后实时报销。 |
使用前后对比
- 使用前：用户需实体店买卡，耗时长、成本高；激活失败无退款，风险大。
- 使用后：3分钟内完成全流程，激活失败30s退款；家庭共享省钱省事。
调研过程：用户通过模拟操作，反馈“支付后二维码秒发，太方便！”。针对老师反馈，额外询问运营商对接痛点，用户表示“模拟激活已足够测试，真实对接可后期”。
1.3 修改完善上周需求规格说明书
上周《需求规格说明书》初稿不足：功能考虑不全（如缺少营销模块和子码审批）；描述缺少细节（如订单超时处理未量化、运营商对接模拟未明确）；非功能需求未覆盖国际化；验收标准缺少量化指标。针对老师反馈，新增运营商对接模拟细节和家庭功能后台打磨。
改进内容：
- 补充促销码和子码审批功能。
- 量化描述：订单锁定库存15min → 超时自动释放；运营商对接使用模拟API，真实接口预留扩展点。
- 添加法规合规细节：支持GDPR数据隐私，并强调营销合规（如无骚扰推送）。
- 用User Story描述核心场景：
User Story：作为留学生小张，我希望在起飞前购买eSIM套餐，以便落地即上网。 小张打开平台，游客模式浏览英国套餐（FR-T1），注册邮箱验证（FR-U1，60s冷却）。选30天套餐，下单锁定库存（FR-O1），应用促销码折扣（FR-M1），支付宝支付（FR-O2）。支付成功，平台调用模拟SM-DP+生成二维码PNG（FR-O3），下载链接有效24h。小张落地激活，若失败，系统定时扫描退款（FR-O4，30s内原路退回）。若家庭游，生成子码分享（FR-O6），后台审批模拟确保运营商兼容（FR-A6）。整个过程解决排队痛点，从浏览到激活<30s，先完善售卖营销再对接真实运营商。
完整更新版已上传仓库：需求规格说明书 v1.1。
1.4 功能分析的四个象限
参考《构建之法》5节功能的定位和优先级，我们将功能分为四个象限：
| 象限 | 描述 | 示例功能 |
|---|---|---|
| 杀手级（高优先、高差异） | 核心竞争力，独特卖点 | FR-O3：实时二维码生成 + FR-O4：激活失败自动退款 + FR-O6：家庭共享子码（后台打磨） |
| 外围级（低优先、低差异） | 基础支持，非核心 | FR-A3：订单CSV导出 |
| 必要级（高优先、低差异） | 必须有，但无差异 | FR-U1：注册/登录 + FR-O1：订单创建 + FR-M1：促销码（售卖营销） |
| 辅助级（低优先、高差异） | 锦上添花，可后期加 | FR-M2：用户推荐系统 + FR-A6：子码审批模拟 |
1.5 调整WBS及项目进度计划
根据修改需求，我们调整WBS：新增“营销模块开发”和“运营商模拟对接”任务，细分子码后台打磨子任务。进度计划使用Gantt图表示（详见Alpha计划部分）。总时长从原8周调整为9周，增加1周缓冲测试运营商模拟和家庭功能。
调整后WBS示例：
- 需求阶段：调研+文档（W9-10）
- 设计阶段：架构+数据库（W10-11）
- 开发阶段：核心模块+营销（W12-14）
- 测试阶段：集成+发布（W15）
二、系统设计
在设计阶段，我们明确软件如何解决需求：采用分层架构，确保分工明确、接口清晰。针对老师反馈，强化运营商对接模拟层和家庭功能后台逻辑。
2.1 整体架构概述
系统采用经典的分层架构，包括前端层、后端层、数据层、外部接口层和安全层。这种设计允许模块化开发，便于维护和扩展。具体而言：
- 前端层：基于Vue3的单页应用（SPA），负责用户交互和API调用。组件化设计，按模块分包（如OrderView、AdminDashboard、FamilyShareUI），确保UI响应迅速，支持游客浏览和买家订单管理。
- 后端层：Django REST API，实现无状态服务，支持水平扩展。核心服务包括UserService（用户管理）、OrderService（订单处理）、PaymentService（支付统一封装）、MarketingService（促销码管理）和OperatorSimService（模拟SM-DP+对接，预留真实API切换点）。
- 数据层：结合PostgreSQL（持久存储，如订单和套餐数据）和Redis（缓存和锁机制，如库存扣减、促销码验证），确保高并发场景下数据一致性。
- 外部接口层：集成SM-DP+模拟接口和支付沙箱，使用Celery处理异步任务（如二维码生成、退款处理和子码审批），减少主线程阻塞。
- 安全层：全程HTTPS加密，JWT认证，二维码和子码签名验证，以及退款接口幂等设计，防止重放攻击。
整体流程：客户端请求经API Gateway（Nginx）路由到Django Views，再调用相应Service处理业务逻辑，最终访问DB/Cache或外部API。优先使用模拟运营商接口，确保早期开发独立于真实对接。
2.2 关键组件详细设计
| 组件 | 描述 | 关键技术 |
|---|---|---|
| UserService | 处理用户注册、登录和个人中心数据展示 | JWT令牌、邮箱验证码（60s冷却） |
| OrderService | 订单创建、库存锁定（15min超时释放）和激活状态追踪 | Redis分布式锁、Celery异步回调 |
| PaymentService | 统一支付封装，支持沙箱测试 | 支付宝/微信SDK，幂等设计 |
| MarketingService | 促销码生成、应用和用户推荐 | 基于历史数据的简单算法，Redis缓存 |
| OperatorSimService | 模拟SM-DP+接口，用于二维码生成和子码审批 | RESTful模拟API，批量处理支持 |
| AdminDashboard | 后台管理，包括套餐CRUD、库存监控和销量图表 | Element-Plus UI，Echarts折线图 |
2.3 数据库设计与ER图
完成数据库设计，主表包括User、Package（套餐）、Order、QRCode、PromoCode（新增营销）。关系：User 1:N Order，Order 1:N QRCode（支持子码），Order N:1 PromoCode。
以下是ER图，展示实体及其关系：
此设计确保数据规范化，支持高效查询，如通过Order快速追踪子码激活状态。
三、Alpha任务分配计划
我们召开迭代计划会议（Zoom，2025-11-14），基于总时间（团队每周42h）、优先级（杀手级先）和依赖（支付依赖用户模块，运营商模拟优先），从Product Backlog选取功能项：FR-U1/U2（用户模块）、FR-O1/O2/O3/O6（订单+支付+家庭）、FR-A1/A2/A6（管理后台核心+子码审批）、FR-M1（营销促销码）。
3.1 选取功能项
选取项：用户注册/登录（高优先）、订单创建/支付/二维码生成/家庭共享（核心）、后台套餐CRUD+子码审批（必要）、促销码（售卖营销，先完善基本）。
3.2 Sprint Backlog与任务认领
分解为1-10h任务，在Leangoo看板管理。PM协助认领（更新新增营销和子码任务）：
| 任务 | 估时(h) | 认领人 | 依赖 |
|---|---|---|---|
| 实现邮箱注册+验证码 | 6 | 沈武钊 | 无 |
| JWT登录 | 8 | 陈俊源 | 用户表 |
| 订单创建+库存锁 | 5 | 张秉瀚 | 套餐表 |
| 支付统一服务（支付宝/微信） | 10 | 沈武钊 | 订单 |
| 二维码生成+模拟SM-DP+调用 | 7 | 郑东楷 | 支付 |
| 家庭共享子码生成+追踪 | 6 | 陈嘉煌 | 订单 |
| 后台登录+套餐CRUD+子码审批模拟 | 9 | 邱宇彦 | 用户 |
| 营销促销码生成与应用 | 5 | 崔乐浩 | 订单 |
| Redis集成库存扣减 | 4 | 崔乐浩 | 订单 |
以下是Sprint的燃尽图，展示实际剩余小时、预估剩余小时和完成小时的趋势：
以下是Alpha阶段从代码完成到发布的流程图，突出Bug修复循环：
3.3 甘特图迭代冲刺计划
Alpha阶段（W12-14，21天）：开发核心闭环+营销+家庭后台。以下是甘特图，左侧表格列出任务ID、名称、开始/结束日期和持续时间，右侧条形表示进度：
四、测试计划
测试与开发同步进行，总纲：产品为eSIM售卖平台，测试覆盖单元/集成/系统/ acceptance。时间：Alpha阶段每周测试日（周五），资源：pytest（后端）、Jest（前端）、Postman（API）、模拟设备（iOS/Android eSIM激活）。针对老师反馈，新增运营商模拟对接测试和家庭子码场景。
- 测试类型：功能测试（核心流程+营销+家庭）、性能（二维码<3s）、安全（JWT渗透+子码验证）、兼容（iOS12+/Android10+）。
- 责任分工：郑东楷负责安全/集成测试（含运营商模拟），邱宇彦数据/性能，崔乐浩自动化脚本（家庭子码）。
- 资源：沙箱环境、Docker测试容器、Leangoo缺陷跟踪。
- 时间安排：开发中每日单元测试，迭代末系统测试，目标覆盖率>80%。 参考《构建之法》测试章节，确保早发现早修复。
🚀 e脉相传，迭代前行。 感谢老师反馈，我们已针对运营商对接和家庭功能优化，继续精炼平台！欢迎反馈、Star、提Issue。
浙公网安备 33010602011771号