福大软工 · 第七次做业 - 需求分析报告

写在前面

• 技术最强组的组长博客
• 不用看也知道的做业
• 男主女主颜值爆表的用户使用场景视频

组队后的团队项目的总体计划安排

咱们将工做流程分为前期、中期、后期来进行。

• 前期
  • 经过需求调研获取用户喜爱、需求；
  • 再借助“爬虫”、数据采集工具获取更多咱们产品所需信息；
  • 最后完成原型设计，中期与后期的软件开发流程也会依据此原型进行。
• 中期
  • 完成核心功能的算法实现；
  • 初步开发出美观、易用的界面；
  • 完成先后端、算法三者的链接，测试产品的运行效率、结果，造成一个完整的软件体系。
• 后期
  • 经过对软件的维护，不断迭代更新软件的内容而且修复潜在bug；
  • 在时间容许的前提下，实现产品的附加功能。

项目logo及思惟导图

• 项目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. 正文文本字体放大一号
2. 行距由1倍调整至1.5倍
3. 将文本内容设置为两端对齐
4. 调整段间距使各处段间距均匀。

需求报告最终版本

别看了，都散了吧

遇到的困难及解决方法

困难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	学会了简单的原型设计和写没人看的剧本