需求&原型改进：
1.给目标用户展现原型，与目标用户进一步沟通理解需求。
a. 思考：他们的痛是什么？场景是什么？
我们在给周围两三个同学展示了我们的原型设计和构想，在课堂上展示过我们之前的需求分析以后，采访了同学们的感受：
问：你们觉得在学习中最大的困难、最大的痛是什么？
答：时间安排不合理，比较容易懈怠。
特别容易把事情，尤其是作业拖到最后，从而导致作业质量比较低，每次都是赶的、应付的。
问：在平时你们都怎么安排自己的时间呢？
答：除了上课时间，其他时间都比较零碎，很多时候是想到什么就做什么，比较少去特意安排。
是啊，尤其是上大学以后，有时候心血来潮做了计划，也容易忘记，就算写了计划也很难会按照原先计划去实现。
自身太容易拖拉了，很多事情明明有很多时间完成，但是总是放到最后才会去做，真希望有人能够激励或者监督我，才能改正我的懒惰啊。
问：你们是否有想过有什么辅助工具来帮助自己学习？
答：特别希望有，我希望有实用的app来帮助我学习，能够督促我，因为大学相对于高中来说太自由，自我约束又不够严。
我也用过一些app，例如超级课程表等，但是觉得还是不够实用，对于学习来说自我意识还是更重要，工具还是只能起到辅助作用。
辅助工具还是很必要的，还有激励，我希望在我学习的过程中能够不断地给我打鸡血，使我有所动力。
2.修改完善上周提交的需求规格说明书。
a. 上周的《需求规格说明书》初稿有哪些不足？特别是：功能考虑不全或需求文档描述缺少的地方。
不足：主要是需求分析功能模块描述的过于含糊和简单，光看“需求规格说明书”不能看出其需求，缺少吸引力
b. 改进内容:
3.2.2功能描述（概要）
正能量警句模块、登录与注册、个人学习任务提醒、显示和分享任务完成度
3.2.3功能描述（详细）
（1）正能量警句模块：用户在点击app时就出现一些正能量语句，系统内存储一些语句根据用户特点更换，例如对于勤奋的、任务完成度较好的用户给予继续支持、坚持不懈的语句，对于懒惰的、很少使用app来提醒自己学习的、任务完成度不好的用户给予一些警语
（2）用户登录、用户注册：用户通过登录的方式进行校验安全进入：用户注册是用户为进入该系统时将个人信息提交到数据库中。
（3）个人学习任务提醒：可自定义课程表，任务可以以导入和自定义输入的两种形式进行任务设置，设置任务的所需要提醒的时间、开始的时间、完成的时间。设置完成后，会在相应设置好的时间，跳出窗口，对用户进行提醒。窗口可让用户选择按规定时间完成任务或推迟完成。在任务完成时间到达时，跳出窗口，让用户选择是否已完成任务和任务完成度
（4）显示和分享任务完成度：用户在跳出的提醒窗口可以设置此次任务的完成度，并且可向第三方分享此次任务的完成度
c. 建议：用一个场景，像讲故事 （User Story）那样，描述用户怎么使用几个相联系的功能，解决了用户的问题。
3.2.4用户场景
用户点击启动app，会随机调取一条关于时间效率、学习管理、心灵鸡汤等正能量语句，该页面停留5秒，起到警示和激励用户的作用。然后进入登录界面，已注册的用户可直接通过账号密码进行登录，忘记密码的用户可点击“忘记密码？”跳转到用手机号验证找回密码的界面。没有账号的用户点击页面下方注册链接，跳转到注册账户界面，用户可设置其昵称，并默认其手机号为账号，自定义密码进行注册。登录完成后，用户进入课程表界面，可进行课程表的导入和自定义设置学习安排，并且可设置相应的提醒时间。待到相应提醒时间时，系统跳出学习提醒框，提醒用户相关的安排。除了提醒功能，用户还可自定义设置学习任务，根据实际情况将任务分配到课程表中，形成每日计划完成度，每次课程表中任务时间结束时，可根据情况输入实际的任务完成度。用户可以随时点击任务，查看相应任务的完成情况。
3.参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限。
4.任务分解WBS
a. 请给出团队项目的WBS；
b. 团队成员估计各自任务所需时间
团队成员这次的任务时间：
吴东益，负责Alpha任务分配计划，花费4个小时；
林晓芳，负责测试计划，花费3个小时；
郑莹，负责需求分析和改进软件需求说明书，花费8个小时；
陈惠：负责系统设计中的系统架构和数据库设计，花费7个小时；
张中结：负责功能性象限和WBS任务分配，花费3个小时。
系统设计：
在设计阶段，我们要清楚：软件是怎么解决这些需求的？
一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
1.如何才能最大限度地实现这些需求，这就是架构设计要解决的问题。请给出系统的架构设计
本系统主要采用的是MVC的设计模式
1) 视图（View） 视图层能够实现数据有目的的显示。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。
2) 控制器（Controller） 控制器起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。
3) 模型层（Model）：“数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。
2.完成团队项目的数据库设计，并在随笔中提供相应ER图（如果必要）
Alpha任务分配计划：
-
第一部分：以需求分析为主，选择和排序本次迭代需要实现的订单条目
（1）对市场上以及同学们提出的需求进行汇总，对系统进行设计和实施（吴东益）
（2）进行系统功能的实现：
1.编写用户注册系统（吴东益）
2.编写课程表导入系统（陈惠）
3.编写计划制定系统（林清青）
4.编写提醒系统（张中结）
5.编写前端界面（郑莹）
（3）对初步完成的系统进行测试与完善（林晓芳）
-
第二部分：以设计为主，确定系统设计方案和工作内容
（1）用户注册（通过昵称，手机号进行用户的注册）（吴东益）
（2）课程表导入（导入用户输入的安排）（陈惠）
（3）计划制定（根据用户导入的安排进行计划的制定和调整）（林清青）
（4）提醒系统（包括每日的鸡汤提醒，任务完成进度以及闹铃提醒等）（张中结）
（5）前段界面（尽量做到美观，简洁明了）（郑莹）
（6）整体测试及完善（保证用户使用的舒适度及实用性）（林晓芳）
测试计划
1.项目背景
为了解决学生惰性和时间安排上的不合理，提高学生的学习效率,特此推出个人学习计划提醒系统，包括课程表管理、提醒、日程安排等功能，以满足学生学习和生活的需要。
2.测试目的
此计划编写的目的是为使个人学习计划提醒系统能够达到与系统说明书所描述的功能一致，并且检验系统是否运行稳定。
3.测试范围
（1）软件的可用性
（2）功能的完整性
（3）数据的准确性
（4）系统的稳定性
（5）帮助等其他使用说明文件是否表达准确
4.测试安排与进度
|
测试任务 |
人员安排 |
时间估计 |
起始时间 |
|
各项功能的测试 |
林晓芳、张中结 |
3天 |
2017/5/9 |
|
完成所有模块的组合测试 |
林晓芳、张中结 |
2天 |
2017/5/14 |
|
确定各项数据都是准确的 |
林晓芳 |
1天 |
2017/5/16 |
|
将安装手册和用户帮助手册与软件操作比较是否有不符 |
张中结 |
1天 |
2017/5/19 |
|
安装、卸载是否顺利 |
张中结 |
1天 |
2017/5/20 |
|
系统稳定性测试 |
林晓芳、张中结 |
1天 |
2017/5/23 |
5.测试种类及测试标准
|
测试种类 |
测试标准 |
|
功能测试阶段 |
a.测试各个模块以及窗口所完成的功能是否准确，操作是否简洁方便 b.功能键是否描述准确、齐全，操作方便 c.界面是否设计简洁、符合用户需求 |
|
数据测试阶段 |
a.输入正确数据是否能按照预期的答案回显 b.是否能识别错误的输入数据，并给予正确的信息提示 |
|
安装手册帮助文件测试 |
a.帮助文档是否精确描述了如何使用各种使用功能 b.术语、菜单描述和系统响应是否与实际程序一致 c.是否能够根据文档方便地解决用户问题 |
|
安装卸载测试阶段 |
a.自动安装和手工配置安装是否都能安装成功 b.安装退出之后，确认应用程序可以正确启动、运行 c.卸载是否成功、彻底，是否把所有相关文件全部删除 |
|
系统稳定性测试 |
a.在几种常用的操作系统下是否能顺利运行 b.在与其他软件并行时是否运行正确。 |