福大软工 · 第七次作业 - 需求分析报告
写在前面
组队后的团队项目的整体计划安排
我们将工作流程分为前期、中期、后期来进行。
- 前期
- 通过需求调研获取用户喜好、需求；
- 再借助“爬虫”、数据采集工具获取更多我们产品所需信息；
- 最后完成原型设计，中期与后期的软件开发流程也会依据此原型进行。
- 中期
- 完成核心功能的算法实现；
- 初步开发出美观、易用的界面；
- 完成前后端、算法三者的连接，测试产品的运行效率、结果，形成一个完整的软件体系。
- 后期
- 通过对软件的维护，不断迭代更新软件的内容并且修复潜在bug；
- 在时间允许的前提下，实现产品的附加功能。
项目logo及思维导图
本次作业贡献度
| 队员 | 贡献度 |
|---|---|
| 林燊（组长） | 8% |
| 陈俞辛 | 11% |
| 朱志豪 | 11% |
| 蔡宇航 | 12% |
| 陈柏涛 | 12% |
| 董钧昊 | 12% |
| 刘宏岩 | 10% |
| 卢恺翔 | 12% |
| 杨喜源 | 12% |
| 总计 | 100% |
说明：
- 由于组长生病，本次安排了较少的任务，固贡献度较低。
- 编写软件需求规格说明书流程：
首先全体队员进行开会讨论明确撰写规范和具体分工，参考了《GB9385-2008 计算机软件需求规格说明规范》、本组商业计划书以及学长学姐的博客。然后分块撰写，具体分工如下：- 蔡宇航：引言、项目概述（功能描述）、需求分配
- 陈柏涛：类图、验收验证标准
- 卢凯翔：思维导图、问卷评估
- 需求报告撰写 —— 蔡宇航、陈柏涛、卢恺翔
- 答辩PPT制作 —— 刘宏岩
- 视频拍摄 —— 朱志豪、陈俞辛
- 原型设计 —— 杨喜源、朱志豪
- 博客撰写 —— 陈俞辛、董钧昊
- 上台答辩 —— 董钧昊
- 评审表统计 —— 陈柏涛、蔡宇航
- 项目logo —— 刘宏岩
- 思维导图 —— 卢恺翔
- 统筹 —— 林燊
评审表
答辩总结
评分
| 组号 | 给分 |
|---|---|
| 第一组 | 86 |
| 第二组 | 75 |
| 第三组 | 74 |
| 第四组 | 89 |
| 第五组 | 60 （???） |
| 第六组 | 77 |
| 第七组 | 69 |
| 第八组 | 78 |
| 第九组 | 89 |
平均分：78.29
提问释疑
第一组
- 问：如果店铺识别算法对某些店铺就是无法识别，是否考虑用其他方式来修复这一问题？
- 答：首先，若多次出现无法识别的店铺，我们有提供手动输入的形式完成信息查询；其次，我们会对提供申诉机制，用户可反馈未能正确识别的商铺位置，若是在我们规定使用范围的商圈内，我们会重新采集数据、应用迁移学习训练。
- 问：应用针对涵盖吃喝玩乐的各种店铺，是否有考虑对不同类型的店铺做一个分类，因为不同类型的店铺用户需要获取的信息也是不同的
- 答：首先这是一个很好的提议，但这项建议更多应用于给予GPS定位的周边推荐功能，我们的计划书中也简单叙述了这一点——根据用户希望检索到的信息提供周边同类型商铺的；而相对于AR扫描识别模块，我们有提供商铺类别信息的。
- 问：如果识别不正确，应用会以怎样的流程来完成后续的操作
- 答：若是返回错误结果，用户可通过重新换个角度扫一扫来实现识别功能；当然，用户也可通过申诉机制来向我们反馈信息，如第一问所述，我们也会做适当算法优化、调整。
第二组
- 问：你们在爬去评论或其他信息时能否保证准确性，或是否会在进行筛选，并非每个使用用户都会在你们产品上进行评论，你们自己累积用户信息周期是否需要很长时间？
- 答：相对于准确性是可以保证的，各大点评类网站也存在着筛选机制，我们自身也会设定筛选的机制；累计用户的信息的一个时间肯定是漫长的，但是每个软件的盈利周期也同样不是特别快的一件事情，我们也会提供一些优惠机制来鼓励用户点评。
- 问：你们产品需使用到较多且复杂的算法，是否能够全部实现你们介绍的功能，且能否保证算法的稳定和正确性？
- 答：可以全部实现，我们主要应用了目标检测以及文字识别两个模块的算法，足以实现本次的功能。我们也会适当扩充我们的数据集来尽可能保障结果正确性。
- 问：你们在吸引用户和累积用户评论信息上的周期是否会太长，这样的话能做到维持用户量和盈利吗？
- 答：软件开始盈利的周期都是十分长的，我们也会用一些优惠机制来鼓励用户点评商铺，用户量则需要我们进一步的推广，这一点在我们的商业计划书中有详细的描述，我们也会通过不断的迭代来完善我们的功能，以此来吸引更多用户。
第三组
- 问：店铺名称识别精度不低于95%感觉会有难度吧，比如怎么找到图里面哪里有字？怎么区别店铺名的字和其他不需要的字？怎么区别店铺名的字和边上颜色相近的灰尘？
- 答：由于我们需要识别的商铺，需在我们的数据库内，识别的难度将会大大降低，95%以上是可行的。
- 我们之前有做过相对于的训练、测试——首先我们按8:1:1分割数据集，再开始训练和测试。具体测试结果如下图所示(扩充样本指应用多种数据增强手段扩充训练集)
- 问：请问如果不注册可以直接用吗？因为我看你们的界面描述里只有注册和其他方式登录
- 答：我们是要求用户注册的，我们更希望以云平台的形式保存客户信息，也可依据客户的历史喜好来完成我们的推荐功能。
- 问：获得店铺信息应该比较简单，但店铺的用户信息和评论你们要如何获得？
- 答：我们可以通过“爬虫”来获取，不过用户的个人信息可能不是不是我们要获取的。我们仅收集我们的注册用户的信息。
第四组
第五组
- 问：你们的APP一开始需要大量的店铺数据，你们准备怎么收集这些数据，耗时会不会很长？
- 答：收集数据时间很快的，可以借助“爬虫”来完成，耗时很短的。而相对于数据采集，由于没有现成的数据，均需要实地拍摄，不过这部分的耗时也不会很长。
- 问：用户历史搜索的推荐要怎么更加精准？因为用户很可能只是搜索了店铺，但是并不感兴趣，这样会不会导致推荐的时候出现偏差？
- 答：我们会记录店铺停留时间的来判定用户是否感兴趣，不过个人认为搜索了店铺但是并不感兴趣这个问题本身就存在矛盾！
- 问：客服反馈这里，你们准备怎么做？要和众多商家达成共识，还要长时间在线，这个工作量是比较大的，你们有什么好的解决方法吗？
- 答：我们团队会设定专人轮流值班，也可以看到我们的原型设计上也有体现我们的
金牌客服。
第六组
- 问：你好，请问是否需要考虑不同用户之间的交互？
- 答：我们实现的内容就有包括信息分享的功能，具体可参见我们的商业计划书。
- 问：你好，请问是否需要考虑不同模式，以及不同模式下的推荐方案？例如设置心情，且不同心情的推荐是不同的。
- 答：设计不同心情来推荐是一个很好的提议，可能需要通过应用“情感分析”等手段来完成，实现难度略高，我们会考虑有时间实现。
- 问：你好，请问当用户在尝试app推荐的地点后，并不满意，该怎么做？
- 答：并不满意的话，用户可以选择给个差评，这样我们便会记录下信息以便于我们下一次推荐。不过推荐机制本身就存在着误推荐的可能性，是很难避免的，我们则更着重于后续的处理。
第七组
- 问：对店铺信息获取问题的补充：除了爬取数据和人工输入（个人感觉比较麻烦）这两个方法之外，是否考虑过制作一个专门提供给商家的版本，让商家自己填写相关信息？
- 答：首先，项目初期是很难完成与全部商家的协商的，当然拥有资金的供应也是可以完成的，但就实际一些来看，我们这个软工实践所需要做出的项目更多的数据获取方式难道不是“爬虫”+人工来解决吗？其次，我们实现的主要功能也是人工智能相关的，没有人工标注的数据集，我们是很难保证算法的可靠性的；最后，商家的版本这一点，我们更希望作为一个前景展望来做，这一点在我们的商业计划书中有所提及。
- 问：请问你们是否有考虑过产品做出来后店铺的覆盖率能达到什么程度？
- 答：我们初步考虑覆盖永嘉这一区域，后续的覆盖区域会随着产品规模逐步扩大。
- 问：请问你们原型图上的“今日推荐”里面的内容是以什么为标准来推荐的？真实有效吗？
- 答：以用户的历史喜好以及当前的定位结果来推荐的，真实有效！
第八组
- 问：对于刷赞或者刷评论这样的有什么措施解决吗？
- 答：我们也会考虑提供筛选功能来解决，此类问题解决难度较高。
- 问：有试验过在晚上或者在天气状况不太好的情况下，识别店铺的准确率嘛？
- 答：我们有通过神经风格迁移来扩充更多场景下的数据集，这样也可以提高我们的正确率，具体的试验还没有测试，但是两个模块也已经完成。
- 问：如何盈利？
- 答：可以通过广告等形式来完成盈利，具体规划可参见我们的商业计划书。
第九组
- 截至博客撰写（2018/11/4 15:30）尚未提问
需求报告修改之处
根据答辩中柯逍老师提出的建议，对需求规格说明书的格式做出了修改：
- 正文文本字体放大一号
- 行距由1倍调整至1.5倍
- 将文本内容设置为两端对齐
- 调整段间距使各处段间距均匀。
需求报告最终版本
遇到的困难及解决方法
困难1
- 困难描述
- 本次作业虽然由于校庆延后了一周，但是组内部分同学作为学生干部反而有更多的事情要做。正值学院的迎新晚会筹备中以及第九周我们开始了电气工程实践并且周六（11.3）是Linux操作系统实践课程的期末大作业提交时间，全组同学都忙的焦额烂头。尤其是原型设计组，志豪同学的事情更多。所以我们遇到的困难之一便是时间不够用。
- 做过哪些尝试
- 我们试着把自己当作一个“多核处理器”，合理的规划时间。并且在分工时， 部分事情较少的同学主动站了出来承担了任务。
- 是否解决
- 是
- 有何收获
- 增强了我们团队的凝聚力以及很好的推进了我们的贡献度分配原则（具体如何体现可以看我们的本次作业贡献度分配说明）
困难2
- 困难描述
- 本次作业要求完成一份需求分析报告，组内同学们都没有经验要如何撰写，开始时有些不知所措，无从下手。开了多次会都没能取得实质性的进展。
- 做过哪些尝试
- 我们认真阅读了作业中给出的 checklist，然后请教了之前的学长学姐其中包括曾经担任过这门课的助教。也阅读了一些前辈的报告，最终形成了一份框架，然后只需要将其填充就好了。
- 是否解决
- 是
- 有何收获
- 了解了一份完整的需求分析报告应该包括哪些内容。以及需求分析报告的目标人群是谁，文字应该如何组织才能够达到写这份报告的目的。
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 20 |
| Development | 开发 | 360 | 420 |
| · Analysis | · 需求分析 (包括学习新技术) | 40 | 10 |
| · Design Spec | · 生成设计文档 | 20 | 30 |
| · Design Review | · 设计复审 | 30 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 30 |
| · Design | · 具体设计 | 160 | 260 |
| · Coding | · 具体编码 | 40 | 10 |
| · Code Review | · 代码复审 | 30 | 50 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 30 | 20 |
| Reporting | 报告 | 85 | 130 |
| · Test Repor | · 测试报告 | 65 | 85 |
| · Size Measurement | · 计算工作量 | 10 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 25 |
| 合计 | 475 | 570 |
学习进度条
| 第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
|---|---|---|---|---|---|
| 1 | 300 | 300 | 15 | 15 | map 容器的性能瓶颈分析 |
| 2 | 0 | 300 | 8 | 23 | 完成基本功能的实现及附加功能的构思 |
| 3 | 200 | 500 | 8 | 31 | 学习 python 中与附加功能相关的库，例如 wordcloud |
| 4 | 0 | 500 | 5 | 36 | 学习了分而治之alpha版本事项和用例图的绘制 |
| 5 | 0 | 500 | 8 | 44 | 学会了简单的原型设计和写没人看的剧本 |
