团队作业2-《需求规格说明书》
随笔：星瀚餐递——校园轻量外卖平台
| 作业维度 | 具体内容 |
|---|---|
| 所属课程 | https://edu.cnblogs.com/campus/gdgy/Class12Grade23ComputerScience |
| 作业要求 | https://edu.cnblogs.com/campus/gdgy/Class12Grade23ComputerScience/homework/13471 |
| 团队名称 | CodeCrafters Duo（代码工匠双人组） |
| 团队成员 | 陈冠余（3123004175）、覃荣宏（3123004193） |
一、选题确定：核心定位与差异化
1.1 项目核心
星瀚餐递（Star Delivery）：校园专属轻量外卖Web平台，无需下载APP，浏览器直接使用，聚焦“15-30分钟校内配送”，解决校内点餐“沟通繁、时效慢、订单乱”痛点。
1.2 差异化设计
- 场景窄化：仅服务校园，商家自有人员配送，时效比校外外卖快50%；
- 操作极简：学生3步下单（选菜→填地址→支付），商家1步接单，无学习成本；
- 校园适配：学号注册验真，支持微信/支付宝（后续拓展校园卡），商家低门槛入驻。
1.3 目标用户获取
- 学生：班级群推广+前50名用户免费体验1单；
- 商家：线下对接5家校内热门小吃店，免费提供平台使用权。
二、需求规格说明书
2.1 面向用户分析
| 用户类型 | 核心痛点 | 核心需求 |
|---|---|---|
| 在校本科生（90%） | 校外外卖慢、微信接单沟通繁、状态不透明 | 快速下单、实时查进度、支付便捷 |
| 校内商家（8%） | 漏单错单多、统计耗时、改价通知难 | 高效接单、自动统计、菜品管理简 |
| 管理员（2%） | 审核繁琐、纠纷处理慢 | 快速审核、异常监控、投诉处理 |
2.2 功能性需块
学生端
| 模块 | 具体功能 | 优先级 |
|---|---|---|
| 浏览 | 商家列表（排序筛选）、菜品详情（图文+库存） | 高 |
| 登录注册 | 学号注册（手机验证）、账号登录（记住密码） | 高 |
| 下单 | 购物车（增删改）、地址管理、微信/支付宝支付 | 高 |
| 订单管理 | 订单列表（状态筛选）、实时追踪、状态通知 | 高/中 |
商家端
| 模块 | 具体功能 | 优先级 |
|---|---|---|
| 登录 | 专属账号登录、密码重置（管理员操作） | 高 |
| 菜品管理 | 新增/编辑/下架（批量操作）、库存设置 | 高 |
| 订单处理 | 实时提醒、接单/拒单/配送/完成操作、订单查询 | 高 |
| 数据统计 | 当日/本周订单量、销售额、热销排行（报表导出） | 中 |
管理员端
| 模块 | 具体功能 | 优先级 |
|---|---|---|
| 登录 | 超级账号登录、密码修改、登录日志 | 高 |
| 商家管理 | 入驻审核、信息编辑、账号禁用 | 高 |
| 订单监控 | 全平台订单查询、异常标记 | 中 |
| 系统设置 | 超时配置、支付渠道对接 | 中 |
2.3 技术需求
技术栈
- 前端：Vue.js + Element UI（响应式适配电脑/手机）；
- 后端：Java + Spring Boot + MyBatis + MySQL 8.0；
- 工具：Git+GitHub、Postman、墨刀。
核心规格
- 性能：页面加载≤3秒，并发500人在线，订单成功率≥99%；
- 安全：密码加密、权限控制、支付防重复；
- 兼容：支持Chrome/Edge/微信浏览器，分辨率≥720px。
三、预期用户数量
| 阶段 | 时间范围 | 学生用户 | 商家用户 | 管理员 |
|---|---|---|---|---|
| 初期（Alpha） | 1-3个月 | 300人 | 5家 | 2人 |
| 中期 | 4-6个月 | 900人 | 10家 | 2人 |
| 长期 | 1年 | 2000+人 | 20+家 | 3人 |
四、真实性·可用性·价值
4.1 真实性
需求源自校园实际痛点（访谈10名学生+3家商家），配送/支付流程贴合校内场景，可模拟真实运行。
4.2 可用性
核心流程无需培训，学生3分钟首单，商家10分钟上手，开发环境已搭建，Alpha阶段可实现闭环。
4.3 价值
- 学生：省时间、时效快、状态透明；
- 商家：降错率、省人力、拓渠道；
- 团队：落地全栈技术，积累项目经验。
五、Git协作管理
5.1 仓库链接
GitHub：https://github.com/Andyo0O0o/StarDelivery
5.2 协作规则
- 分支：main（稳定）、develop（开发）、feature/xxx（功能）、bugfix/xxx（修复）；
- 流程：Issue分配任务→按格式提交代码→PR审核合并→文档版本化管理。
5.3 Issues截图
六、团队计划与时间安排
6.1 原有安排
| 阶段 | 时间范围 | 核心任务 | 负责人 |
|---|---|---|---|
| 阶段一 | 第9周 | 组队选题、仓库搭建、初步需求分析 | 两人协作 |
| 阶段二 | 第10周 | 需求说明书、原型设计、开发环境搭建 | 陈冠余/覃荣宏 |
| 阶段三 | 第11周 | 原型优化、任务拆分、测试计划、接口设计 | 两人协作 |
| 阶段四 | 第12-13周 | Alpha开发、联调、冲刺博客 | 陈冠余/覃荣宏 |
| 阶段五 | 第14周 | 测试反馈、Bug修复、阶段总结 | 两人协作 |
| 阶段六 | 第15周 | 文档完善、版本迭代、项目总结 | 两人协作 |
6.2 校正后安排
| 阶段 | 时间范围 | 核心任务（新增/调整） | 负责人 |
|---|---|---|---|
| 阶段一 | 第9周 | 组队选题、仓库搭建、初步用户调研 | 两人协作 |
| 阶段二 | 第10周 | 需求说明书、原型设计、开发环境搭建、数据库设计 | 陈冠余/覃荣宏 |
| 阶段三 | 第11周 | 原型评审优化、Issue创建、测试计划、核心接口开发 | 两人协作 |
| 阶段四 | 第12-13周 | Alpha开发、联调（第13周启动）、冲刺博客 | 陈冠余/覃荣宏 |
| 阶段五 | 第14周 | 20人+2商家测试、Bug分类修复、阶段总结 | 两人协作 |
| 阶段六 | 第15周 | 文档完善、Tag标记（v1.0-alpha）、项目复盘 | 两人协作 |
6.3 矫正计算方法
采用“三点估算法”：期望工期=（最乐观时间+4×最可能时间+最悲观时间）÷6，结合双人团队特性，新增“用户调研”“数据库设计”等前置任务，细化联调与复盘环节，确保进度可控。
七、团队分工与进展
7.1 分工
| 成员 | 角色 | 核心职责 |
|---|---|---|
| 陈冠余 | PM+前端+测试 | 需求/原型/前端开发/测试用例/文档/博客 |
| 覃荣宏 | 后端+数据库 | 接口开发/数据库设计/支付对接/联调/Bug修复 |
7.2 完成情况
- 已完成：团队组建、选题确定、GitHub仓库搭建、开发环境配置、初步需求分析；
- 进行中：需求规格说明书撰写、原型设计、数据库表结构设计。
八、个人感想
陈冠余
“双人团队的高效在于沟通零成本，需求确认、问题解决都能快速推进。这次项目让我从PM视角统筹进度，同时深耕前端开发，深刻体会到‘需求落地’比‘功能堆砌’更重要，期待做出真正解决校园痛点的产品。”
覃荣宏
“聚焦校园窄场景让开发目标更清晰，后端核心是保障接口稳定与数据安全。通过对接支付渠道、设计数据库结构，我将课堂知识落地到实际场景，也学会了配合前端节奏调整开发优先级，团队协作让项目推进更高效。”
九、排版说明
全文采用Markdown标准格式，分章节层级清晰，表格统一对齐，关键信息突出，符合作业排版要求。