福大软工 · 第七次作业 - 需求分析报告
"Jarvis For Chat"需求分析报告
团队项目的整体计划安排
项目logo及思维导图
项目logo
思维导图
个人贡献分分配
- 本着多干多得的原则，我们尽可能地降低基础绩效的占比，目的在于鼓励大家多参与软件开发的过程。不作为的队员在我们队伍里是得不到高分的。
- 定期分析团队成员的贡献情况，届时每个成员得到一个单次总分，待最终评分时，根据大家的总分按比例分饼。
- 单次总分上限为120分，其中特别贡献分额外计分，原则上不超过20分，如果做得真的特别特别好，可以考虑突破20分。
个人单次贡献表格如下：
| 待评分项 | 衡量指标 | 评分方式 | 项目占分 | 备注 |
|---|---|---|---|---|
| 基础绩效 | 固定分数 | 25 | 无 | |
| 工作时长 | 总工作时长 | 项目经理计算 | 40 | 参与了什么工作、工作的重要程度 |
| 工作质量 | 代码可用性、可靠性 | 团队互评得到 | 20 | 工作做得怎么样 |
| 参与协作程度 | 线上及线下议会出席情况 | 项目经理评估 | 15 | 一般情况下为满分，视具体情况扣除 |
| 特别贡献分 | 特殊贡献（范围不定） | 团队讨论得出 | 20 | 额外计分 |
| 总分 | 120 |
本次作业个人贡献分
现场得分及QA总结
| 第一组 | 第二组 | 第三组 | 第四组 | 第五组 | 第六组 | 本组 | 第八组 | 第九组 | |
|---|---|---|---|---|---|---|---|---|---|
| 本组对其评分 | 78 | 75 | 79 | 69 | 76.5 | 84 | 91 | 75 | 69 |
| 对本组的评分 | 80 | 79 | 84 | 74 | 72 | 74 | 91 | 84 | 85 |
本组的现场答辩得分：80.00
第一组提出的问题：
问：在这次答辩中并未进一步提及项目需求中说到的主要功能“聊天机器人”？
- 并非不开发，而是可能会推迟到项目后期才开发。我们以需求为导向，经过问卷形式的用户调研后，发现用户对聊天机器人的需求并不高，或者说重要程度没有热词分析、关键词提醒来得大。所以我们暂不开发聊天机器人功能，待热词分析、关键词提醒、个性化消息群发、单向好友删除功能完成后，再开发聊天机器人的功能。
问：如果热词筛选遗漏了某些群内热点，如何处理这些遗漏？
- 我们将使用NLP中的分词技术，提取出相关名词，经过相关筛选(主要是与热词库作匹配)后得出热点名词。这个过程中确实可能出现遗漏，不过出现的概率并不高；而且我们也会不断更新我们的热词库，尽量减少这种情况的出现。
问：对热词筛选算法是否指定相应的验收标准？
- 我们暂时还未对热词分析结果的内容做相关的验收标准。我们只能说尽可能选出热词。分析结果暂时无法给出很明确的保证。
第二组提出的问题：
问：是否可以排除掉一些用户们经常使用到的但是不是关键内容的词，比如牛逼。
- 完全可以考虑。我们将使用NLP中的分词技术，提取出相关名词，经过相关筛选(主要是与热词库作匹配)后得出热点名词。只需要在我们自己的热词库中剔除您所说的这部分内容即可。
问：打算如何恰当处理用户的隐私问题。
- 我们不会尝试获取用户隐私。而且从技术层面上我们确实获取不到用户的隐私，主要原因是登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，我们获取不到相关的信息。
问：团队获取利益的途径都有什么？
- 如果真的要获利，主要是通过会员版本的收费来获利。
第三组提出的问题：
问：你们对于数据的处理以及用户的信息有保障吗？
- 我们并不清楚该组所提出的的数据的处理是指哪一方面，追问后得知是有关隐私的问题。我们不会尝试获取用户隐私。而且从技术层面上我们确实获取不到用户的隐私，主要原因是登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，我们获取不到相关的信息。
问：在群发功能的使用上,是不是可以有更广的使用范围？
- 目前我们头脑风暴想到的情景主要是：1. 手机号变更了需要在QQ微信上通知大家 2. 节日祝福 3. 活动通知。之后我们还会继续我们的头脑风暴，尽可能想出更多的使用范围
问：团队的技术维持和可预盈利比是否是乐观的？
- 技术层面上我们目前还是比较忐忑的，因为是基于前辈开发的库进行开发，如果前辈开发的库并没有提供相关功能，我们的软件的部分功能就无法实现。至于可盈利性，我们不做出很乐观的估计。
第四组提出的问题：
注：该组在规定时间内未对我组提出任何问题，故不做回答。
第五组提出的问题：
问：你好，请问你们热词分析有没有考虑近义词的问题？
- 目前没有考虑，不过后期如果有需要的话我们会考虑加入。
问：你好，请问你们群发祝福的祝福语是如何来的？如果是手工书写，后期工作量会不会太大？如果是网上爬来的，如何使好友觉得这条祝福语不像是群发的？
- 首先可以在每个节日来临之际为用户提供部分节日祝福模板来供用户选择，这样做的工作量并不大。用户也可以自己从网上找相关的祝福语，简单修改（在合适的位置加入昵称）即可使用我们的功能。
问：你好，看你们的原型设计好像是电脑端风格?电脑很难保证随时开机，你们有没有考虑做手机端的产品
- 首先我们一直都是想在电脑端做产品。暂时没有考虑做手机端的产品，一方面我们是基于web端的qq和微信进行开发，登录时需要扫码，如果将产品部署在手机端又如何让手机自己扫自己呢（不是做不到只是有点麻烦）；另一方面我们还考虑到手机算力不足、续航不够长的问题。所以最终是想将它部署在电脑端的。另外我们可以考虑为用户提供略收费的服务器端7×24小时代挂机服务。
第六组提出的问题：
问：你好，请问对于关键字设置一个关键字搜索功能是否能够提供更好的用户体验？
- 感谢贵组宝贵的建议，我们在开发过程中会考虑加入。
问：你好，请问需求说明书中的群发对象只能选择群组，而实际群发时对象经常是qq中的好友分组，增加这一功能是否会好些？
- 我们始终都是再说让用户选择群发对象，而没有限定群发对象只能是群组呀，劳烦贵组再仔细看一遍相关部分的内容。
问：你好，请问这一软件设计到大量用户隐私，关于隐私保护是否能够很好的做出保证？
- 我们不会尝试获取用户隐私。而且从技术层面上我们确实获取不到用户的隐私，主要原因是登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，我们获取不到相关的信息。
第七组提出的问题（本组）
第八组提出的问题：
问：在PPT的展示中没有验收标准，简介概括一下
- 验收标准内容较多，就算放到PPT上也未必看得清，故本次并没有将它放入PPT。不过PPT里是放得下验收标准的概括的，我们下次注意改进！
问：利用备注群发祝福的功能，只能初步实现对于数字的删除等，对于后面正确的识别名字真的能实现吗？
- 我们会尽可能地提取出来。
问：安全性如何更好的保障？用户已经算是把最隐私的数据都透露给你们了。还有就是如何盈利？
- 我们不会尝试获取用户隐私。而且从技术层面上我们确实获取不到用户的隐私，主要原因是登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，我们获取不到相关信息。
- 盈利的话，我们不做出十分乐观的估计。
第九组提出的问题
注：该组在规定时间内未对我组提出任何问题，故不做回答。
各小组对我组提出的建议及我组改进总结
第一组：
建议：在下一步的开发中继续以用户的视角来提升产品功能的易用性与合理性
- 改进：会在项目开发过程中进行改进，需求报告中暂不更改。
第二组：
建议：排除掉一些经常用的并且不是用户需要获取的词
- 改进：我们会在做热词分析时建立一套热词库，这个热词库中会尽量的剔除那些“常用的但不重要的”词
第三组：
建议：建议拓展功能的面向群众
- 改进：感谢贵组的建议，但无法在需求报告中更改。
第四组：
建议：用户需求不局限在电脑端，建议可以向安卓端和IOS端拓展
- 改进：暂无面向安卓端、IOS端开发的意向，故无更改。首先我们一直都是想在电脑端做产品。暂时没有考虑做手机端的产品，一方面我们是基于web端的qq和微信进行开发，登录时需要扫码，如果将产品部署在手机端又如何让手机自己扫自己呢（不是做不到只是有点麻烦）；另一方面我们还考虑到手机算力不足、续航不够长的问题。所以最终是想将它部署在电脑端的。另外我们可以考虑为用户提供略收费的服务器端7×24小时代挂机服务。
第五组：
建议：切实用户需求，根据需求改进功能算法，用户的使用快捷方便体验友好应该在首位。
- 改进：我们一直都在也一直都会以用户的需求为导向呀。
第六组：
建议：根据用户实际需求改进功能
- 改进：我们一直都在也一直都会以用户的需求为导向呀。
建议：对关键字这一功能还可以继续优化
- 改进：暂时不明白贵组是建议优化关键词的哪一方面，我们会在项目进行过程中不断收集用户反馈来改进产品。
建议：思维导图可以更加细化
- 改进：由于制作的思维导图有点大，考虑到需求说明书里就算放了也看不清的问题我们没有放，并不是我们没有做更加细化的思维导图。如需要可以在本页面搜索思维导图。
第八组：
建议：单单根据备注然后智能群发消息可能稍微有点欠缺
- 改进：我们尽可能去做好就是啦(#.#)
第九组：
建议：建议多花一些篇幅介绍软件的安全的设计部分，这是可能是用户最为关心的部分。在获取聊天记录方面寻找一些可行的方法。在软件安全部分要多注意，可以将这部分作为主打的卖点之一。
- 改进：保护用户隐私是我们的底线，我们多次强调我们不会尝试获取用户隐私。而且从技术层面上我们确实获取不到用户的隐私，主要原因是登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，我们获取不到相关信息。因此在项目说明书中增加用户安全部分的描述。
《需求规格说明书》
-
修改之前的《需求规格说明书》
-
修改之后的《需求规格说明书》（红色的字为修改之处）
遇到的困难及解决方法
困难一
- 困难描述：Pad上手绘完成的视频通过QQ导给电脑时十分模糊的问题
- 做过哪些尝试：通过坚果云、U盘进行传输等
- 是否解决：解决
- 有何收获：不能拿QQ导出视频，否则会被压缩。
困难二
- 困难描述：核实wxpy、qqbot库时发现部分功能无法实现
- 做过哪些尝试：再次核实wxpy、itchat库
- 是否解决：无法解决
- 有何收获：站在巨人的肩膀上开发也是一件不容易的事情，巨人没去过的地方你怕是也去不了。
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 15 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 15 | 20 |
| Development | 开发 | 650 | 1130 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 90 |
| · Design Spec | · 生成设计文档 | 260 | 380 |
| · Design Review | · 设计复审 | 30 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 300 | 600 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 75 | 115 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 15 | 25 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60 | 90 |
| 合计 | 740 | 1265 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 200 | 200 | 5 | 5 | 巩固C++，了解单元测试和异常分析 |
| 2 | 100 | 300 | 5 | 10 | 学习主函数参数，文件流读取 |
| 3 | 0 | 300 | 3 | 13 | 学习《构建之法》和原型设计，process on制图 |
| 4 | 0 | 300 | 3 | 16 | 深入学习命令行测试，学习数据结构 |
| 5 | 350 | 650 | 10 | 26 | 改bug技能up，深入了解C++和调试技术 |
| 6 | 0 | 650 | 5 | 31 | 对需求分析进一步实践 |
| 7 | 0 | 650 | 5 | 36 | UML图的学习和操作 |
| 8 | 0 | 650 | 5 | 41 | 接口文档设计和数据字典设计 |
| 9 | 0 | 650 | 5 | 46 | 学习pyqt和wxpy |