需求&原型改进
1、给目标用户展现原型，与目标用户进一步沟通理解需求
用户的痛：四则运算是每个人都必须掌握的一项基础运算技能，特别是小学生在刚开始学习四则运算的时候，往往需要大量的四则运算题目练习，长期的巩固，才能让他们把四则运算掌握的更加牢固。四则运算练习的过程又是十分枯燥的，而小学生一般由于心智还未成熟，自制力都比较差，很容易无法坚持进行四则运算练习。所以，小学生和家长的痛点，主要在于如何让小学生能自愿进行四则运算练习甚至让他们迷上四则运算。
场景一（使用产品前的场景）：小明的妈妈从新华书店买来一本四则运算的练习题册，叫小明每天完成四则运算练习题册上的题目。由于练习十分枯燥，每天小明都十分不情愿甚至有时不听妈妈的话，没有完成今天的练习，拿起手机玩起了某手游,XX荣耀，体验到了练习册所不能给他带来的快乐，沉迷排位无法自拔，荒废了学习。
场景二（使用产品后的场景）：小明的妈妈从某朋友那得知我们的产品，让小明使用我们的产品进行四则运算练习，由于我们产品提供了丰富的模式选择，让小明感受到了练习的乐趣。由于有排行榜，小明的虚荣心促使他更加勤奋的在我们的平台上练习四则运算，既愉悦了身心，又提高了小明的四则运算水平，从此小明的妈妈再也不担心小明无法自觉地学习了。
与目标用户沟通：
我们把我们的原型设计发给了某小学生让他感受下有什么缺陷，发现他并不清楚等级上的初级、中级、高级是根据什么来划分的，不知道自己该对应哪个等级，所以我们把初级、中级、高级换成了一年级、二年级、三年级、四年级、五年级、六年级，这样目标用户就可以很直观的按照自己所在的年级来选择对应的难度进行练习。
2、修改完善上周提交的规格需求说明书
上次规格说明书不足的地方：用例图中角色只分为注册用户和未注册用户，没有更细的角色划分，没有教师角色对应的用例。类图中只有用户类，没有细分为教师类和学生类。功能和用户场景只分为注册用户和未注册用户，注册用户没有细分为教师用户和学生用户。
规格说明书具体改进的内容：
原来的用例图（左）和修改后的用例图（右）对比：
原来的类图（左）和修改后的类图（右）对比：
3、用户场景描述：
游客用户场景：
林同学是一名小学生，他由于数学成绩比较差，于是给自己定下每天练习四则运算的学习计划。他上网查看练习四则运算的网站，选择游客登录，网站上出现了题目，他回答完全部问题并提交了上去，网站上显示了他此次的答题成绩。
普通用户用户场景：
李同学是一名小学生，他由于数学成绩比较差，于是给自己定下每天练习四则运算的学习计划。他上网查看练习四则运算的网站，注册了一个账号，登录了进去，设置了个人信息。在主页面他选择了模式中的一种，并选择了难度，点击确定后进入测试，按照游戏规则完成游戏规则后，点击提交提交答案，网站上显示了自己此次答题的成绩和历史的记录。
老师用户用户场景：
李老师是一名小学老师，为了跟上时代的潮流给学生布置作业，于是他上网找到一个网站创建了一个班级，让学生们加入班级。老师点击生成作业，并设置作业信息（难度、数量），网站生成题目，李老师查看觉得可以，点击发布，选择班级，作业布置成功。第二天老师查看班级此次作业提交情况。
4.参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限
5、任务分解WBS
登录注册（吴桂元、黄进勇）：2天
修改密码（郑希彬）：0.5天
选择模式和难度（郑希彬）：0.5天
四则运算（何忠鹏、李勇）：5天
排行榜（黄进勇）：1天
个人信息修改（吴桂元）：0.5天
6、架构设计
7、数据库设计
8、Alpha任务分配计划
本组队员有五人，故将任务分为三个功能模块，一个前端模块，一个测试模块
模块一：教师模块（负责队员 何忠鹏）
B.信息统计 （测试学生姓名 年级 班级 正确率）
C.创建班级 (创建班级可以邀请学生加入)
模块二：做题模块（负责队员 黄进勇 何忠鹏）
1. 练习部分
A.选择等级：一年级、二年级、三年级、四年级、五年级、六年级
B.选择模式：限时模式、限量模式、无尽模式
2. 回顾部分
A. 错题记录
B. 成绩记录
C. 错题回顾（错题做对两次才能从错题库中剔除）
3. 累计积分
A.签到
B.答题
模块三：学生模块（负责队员 吴桂元）
1. 注册学生用户
2. 修改密码
模块四：前端模块（负责队员 李勇 郑希彬）
1. 网站页面布局
2. UI美化设计
模块五：测试部分（负责队员 吴桂元）
1.测试计划的编写及任务分配
2.总负责整个测试过程
9、测试计划
1. 项目背景： 本系统是一个针对小学生四则运算的测试系统
2.任务概述
2.1 测试目标： 希望通过测试，发现项目存在的漏洞，大家一起解决问题，完善整个系统。
2.2 测试范围：教师子系统
游客子系统
学生子系统
3.测试策略
3.1 测试方法：手动测试
3.2 测试人员需求、分工
|
人员 |
职责 |
|
吴桂元 |
组织测试 制定测试计划 需求审核 控制测试进度 与有关队员沟通 测试分析 |
|
李勇 |
组织测试培训 协助沟通 协助确定测试需求 协助准备测试数据 缺陷报告 |
|
吴桂元、黄进勇 |
测试学生子系统 |
|
郑希彬 |
测试游客子系统 |
|
何忠鹏 |
测试教师子系统 |
3.3 测试阶段计划
|
测试阶段 |
预计花费时间 |
测试人员 |
完成标志 |
|
测试计划设计 |
1天 |
吴桂元 |
计划完成 |
|
测试培训 |
1天 |
全体队员 |
掌握此次测试重点 |
|
学生模块部分 |
4天 |
吴桂元、黄进勇 |
实现题目的生成与判断正误 实现登陆验证 实现各个模式和难度 |
|
游客模块部分 |
2天 |
郑希彬 |
实现游客答题功能 |
|
教师模块测试 |
3天 |
何忠鹏 |
实现自主出题 实现查看学生信息 实现创建班级 |
|
缺陷报告 |
4天 |
李勇 |
完整记录系统缺陷及解决方法 报告缺陷 |
|
测试分析 |
1天 |
全体人员 |
完整分析测试中存在的问题 及整个系统存在的问题 |
4.资源需求
4.1 人员需求：要求六名队员掌握
本次测试的重点
每个子系统的功能
实际使用过程中哪部分问题较多
4.2 硬件需求：
笔记本电脑4台
4.3 软件需求：
Java开发环境
