# 需求分析报告
前言
项目logo及思维导图
项目logo
- 项目Logo设计思路：我们的项目基于福州大学的各个食堂展开服务，所以我们的图标是一个抽象的碗，碗由字母“J”和“S”（即食的拼音缩写）组成，色调使用了相近的两种橙色，整个logo意在使得用户一看到我们的图标就联想到热闹的食堂并与我们的app名产生联系。
- 思维导图
组队后的团队项目的整体计划安排
| 阶段 | 主要任务 | 计划时间 | 内容 |
|---|---|---|---|
| 1 | 项目选题 | 2018.09.27-2018.10.12 | 确定选题，完成项目的市场调研和竞品分析，指定推广战略 |
| 2 | 需求分析 | 2018.10.20-2018.11.04 | 编写需求说明书 |
| 3 | 编码规范 | 2018.11.05-11.11 | 完成接口规定、编码规范、编码环境搭建 |
| 4 | Alpha冲刺 | 2018.11.11-2018.11.23 | 完成项目的核心功能开发、前后端对接 |
| 5 | 改进总结调整 | 2018.11.24-12.07 | 项目完善、用户试用反馈、测试计划改进 |
| 6 | Beta冲刺 | 2018.12.13-2018.12.21 | 完成附加功能的开发以及根据用户反馈改进 |
队员本次作业贡献比例
| 姓名 | 比例（%） | 完成工作 |
|---|---|---|
| 王彬 | 14 | 视频拍摄、界面原型设计、logo设计 |
| 赵畅 | 10 | 类图设计、Word汇总、思维导图汇总 |
| 李恒达 | 12 | 思维导图、视频拍摄、验收标准撰写 |
| 胡展瑞 | 12 | 验收标准撰写、PPT制作、视频制作 |
| 王源 | 12 | 类图设计、思维导图、食堂平面图设计 |
| 佘岳昕 | 10 | 验收标准撰写、思维导图 |
| 陈志炜 | 10 | 功能描述撰写、思维导图 |
| 陈文垚 | 10 | 引言编写、思维导图 |
| 林煌伟 | 10 | 类图设计、思维导图 |
撰写需求规格说明书的分工
答辩总结
小组得分
- 去掉一个最高分，去掉一个最低分，小组最终得分为77分
| 组号 | 组名 | 打分 |
|---|---|---|
| 1 | 爸爸饿了队 | 81 |
| 2 | 拖鞋旅游队 | 78 |
| 3 | 彳艮彳亍队 | 79 |
| 4 | 火箭少男100 | 76 |
| 5 | 起床一起肝活队 | 60 |
| 6 | 404 Note Found队 | 71 |
| 7 | 第三视角 | 78 |
| 8 | 小白吃 | 78 |
| 9 | 我头发呢队 | 79 |
问题汇总
第二组的提问：
- 问题1：用户一开始使用怎么能最快得知其口味喜好并进行正确的推荐，推荐的正确性如何保证？
- 答：我们的推荐是建立在用户使用软件的当时口味偏好进行推荐的，此外在软件开发初期，我们会积极尝试可能的算法来达到我们对推荐精确度的要求，初步调查后，随机森林、kNN等线性回归算法在我们的考虑范围内， 我们在项目计划书中，以及现场PPT展示中都明确阐述了我们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味。
- 问题2：关于推荐到菜品如果是自选类，能否进行正确的推荐且保证大部分自选都符合用户的口味？
- 答：在团队选题报告答辩中我们就回答过，自选窗口存在每日菜单变动的问题，这一客观局限使得我们并不打算向用户推荐自选档口的菜品，不过现在在考虑面对自选档口时只推荐档口的招牌菜的做法的可行性。
- 问题3：如何更大程度吸引用户选择你们的产品？
- 答：这个问题我们在团队选题报告的项目推广中已经有了全面且清晰的阐述。
第三组的提问：
- 问题1：每家店铺都有不同的菜品,如果需要细化菜品的话是否需要大量的调查
- 答：是的，将各家不同的菜品进行口味量化是我们的项目无法避免的一部分，也是推荐的可信度的保障，所以我们在项目初期已经对各个食堂的菜品进行录入与分析。
- 问题2：对于学生街以及食堂来说很多店铺都在不停的更换,如何及时的更新店铺数量,需要维护人员定期的调查吗
- 答：我们目前只针对福大的各个食堂展开我们的服务，按照经验来看，食堂大部分的店铺并不会进行频繁的菜品轮换，但对店铺及其菜品的维护也是需要定时进行
- 问题3：如何保证评价的可信程度,如果是别的商家恶意评论或者是水军好评该如何解决？
- 答：我们的用户评价更多的是用户对店铺的意见和建议，且我们也不打算提前开发产品的社交属性，在产品上线后得试运行期间我们会注意恶意差评得情况是否出现，并对此采取相应措施
第四组的提问：
- 问题1：请问推荐的准确性如何保证呢？仅采用简单的线性回归虽然效率高但是很难评估准确性。
- 答：我们在项目需求答辩中已经阐述了我们对推荐算法的验收标准，我们会在训练模型时努力达成我们的目标
- 问题2：产品的适用推荐范围是多大呢？
- 答：我们的推荐范围框定在福州大学各个食堂的非自选档口的菜品中，针对自选档口也可能会采取推荐档口特色菜品的方式。
- 问题3：产品是否存在定期的迭代规程？
- 答：感谢您的建议与提醒，我们已在项目需求计划书中补上这部分内容
第五组的提问：
- 问题1：有没有可能出现重复推荐了相同的店但是用户并不喜欢却无法屏蔽的现象？
- 答：我们在原型设计中就已经考虑到这个问题，当用户对当前的推荐不满意时用户可以要求程序给出其他推荐，二被否决的推荐在往后的推荐结果中的权重会相应减小
- 问题2：遇到多人出行不知道吃什么的时候这款软件还能适用嘛？
- 答：如何使用本款软件是用户的自由，我们会尽力保证应用本身功能的易用性
- 问题3：关于你们组的logo，与嘀嘀打车的有些相似（涂上色就差不多了），后期有考虑进行修改避嫌么
- 答：在我们看来两者差异十分明显
第六组的提问：
- 问题1：请问用户的口味细化你们打算怎么做到？
- 答：我们通过用户获取推荐菜品前做的4道与非选择题来获知用户当下的口味偏好，并作为我们推荐的依据
- 问题2：请问软件推广过程打算做出什么努力？
- 答：这部分我们在项目选题报告中的推广方式部分已经做出充分详细的阐述。
- 问题3：如何突显产品竞争优势吸引用户
- 答：我们的产品在一开始的定位就将目标人群设置为FZU在校大学生，将使用场景设定在大学食堂的范围，目标清晰，需求明确。市面上存在一些类似菜品推荐的小程序或APP，但它们的核心都是随机推荐菜名而没有综合考虑用户需求，也没有结合所在地区的商铺进行本地化。此外现阶段的类大众点评软件的应用理念和操作逻辑基本大同小异，都是根据用户的地理位置给出附近区域的餐厅推荐，但却没有进一步深入达到某一菜品级别的推荐。以上就是我们的软件的竞争优势。
第七组的提问：
- 问题1：请问”用户分析报告“中“总营业额”、“周客源数”、“支付笔数”你们要怎么获取？并不是使用你们的产品推荐菜品并且点击了”带我去“，或者评论了，就能确定他为这道菜品消费了啊
- 答：这是我们的产品原型对后期产品可能的产品形态的一种展望，为了达成这个目标，我们需要打通支付方式、食堂商家的中间道路，所以在产品开发初期，问题中提到的统计信息暂时无法上线，在先期的开发中我们会将精力主要集中在普通用户端的开发与推荐算法的完善，如果产品运行稳定再向我们的远期产品愿景努力。
- 问题2：请问你们怎们确保推荐的菜肴就是用户适合的？怎们确定及判定用户的口味及喜爱？
- 答：用户对推荐菜品是否满意是一个主观问题，我们所能做的就是尽量保证推荐算法的客观合理性。对用户口味的判定是通过用户每次获取推荐前的4道布尔选择题来获取的，之后我们的推荐算法会根据用户的选择推荐出最可能获得用户青睐的菜肴
- 问题3：请问你们怎们保证菜品推荐的真是可靠？菜品推荐应该是要基于大量的用户，请问你们前期推广打算怎么吸引用户？
- 答：我们推荐的菜品都是通过到食堂实地采集相应的数据并录入到我们的数据库中，所以推荐的菜品都是真实可靠的。关于产品推广，我们已经在之前的项目选题报告中的推广方式部分做出明确详细的阐述。
第八组的提问：
- 问题1：商家端管理是否需要配备硬件，还是说只要用手机就行？
- 答：商家端的应用会基于Web端提供服务，因为分析报告内容多样，采用Web端展示更方便用户浏览。
- 问题2：关于ppt的讲解，老师是建议说让上次没有参与的非pm的优先，为什么还是pm讲解的？
- 答：因为这次答辩是关于整个软件的整体方向的报告，PM参与了项目需求报告的撰写、PPT的制作、宣传视频的制作，对这次项目有更全面的认识，所以这次PPT演讲依然由PM承担，在之后深入到技术层面的演讲中会优先让其他组员承担演讲任务。
- 问题3：对于推荐算法的那一部分，要做到花费时间少和匹配相对准确，真的能有相对较好的平衡嘛？
- 答：算法的时间复杂度与其准确性之间并没有直接的关系，我们指定了相应的验收标准对我们的推荐算法的性能表现进行衡量，确保推荐算法的准确性和运行速度达到应用的要求。
第九组的提问（暂无）：
- 问题1：
- 答：
- 问题2：
- 答：
- 问题3：
- 答：
修改完善本组需求分析报告
- 新增推荐算法验收标准
- 新增对项目的可维护性要求
- 格式审查:去除首页的页码
《需求规格说明书》附件
评审表格设计
遇到的困难及解决办法
**
这次遇到的困难主要有两个：**
- 制作视频的IDEA
- 验收标准的撰写
**解决的办法： **
- 组长常年逛B站，提供了几个潮流的视频样本，以及自己边做视频边出现的想法
- 验收标准参考了国家的标准，以及学习了前面其他学长的经验
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 5 | 5 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 30 |
| · Design Spec | · 生成设计文档 | 35 | 50 |
| · Design Review | · 设计复审 | 12 | 15 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 15 | 15 |
| · Design | · 具体设计 | 15 | 15 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | ||
| · Test Repor | · 测试报告 | 30 | 60 |
| · Size Measurement | · 计算工作量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 5 | 5 |
| 合计 | 140 | 200 |
