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

目录

• 快速了解
• 1. 需求&原型改进
  • 改进点呈现
• 2. 完善需求规格说明书
• 3. 系统设计改进
• 4. 任务分配计划
  • WEB任务分解
  • 项目进度计划
• 5.测试计划
  • 项目产品
  • 测试形式

快速了解

这个作业属于哪个课程	前往课程
这个作业要求在哪里	作业要求
这个作业的目标	根据进一步调查，进行需求改进&系统设计优化
Github	项目仓库

1. 需求&原型改进

改进点呈现

• 问题1：如何保证跑腿需求被顺利完成（即尽量避免接单者忘记了，或者临时放弃了）

  修改1：普通用户需要申请才能称为接单者(在这里做管理)，这里参考美团之类的大厂对外卖员的管理，需要对这些接单者进行有效的制约。

• 问题2：如何尽量保证时效性的需求尽快得到满足或回应，而不是让有需求的同学苦苦等待

  修改2：添加跑腿需求的标签（普通需求和紧急需求），并在一定程度上优先展示这类需求, 超过一定的时间额度没人接单，系统就得发布信息给该用户（并采取措施，比如派送这边的人去完成...），这样用户发布时就可以根据实际情况选择自己的这个服务需求的类型了。

目前调查用户的需求类型大概有如下两种：

姓名	小明
性别	男
专业	计科
用户需求、目的、困难	平时往返工作室，实验室，时间比较紧，还对于一些水课不感兴趣，但又迫于考勤
典型场景	需要一些服务

姓名	张三
性别	男
专业	电子信息
用户需求、目的、困难	家庭条件不是很好，平时课余时间比较多，但又没有比较好的渠道
典型场景	提供服务，获得报酬

2. 完善需求规格说明书

之前的需求报告还存在这一些问题，下面以场景的方式呈现：

​ 修改前：用户A是一个计科专业的同学，某天他突然有一些紧急的私事，第二天不能去上课，又没有正当理由请假。便第一次使用了FunCampus小程序，将他的代课需求编辑好，点击发送到上面去，不久，另一端的用户B看到了，觉得自己刚好可以做，便点击接单。这时系统便把这个消息（小程序端+短信）推送给了用户A，用户A点击确定后，这项服务交易就确定，但好巧不巧，到了第二天，用户B突然也有事，将A的需求抛之脑后了，结果，用户A忙完，却得知自己被记名了，平台将钱退回。于此，FunCampus便收到了差评，也失去了一个宝贵的用户！

​ 修改后：用户A是一个计科专业的同学，某天他突然有一些紧急的私事，第二天不能去上课，又没有正当理由请假。便打开第一次使用了FunCampus小程序，将他的代课需求编辑好，点击发送到上面去，不久，另一端的接单员B(普通用户申请成为接单员，参考美团外卖员进行有效的管理)看到了，觉得自己刚好可以有时间，便点击接单。这时系统便把这个消息（小程序端+短信）推送给了用户A，用户A点击确定后，这项服务交易就确定，但好巧不巧，到了第二天，接单员B突然也有事，于此，他告知后台（即我们这些管理者），我们立马采取措施派出其他接单者C（或者亲自上阵）, 顺利解决用户A的需求，将报酬发给C 有保证的服务，也使得FunCampus便收到了用户A的好评支持！耶，努力总会有回报的！

3. 系统设计改进

根据发现的不足和存在的问题，我们将系统设计进行了一些优化

系统功能架构设计

4. 任务分配计划

为了项目进度的顺利推进，我们召开了本次的会议讨论项目的相关内容

WEB任务分解

甘特图

项目进度计划

时间	具体任务	完成情况
第 9 周	1.团队组队、团队博客	✔
	2.团队介绍、成员展示、角色分配、选题确定	✔
	3.制定团队计划安排，团队贡献分的规定	✔
第10周	1.需求规格说明书	✔
	2.原型设计，队员估计任务难度并学习必要的技术	✔
	3.编码规范完成、平台环境搭建完成、初步架构搭建	✔
第11周	1.原型改进（给目标用户展现原型，并进一步理解需求）	✔
	2.架构设计，WBS, 团队成员估计各自任务所需时间	✔
	3.测试计划	✔
第12、13周	1. 团队项目Alpha任务分配计划
	2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交
第14周	1.用户反馈+测试计划改进
	2. 团队Alpha阶段个人总结
	3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理
第15周	1. 团队项目Alpha博客：事后分析

5.测试计划

项目产品

FunCampus一款面向广大大学生提供服务的小程序

测试形式

• 单元测试

• 接口测试

• json数据测试

• 模块测试

利用多种测试方式进行测试，测试用例尽量全面，保证程序的强健性，根据测试结果，编写测试报告，再提交至开发人员进行改进！