团队作业3——需求改进&系统设计

这个作业属于哪个课程	班级地址
这个作业要求在哪里	作业要求
这个作业的目标	需求改进&完成系统设计

一、需求&原型改进：

1.1针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改

1.1.1问题1（来自老师）：市面上有很多类似于购物系统的网站，你们团队这个项目突出的创新点在哪里呢？

我们进过综合考虑后创新性的将校园快递代取服务融入了我们的购物平台。

一、需求背景

随着线上购物的普及，快递收发成为校园生活的一部分。为了提高快递收发效率，减少学生排队取件的时间，我们计划在线上购物软件中集成“校园快递代取”功能。该功能旨在通过平台匹配愿意兼职的学生，为用户提供自由、便捷的快递代取服务。

二、功能实现

1. 认证机制：
   管理员将对具备代取能力的用户提供认证，只有通过认证的用户才能接单，帮助他人代取快递，以此预防潜在的失信行为
2. 发起订单：
   由用户·根据自己的需求，在我们的平台上发起快递代取服务请求
3. 接单：
   由经过认证的用户选择合适的订单，帮助别人代取快递，同时限制一次性代取快递的量，实现供需的合理对接
4. 确认完成：
   在用户确认收到快递后由发起者结束订单
5. 取消订单：
   用户在发起订单后，可能会因某些原因需要取消。如果订单已被接单，用户的信誉分将受到影响；若订单尚未被接单，则信誉分不受影响。
6. 押金制度
   每个接单的用户都得支付一定金额的押金，以督促用户遵守规则接单，服务好广大给顾客，实现“校园快递代取”功能的良性运作
7. 抽成
   用户花钱请人代取，订单我们抽5%，如果是打赏给那个人的话就不抽
8. 自动代取服务
   考虑到每次用户的快递到了都得用户逐一发起代取服务，我们设置一个自动代取服务选项，让用户判断要不要自动发起代取服务。当系统判断到用户的快递已经到了后，会自动发起快递代取招募，享受便捷的代取服务。（考虑到系统整体的开发，我们将在实现其他功能后着力开发此功能，提升我们系统的竞争力）

1.1.2问题2（来自其他组的建议）： 如何管理和更新订单的状态，以便用户和管理员及时了解订单的处理情况？

改进：可以设计一个订单状态管理系统，包括各种订单状态（如待处理、已发货、已完成、已取消等），并在订单流程中及时更新订单状态。同时，为用户和管理员提供订单状态查询功能，让他们随时了解订单的处理情况。另外，可以通过邮件、短信等方式向用户发送订单状态更新通知，提高用户体验。

1.1.3给目标用户展现原型，与目标用户进一步沟通理解需求。他们的痛点是什么？场景是什么？

• 我们的目标用户是在校大学生，在给他们展示我们的项目后，进行了积极有效的交流沟通，我们发现他们当中有些比较忙，空闲时间与取件时间由冲突；有些担心快递和外卖一样会被偷；有些人比较懒，讨厌每次都得开启代取服务，等等......
• 经过我们的调查，我们选择增加校园用户代取功能并加以完善来解决实际校园场景下用户的痛点、堵点，提高我们购物平台的服务质量，增强竞争力。
  

1.2修改完善上周提交的需求规格说明书

功能需求改进内容：

一、消费者端：

• 商品推荐系统：
  可以添加基于用户行为、历史购买记录等数据的个性化商品推荐功能，提升用户体验和购买转化率。
• 消息通知：
  可以增加订单状态变更、促销活动等消息通知功能，通过短信、后台推送等方式提醒用户。
• 代取圈服务：
  平台提供校园快递代取服务，通过认证机制确保代取用户可信：
  1.用户按需发起订单，认证用户接单并限制代取量以实现供需合理对接。
  2.订单完成后由发起者确认结束，取消订单将依据接单状态影响用户信誉分。
  3.接单用户需支付押金以保证服务质量，平台对订单抽成5%（打赏除外）。

二、商家端：

• 营销工具：
  为商家提供优惠卷、限时折扣等工具，帮助他们提升销售额。
• 店铺管理：
  让商家可以添加和删除店铺，并且把商品添加进店铺里售卖

三、系统管理端：

• 活动管理：
  增加平台活动管理功能，如限时抢购活动的创建、监控和管理。
• 代取圈管理：
  增加用户认证与审核、押金管理、信誉分管理、费用管理等规则，确保代取服务的有序进行。

User Story：
背景：小锋最近需要为即将到来的家庭聚会购买一些新的餐具和装饰品，他希望在一个可靠且方便的网上购物平台完成这次购物。
• 浏览商品与过滤筛选功能：小锋进入了网上商城的首页，他在分区选择了家居用品分类，然后进一步筛选餐具与装饰品类别，开始浏览不同价格与品牌的餐具与装饰品；
• 搜索商品功能：小锋看了许多款式后，将目标锁定于现代简约风格的餐具与装饰品，于是他在搜索框输入“现代简约餐具套装”和“现代简约装饰品”；
• 选择商品与购物车功能：几番比较过后，他将评分高的一套餐具与装饰品加入了购物车；
• 优惠促销功能：在购物车页面，小锋发现平台推出满300减50的满减优惠条件，于是又加了一些小饰品凑足了满减并进行了支付；
• 订单确认功能：小锋核对了订单的商品信息与收货地址，平台也会实时更新订单的情况，半小时后小锋收到了已发货的消息，完成了此次购物。
• 代取服务功能：小锋的快递到了之后，他在平台发起了代取订单，支付费用后，代取人按时将快递放到了小锋指定的地方，小锋确认无误后结束了代取订单，小锋支付的费用也到了代取人的账户。

1.3功能分析的四个象限

1.4修改后的WBS图及相应的项目进度计划

二、系统设计：

2.1在设计阶段，我们要清楚：软件是怎么解决这些需求的？

• 一个好的分层式结构，我们将系统架构分成前端界面层、后端服务层、数据存储层、中间件与基础设施层、可以使得开发人员的分工更加明确。其中最基础的部分之一为前端界面层，包括了消费者、管理者、商家三种用户的功能，可以使用HTML、CSS和JavaScript等前端技术构建用户友好的界面。再之就是后端服务层，后端层要和前端界面层实现稳定的交互，通过AJAX、Fetch API等技术实现前端与后端服务的异步通信。调用后端提供的API接口，处理后端返回的数据，并在前端界面上展示。
• 一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
  将需求分类、整理，区分功能需求、非功能需求、技术需求等，之后根据需求的紧急性、重要性以及实现的难易程度来确定各个需求的优先级，对于最为关键的功能先实现。
  其次是将大需求拆解成小任务或模块，确保每个模块都是可实现的，并且可以独立开发和测试，保证拆解后的需求具有清晰的功能边界和明确的技术实现路径，并对需求进行技术评估，确保所提出的需求能够在现有的技术架构上实现，或者需要做哪些技术上的调整。
• 如果遇到技术难题，可以考虑技术方案的替代选择或创新方案。

2.2如何才能最大限度地实现这些需求，这就是架构设计要解决的问题。请给出系统的架构设计

系统采用分布式微服务架构，将不同的业务逻辑分拆为独立服务模块，确保系统的灵活性和可扩展性。使用前后端分离的模式，以便前端页面与后端服务独立开发和部署。
架构图：

2.3完成团队项目的数据库设计，并在随笔中提供相应ER图

数据库表设计：(由于采用utf-8编码，所以单个汉字占用3个字节)
user用户

goods商品

orders订单

shop商铺

reviews评论

carts购物车

take_order代取单

logistics物流

ER图

2.4分析设计方法

2.4.1. 需求分析与可行性分析

• 收集需求：通过调研和分析收集用户需求，包括功能需求（用户管理、订单管理、商品展示、快递代取需求等）、非功能需求（如性能、安全性、可扩展性）、系统约束（预算、开发周期、团队技术能力等）。
• 需求分类和优先级：根据系统使用场景对需求进行分类，并设置优先级，为系统设计中各功能模块的重点设计提供依据。
• 可行性分析：考虑技术、资源和项目周期等因素，评估各需求的可行性，从而确定系统的整体设计方向和重点实现的模块。

2.4.2. 系统架构设计

• 架构模式选择：选择适合项目的架构模式，根据项目特点设计系统的总体框架。
• 模块划分：将系统划分为独立的功能模块，如用户模块、商品模块、订单模块、支付模块等。这样可以降低模块间的耦合度，提高系统的可维护性。
• 技术选型：确定系统开发的技术栈（前端框架、后端框架、数据库类型等）。

2.4.3. 数据库设计

• 数据模型设计：基于需求分析，确定数据实体（如用户、商品、订单等）及其属性。
• ER图设计：创建ER图以直观展示各实体及其关系，明确主键、外键和约束关系。
• 表结构设计：细化数据模型，设计数据库表的具体字段、数据类型和约束条件，确保表的逻辑完整性和合理性。
• 索引和优化：为高频查询字段添加索引，优化数据库结构，提升数据访问速度，尤其是查询频率高的表（如商品和订单表）。
• 数据安全与备份：设计数据备份和恢复策略，并设置数据权限控制，确保数据安全性。

2.4.4. 系统流程设计

• 用户操作流程：设计各功能模块的用户交互流程，如商品购买、支付、订单查询、评价等，确保用户在系统中的操作流程清晰、流畅。
• 业务逻辑设计：定义各模块的业务逻辑，如订单生成逻辑、商品库存更新逻辑，确保系统功能能有效地实现业务需求。

2.4.5. 性能设计

• 负载均衡：API 网关进行负载均衡，分发请求；同时采用Redis缓存热门数据，减少数据库读写负担。
• 消息队列：通过消息队列实现订单请求、快递代取订单的异步处理，提升响应速度和系统的扩展性。
• 监控日志：实时监控系统性能，分析日志数据，提前预警故障并进行数据回溯。

2.4.6. 测试设计

• 单元测试：对各模块、各函数单独进行测试，验证逻辑和数据处理的正确性。
• 集成测试：对模块之间的交互进行测试，确保数据流和业务逻辑在不同模块中有效执行。
• 压力测试：在开发环境下模拟高并发访问，评估系统在峰值流量下的响应能力，确保系统的性能和稳定性。

2.4.7. 系统部署设计

• 部署环境选择：根据预算选择服务器或云服务，并配置必要的资源。
• 监控与维护：部署系统监控工具（如Prometheus、Grafana），实时监控系统运行状态、负载情况和数据库状态，确保系统在运行中快速响应潜在问题。

三、Alpha任务分配计划

3.1依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项。(5分）

3.2对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。（5分）

3.3以甘特图的方式拟定迭代冲刺计划。（10分）

四、测试计划

测试不是在所有的开发工作完成之后才进行，而是与开发几乎同步进行的
测试计划和测试总纲主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责什么方面，各种资源在哪里，等等。

4.1 引言

4.1.1 测试计划基本信息

• 使用本测试计划的项目为线上购物系统，开发团队为Bug不打烊小队。
• 本测试计划的制定者：LGH、YZX。制定日期：2024/11/4-2024/11/7。
• 本测试计划的使用人员：团队全员。

4.1.2 项目背景

• 市场需求分析：随着互联网技术的快速发展和智能手机的普及，越来越多的消费者倾向于在线购物。电子商务市场规模持续增长，消费者对便捷、快速、个性化的购物体验需求增加。
• 技术支持：云计算、大数据、人工智能等技术的发展为线上购物平台提供了强大的技术支持。移动支付、物流跟踪、个性化推荐等技术的应用提高了购物的便利性和效率。
• 目标群体用户：有线上购物需求的群体，需要拓宽销路的商家，需要更个性化的购物平台的个人。
• 项目愿景和目标：建立一个安全可靠、服务全面的个性化线上购物平台，提供一站式购物解决方案，满足不同用户的需求，并实现商业价值和社会价值的双重目标。

4.2 测试范围

本测试计划主要测试系统的，具体如下：

4.3 测试目标

系统的所有功能可以正常使用，系统不存在明显的BUG，系统能够兼容主流设备，用户拥有流畅的使用体验。

4.4 测试方式

4.4.1 测试人员需求和分工

所有团队成员均参与测试，每个功能实现后所有团队成员都至少测试十次，每个成员使用的测试资源相同，在测试出问题后与其他成员讨论，并由负责对应部分开发的成员进行修复。

4.4.2 测试时间安排

测试覆盖整个Alpha阶段（即11、12周）。

4.4.3 测试策略

测试策略采用W模型，覆盖整个Alpha阶段（即从详细设计到交付的流程），具体如下：

项目的开发分模块进行，故测试内容也分模块进行。在所有模块开发并分模块测试完成后，集成所有功能，进行整个系统的使用测试优化，覆盖所有测试方面。

4.4.4 测试方法

采用黑盒测试和白盒测试相结合的方法。

• 黑盒测试，即把被测的软件看作是一个黑盒子，我们不关心盒子里面的结构如何，只关心软件的输入数据和输出结果。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
• 白盒测试，即把盒子打开，去研究里面的源代码和程序结果，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。主要运用单元测试的方法，确保每个模块的函数方法都能正常工作。

4.4.5 测试停止及恢复条件

• 停止条件：系统崩溃；系统响应时间超过15秒；程序运行结果出现错误。
• 恢复条件：程序可正常运行。

4.4.6 测试环境

4.4.7 测试资源

• 人力资源：所有团队成员均参与测试。
• 硬件资源：多台主流笔记本和主机。
• 软件资源：线上服务器、编程工具。
• 数据资源：提供测试用户进行多方面操作验证数据是否安全可靠收集。

4.5 风险评估

4.5.1 进度风险

4.5.2 技术风险

4.5.3 人力资源风险

4.5.4 运营风险（zjc）