福大软工 · 第七次作业 - 需求分析报告
Foreword：
1.Plan
- 团队所有成员共同讨论各部分实现功能，共有5个功能，分别由5名成员负责各自的后端接口，2名同学负责前端界面，1名同学负责美工；
- 在11月8日前，美工组同学先完成界面主体设计，然后交由各参数于前端小组；
- 在11月8日——11月15日期间，前端小组根据美工小组同学的设计，完成前端的编程，与此同时，后端组自发讨论学习各自功能的实现算法；
- 在11月15日——11月20日期间，后端组完成各自的后端功能实现，并与前端接口相连接；
- 在11月20日——11月25日期间，团队成员组织探讨合并该项目，对于有缺陷或者未能实现的功能集中讨论，改善项目。
- 线上推广
- 在本院、校学生会以及各个班级组织推广免费使用
- 线下推广
- 与福建省其他高校一起推广使用，体验高效便捷的微信办公软件服务
- 另外，在办公区域，通过添加小程序等服务，赠送相关办公用品
2.Logo & Mind Mapping
Logo：
因为我们的项目名称是WeEdit，所以我们的LOGO象形E，即办公的意思，同时主体部分为共享的标志，符合我们项目的立意。另外，用交流符号“...”以及铅笔形象地结合，展现出我们的主推功能———“共享编辑”。底色设定为绿色，主要是为了契合微信的图标底色，我们竭尽全力地使这个小程序与微信进一步的贴切，减少用户的使用难度，方便使用。
Mind Mapping：
3.Individual Score
图中已经细分了各个成员在本次的团队实践任务中的具体工作分工，并以工作量的比例进行分数的评定，详细见图。本次的需求规格说明书具体参照了“GB-T 9385-2008，《计算机软件需求规格说明规范》”，以大纲为框架逐渐完善内部内容，后续经审核补充完成最终的文档。
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 18.575 |
| 蒋熊 | 8.675 |
| 黄志铭 | 7.775 |
| 黄毓明 | 14.975 |
| 林翔宇 | 16.775 |
| 丁水源 | 14.975 |
| 杨礼亮 | 16.775 |
| 陈超星 | 1.475 |
4.Review Form Design
5.Final Score & Problem Solving
Final Score：
| 小组 | 评分 |
|---|---|
| 第一组 | 82 |
| 第二组 | 77 |
| 第三组 | 77 |
| 第四组 | 87 |
| 第五组 | 63 |
| 第六组 | 82 |
| 第七组 | 79 |
| 第八组 | 76 |
| 第九组 | 90 |
| 最低分 | 63（第五组） |
| 最高分 | 90（第九组） |
| 有效分数 | 82，77，77，87，82，79，76 |
| 最终平均得分 | 80 |
Problem Solving：
之前提到过的关于格式上的问题已经全部进行了修改，包括页码、部分未处理好的文字阴影等。同时在内容上进行了大幅度的增加，包括重新绘制实体关系图，增加数据流图以及数据字典等
- 第一组的问题
Q1:在宣传中讲到应用的文档编辑倾向于“轻量化的编辑”，这与现有的移动端文档编辑应用相比有独到的竞争力吗？
A1: 我们主推微信群聊群体(尤其针对经常使用微信群聊进行办公的上班族、社团部门等)，简单编辑易上手和链式体验就是我们的竞争力。
Q2:产品比起之前的需求分析又增添了新功能，能否阐述一下产品的核心功能是？
A2: 我们的核心功能还是共享编辑。
Q3:是否对文档协同编辑时可能出现的问题制定相应的验收标准（比如文档在多端编辑时没有同步更新）
A3: 后期会制定一个标准，及时更新，谢谢。
- 第二组的问题
Q1:市面上有很多做的很成熟且使用很方便的竞品，其功能也很丰富，为什么客户要选择你们的？
A1: 首先，微信小程序便于使用和分享，其次捕获定位信息的功能能够方便用户们的使用而不同于其他软件的选取地点。
Q2:你们产品为小程序且介绍的功能较多，加上小程序本身有局限，能够真正实现你们所介绍的功能吗？
A2: 小程序开发内部提供有丰富的接口，就目前了解而言是可以实现的。
Q3:是否有考虑增加更佳新颖功能或界面设计更加突出来吸引用户使用？
A3:暂时没有，我们认为能使用户更加便捷快速的去熟悉使用就是我们产品推出的初衷。
- 第四组的问题
Q1:请问你们开发的产品相比于如腾讯文档这类多人实时在线编辑的软件，存在有哪些附加功能呢，还是仅是以微信小程序形式来实现？
A1:我们还有现场签到、发布通知等一系列功能，可以形成一个链式的关联整体使用。
Q2:微信小程序能实现的功能存在局限性，是否能有效完成该项目呢？
A2: 就目前而言是可以完成的。
Q3: 仅依赖于微信小程序是否显得拓展性不够，扩展成APP的形式是否会效果更好呢？
A3: 我们认为微信小程序本身以其简单便捷的优点会给产品带来更大的吸引力，拓展性方面会在可行的范围内，再进一步的去深入，尽可能的在完成既定规划的情形下去丰富拓展。
- 第五组的问题
Q1:既然是链式功能服务，有没有考虑做成app，可供多种社交账号进行登录使用？并且不同账号之间的文件可以共享编辑？
A1: 我们暂时主要是为了微信用户来考虑，因为从目前来看，微信这边市场需求比较大，办公人群居多。
Q2:文档编辑授权问题，发起人能否进行批量授权？
A2: 文档本身是以一种交互反馈的形式来共享编辑，因此批量授权的实现是在我们考虑范围中的。
Q3:现场签到的防止虚拟定位是否繁琐了点，能否有更加高效的签到方式？
A3: 目前为止这是我们想到的一个解决虚拟定位的方式之一，后续会再进一步去深入了解与学习，寻找更便捷一点的防范措施，感谢你们的建议。
- 第六组的问题
Q1:你好，请问1分钟的视频用来展示原型的操作时间过短，且没有声音，观看者很难看清楚具体功能，是否可以考虑采用截图置于PPT中由演讲者大致讲解功能模块？
A1: 视频的展示主要是为了引导用户的使用，达到一个过程式的介绍，关于时间过短(题目规定)以及无声(视频制作的不足)的问题我们是可以后续修改的，你们提出的建议可以接收，谢谢指出不足。
Q2:你好，请问签到功能是否能够解决代签问题？
A2: 我们在介绍中有提到，目前给出的一个解决方案是配合网络接入地址进行防止虚拟定位的问题，后续会进一步去了解使用其他更便捷的方法。
Q3:你好，请问PPT内容相对比较少，是否可以考虑丰富PPT内容? 如增加原型的界面截图。
A3: 本次的ppt主要介绍的主题均已经点出，已经满足基础性的要求，关于内容较少的问题，我们后续会注意的。
- 第七组的问题
Q1:你们提到签到的时候会限制IP或者WIFI，不知道这个方法的可行性有多高呢？是否可以给出一些例证来说明？
A1: 举例你到一定的地点使用上此IP，然后我对此进行判断后抉择签到授权问题，当你在其他的IP地址上签到时因为不满足要求则视为无效签到地址。可行性目前的了解是可以做到的。
Q2:”收集想法“这个功能和在朋友圈发一条消息或者在QQ空间发说说有什么差别？
A2: 不太能够理解你们提问的目的，但是作为本产品的一个辅助性功能，收集想法本身对使用群体没有多大的约束，它本身作为一种放松心态、随时发送随机回答的方式，满足工作闲暇之余的放松。
Q3:”共享编辑“这个功能是否有历史修改记录，能实现版本回退？如果回退到较早的一个版本，这个版本之后的改动是否会一直保存着，还说是在这次操作里还能保留，但退出本次操作后，那些版本就会被清空？
A3: 会考虑增设记录的保存，即可以退回使用，如果是愿意回退到上一个版本的话，自然该版本后的操作将视为失效不予记录。
- 第八组的问题
Q1:产品与其他同类型产品拉开距离的核心竞争力是什么？
A1: 我们使用微信小程序，依托微信潜在的巨大办公市场，能够给用户更便捷的办公体验。
Q2:对于协同编辑功能有没有考虑到在线用户数量会暴增，那会不会造成编辑的不稳定，有什么对策解决？
A2: 目前我们考虑的是小群体用户，即一个部门或者一个小团队的内部使用，针对于这个，我们后续也会考虑解决的，谢谢。
Q3:对于签到，为防止代签之类的问题，是不是会用gps定位功能，但若是组员没有开启这个功能，那这样不就有漏网之鱼了吗？
A3: 本身该功能就是为了精准签到设定的，所以对于使用者是有要求的，你所提到的问题不属于我们产品本身该考虑的问题。
- 第九组的问题
-
Q1:既然是多人编辑文档，以微信小程序实现的话，在手机端会不会不方便编辑文档？
A1: 我们会考虑尽可能的去使得用户满意并愿意使用我们的小程序，关于不方便操作的问题我们正在设法简约操作，谢谢你们给予的意见。
Q2:如果在电脑端实现，那么该产品跟目前以有的产品相比较，你觉得你们的优势在哪里？
A2: 可以进行配套使用，因为主打的群体面向微信用户，目前市面上的公司等等大型组织一般都更经常的使用微信，因此其存在的意义就是以其方便快捷来拉拢这些潜在的既有用户，拓展更多的新用户涌入。
Q3:微信小程序的编辑文档界面是否真的能方便用户的使用，有没有考虑调查一下用户的使用感受？
A3: 可以在后续进行若干次产品调研，提升使用质量。
6.Modifications to Those Problems
（说明：之前提到过的关于格式上的问题已经全部进行了修改，包括页码、部分未处理好的文字阴影等。同时在内容上进行了大幅度的增加，包括重新绘制实体关系图，增加数据流图以及数据字典等）
7.Difficulties & Gains
Difficulties：
1.一开始不知道该如何写“需求分析报告”，所以一开始还是比较懵的，知道后来队长找了一个例子给我们参考，我们才渐入佳境。
2.对例子文档的理解不透彻。如：第二章里的优先级以及设计场景之类的问题。
3.对于验收验证标准不了解。
4.对于视频的制作掌握不足，因此还是花费了一些时间来学习视频制作以及视频的美化。
Gains：
1.能与队友一起完成将近40页的“需求分析报告”是十分荣幸和有意思的事情，在这过程中我们不断的交流和探索，才能最终完成本次的实践任务，成就感十足~~
2.懂得了如何制作视频，更关键的是如何制作精美、有趣、有意境的视频，虽然本次的视频我没有参与制作，但是我还是自学了iMovie的的制作，十分有趣，我也想以此为契机，能够制作自己的vlog呀~~~嘻嘻~~十分兴奋能够开启自己的vloger之旅。能够记录生活是十分有趣的呢~
（Oops~~Sorry~~第二点有一点点离开话题啦。）
3.通过本次的实践，我更加熟悉了一款产品的形成过程，并不是简简单单的一上来就打代码，打到天昏地暗，前期的需求准备工作才是完成一款产品的关键，虽然不需要写代码，不过这份工作确实比写代码更艰难、更具挑战性的。因为我感受到它是一款产品的生命线的首端，只有做好了“开头”，我们的产品才能有优质的生命线，不是吗？嘻嘻(*^_^*)
8.PSP Table
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 940 | 1380 |
| · Analysis | · 需求分析 (包括学习新技术) | 20 | 30 |
| · Design Spec | · 生成设计文档 | 420 | 630 |
| · Design Review | · 设计复审 | 20 | 10 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 440 | 650 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 40 | 60 |
| Reporting | 报告 | 30 | 50 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 15 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 35 |
| 合计 | 1000 | 1460 |
9.Schedule：
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 500 | 500 | 15 | 15 | 学习VS2017，GitHub使用，复习C++相关知识 |
| 2 | 500 | 1000 | 20 | 35 | 阅读《构建之法》，从零开始学Java语言 |
| 3 | 1000 | 2000 | 15 | 50 | 阅读《构建之法》，学习Java，学习墨刀等工具使用 |
| 4 | 700 | 2700 | 35 | 85 | 复习C++知识，学习STL的使用。 |
| 5 | 300 | 3000 | 20 | 105 | 学习STL相关知识，以及使用VS，Process On 等工具 |
| 6 | 0 | 3000 | 35 | 140 | 学会如何设计软件的相关细节。 |
| 7 | 0 | 3000 | 30 | 170 | 学会如何写一份完整的“需求分析报告”。 |
