第一部分 需求与原型改进
1.1改进的原型
1.1.1 高保真原型
1.1.2 高保真原型下载地址
原型地址：https://pan.baidu.com/s/1HKyu3tVNSbBVJi0URXlwbA
（用Axure RP打开后预览即可）
1.2改进的需求规格说明书
1.2.1改进说明
1.改进部分
2．开发目标
产品的开发是以需求为基准的，产品意在为东北师范大学在校生提供膳食推荐。其作用范围首先以东北师范大学净月校区为试点，基于东北师范大学净月校区的饮食服务系统，对于有着个性化的单个个体，提供其个性化的推荐服务。
本开发团队所有人均为东北师范大学2016级本科生，对于本校的本科生有着很好的了解。同时应用目标也就是我们十分熟悉的在校学生。所以有着一定的优势，可以更好地了解
根据我们的前期调研，超过七成的人愿意使用我们的产品，而89.38%的人愿意配合我们的服务，并提供评价以优化我们的服务措施。说明大家对我们的项目还是有着一定期许的额，使得我们拥有着很大的提升基础和进步空间。
同时，我们的产品还将为用户提供餐品的分类信息，用户可以通过选择分类，再由我们的产品进行推荐。经过用户一段时间的使用，使得我们了解用户喜好进行加权之后，我们可以为用户推荐更多更好地菜品。同时，我们也会根据用户选择的性格特点，您是希望尝试更多新的餐品，还是希望选择自己所习惯的几家店中选择都将会记录下来。
之后我们还计划在产品中添加推荐功能，通过对大量用户推荐的餐品进行整理，并将他们推荐给有着类似爱好的用户，这个属于产品的附加功能和长期规划，我们将先完成产品的基础功能后，对这些进行完善。
3．用户角色分析表
我们的用户主要为大学生，目前阶段更是仅针对东北师范大学的在校学生。通过调研中所得到的信息，我们绘制了用户角色分析表如上。
同时经过同学，也就是我们的潜在用户所给出的反馈信息，我们认为，界面尽可能的简单，清爽是我们产品的一个基本要求。之后尽可能少的让用户有较大的时间投入以及思维投入。同时我们决定用打星或者滑动的方式，优化用户体验。毕竟学生为我们的主要用户，而作为学生对复杂的操作也是很反感的。所以通过我们的用户分析，我们很好地找到了优化我们服务的方向。
4．验收验证标准
1、 主界面
清晰简洁，落落大方，可以清楚地提供给用户菜品信息以及检索条件，在用户选择推荐后，可以快速有效地推荐给用户今日菜肴，生去用户操作负担。
提供菜品分类信息，分不同口味，不同的就餐时间，以及不同的营养价值。方便用户的自主选择和限定条件推荐。
2、 产品推广
通过二维码推广，策划宣传，朋友圈转发推荐等方式，让我们的产品能够切实实现在用户身上，使得用户可以享受到便利，并同时通过加大样本数来推动更新推荐算法的合理性及普适性。
同时可以和食堂等校内相关部门取得合作，录入相关信息、给出相关推荐、也可以在食堂醒目位置设置易拉宝或者海报等内容，在适用的场合推荐我们的产品，达到事半功倍的效果。
2.缘由
经过调研，有什么用户提出了什么需求。所以做出了什么改进。
1.2.2需求规格说明书下载地址
https://pan.baidu.com/s/19NxkaVKRK84YYwlzXTHf5Q
第二部分 系统设计
2.1系统架构设计
2.1.1、文档概述:
A.项目背景
每顿吃什么是许多人日常困扰，这个问题对在校大学生而言尤其突出。
B.项目目标
解决在校大学生每顿饮食的选择困难症，帮助他们做出决定
C.文档版本信息
此版本为1.0
E.目标读者
在校大学生
F.参考文档
MySQL数据库设计规范：https://www.cnblogs.com/mjbrian/p/6841226.html
G.名词解释
2.1.2、整体架构：
主要从整个IT层描述系统所处的位置，与周边关联系统之间的调用关系。
A.Page Frame：Native预先加载一个WebView，当打开指定页面是，无需加载额外资源直接渲染，返回显示历史View，当退出小程序，View状态不销毁。
B.系统采用四层架构设计：
1、展现层
微信公众号/微信小程序——更新业务需要，将部分数据以微信公众号+H5的方式展现；涉及硬件设备控制功能的系统部分模块采用微信小程序，增加用户操作体验和访问便捷性。
2、通讯层
基于阿里云CDN实现静态数据加速；
基于阿里云SLB，实现服务器负载均衡；
基于HTTPS 通信方式，实现前后端数据通信。
3、服务层
核心业务基于Spring Cloud 架构实现微服务化。
Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
4、数据层
mysql：存储事务性数据，以及关联性将强的数据。
2.1.3、逻辑架构：
A.系统内部功能模块的划分
B.各模块功能介绍、相互之间的关系
2.1.4、数据架构：
A.本系统关键数据表设计
B.数据管理策略
引入Redux。
引入Redux的好处在于可以集中管理数据，并且让Page的代码保持绝对简单，让所有的组件都变成简单可复用的无状态组件。
此外，Redux还让离线缓存更方便，数据复用更简单。
2.1.5、技术架构：
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
数据库：Mysql
前端：，html、css、javascript
后台：java，采用MVC，Spring等轻量级的框架
2.1.6、部署架构：
后台代码部署到服务器，前端通过微信小程序开发者工具编写并部署
服务器采用阿里云，HTTPS
2.1.7、其他说明
A.特别约束条件
目前开发菜单以东北师范大学为蓝本，后期加入其它学校内容
2.2 任务分解WBS
2.2.1WBS详情
WBS就是Work Breakdown Structure，即分而治之。从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。
WBS要求：
1.保证所有子节点覆盖了全部父节点包含的内容。
我们整个项目包括两个界面——主界面和分界面“吃货轨迹”。所以树状图包括这两部分，并且将两个界面的所有功能都列出来了，并且对每个功能做了文字说明。所以说所有的子节点覆盖了父节点的内容。
2.保证各个子节点不要相互覆盖。
两个模块中的功能都是不一样的，所以说各个子节点都没有互相覆盖。
3.叶子节点要保证足够小，能在一个里程碑中完成。
两个模块的子节点功能都划分的很详细了，这也保证了叶子节点足够小。
4.从结果出发构建WBS，而不是从团队的活动出发。
我们这个项目就是要实现帮助用户选择“吃什么”，最后就是要做出原型的效果。所以说我们的WBS就是建立在此基础之上的，即从结果出发来构建的。
2.2.2WBS图像
我们小组做的项目是帮助大家更好地选择“吃什么”，根据我们设计的原型和调研后用户的需求，做出如下的WBS树状图来展示项目工作任务：
Leangoo工具做WBS：
2.2.3团队成员任务完成时间的估计：
-
- 曹滢：主要负责前端。5.28-6.3用一周的时间来学习微信小程序的知识（因为微信小程序主要涉及前端知识较多），6.4-6.17左右用两周左右的时间来做以及完善好界面，6.17-之后根据项目具体需求再进行调整和更改。
- 方慧琳：主要负责后端。5.28-6.10用两周时间来学习微信小程序的知识，6.10-6.24用两周左右的时间来做和完善好后台及数据，6.24-之后根据项目具体需求再进行调整和更改。
- 许征航：主要负责算法。5.28-6.10用两周时间来学习微信小程序的知识，6.10-6.24用两周左右的时间来配合方慧琳同学完善好后台的算法内容，6.24-之后根据项目具体需求再进行调整和更改。
- 王璐瑶：主要负责算法和完善需求。5.28-6.10用两周时间来学习微信小程序的知识，6.10-6.24用两周左右的时间来配合方慧琳同学和许征航同学完善好后台的算法内容，6.24-之后具体对项目进行需求的调整和更改，并将改进的需求与前后端同学进行协商。
- 王超超：主要负责整合。5.28-6.24学习微信小程序的知识，期间负责各种需求整合和资料查找整合工作。
第三部分 测试计划
3.1 引言
3.1.1项目背景
“人生每天三大问：早上吃什么，中午吃什么，晚上吃什么。”这句话在半个月前的朋友圈和空间着实火了一把，在我们身边，有这样一部分人，他们有着一定的选择困难症，不知道自己每顿饭应该吃什么。所以我们小组希望做出一个能够推荐每天饮食的小项目，用以记录用户的每日膳食并做出一种基于用户喜好的饮食推荐。
3.1.2参考资料（计划编写依据：可行性分析报告／软件需求定义／ 软件概要设计／软件详细设计／用户使用说明书／……）
用户需求调研报告
3.1.3有关项目人员组成以及联系方式（开发人员／版本控制人员／ 测试人员／软、硬、结构、营销人员等）
| 开发人员 |
项目组成员5人 |
| 测试人员 |
项目组成员5人 |
3.2.任务概述
3.2.1测试范围
功能测试 性能测试 安全测试
本系统测试方案测试主要根据用户需求说明书和软件需求规格说明书以及相应的文档进行系统测试，包括性能测试、功能模式测试、安全测试以及其他测试，而单元测试和集成测试由开发人员来执行。
3.2.2测试目标
接口测试：确保接口调用的正确性
集成测试：检测需求中业务流程，数据流的正确性
功能测试：确保测试的功能正常
用户界面测试：通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
性能测试：核实所指定的事务或业务功能在以下情况下的性能行为正常的预期工作量，预期的最繁重工作量
负载测试：核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间
容量测试：在一定数量的客户机长时间执行相同的业务功能
3.3.测试策略
3.3.1测试人员需求、分工
| 角色 |
具体职责 |
|
|
|
|
|
|
|
|
|
|
|
|
3.3.2测试方法（自动化测试／手动测试；白盒测试／黑盒测试；中断测试／临界测试／压力测试等）
自动化测试 手动测试 黑盒测试 压力测试
3.3.3工具引用及测试培训（内训／外训）
XTest
3.3.4测试阶段计划（工作内容、人员安排、起止时间等）
| 工作计划 |
开始时间 |
结束时间 |
人员安排 |
|
|
|
|
|
|
|
|
|
|
3.3.5测试停止及恢复条件
评估测试的执行状况进行适应性暂停
恢复暂停的测试
核实结果
调查意外结果
记录缺陷
对测试进行评估
评估测试用例覆盖
评估代码覆盖
分析缺陷
确定是否达到了测试完成标准与成功标准
核实结果后恢复测试
3.3.6测试文档及缺陷提交管理等
| 文档说明 |
作者 |
文档位置 |
|
|
|
|
3.3.7测试环境
微信平台
3.4．测试资源
3.4.1硬件资源需求
Windows 系统 PC机
3.4.2软件资源需求
微信自带测试平台
3.4.3测试环境需求
| 软件环境 |
| 硬件环境 |
3.4.4测试人员需求
| 角色 |
具体职责或注释 |
3.5．风险评估
3.5.1人力方面
人力人员相对不足
3.5.2时间方面
任务繁重，测试开发人员时间问题
3.5.3环境方面
测试环境微信自带平台，风险相对较小
3.5.4资源方面
网络资源约束
第四部分 团队合影
