福大软工 · 第七次作业——需求分析报告

Part 0. 开篇

WeEdit需求规格说明书
第三次软工实践答辩材料
一分钟演示视频
组长博客链接

Part 1. 计划安排

1. 团队所有成员共同讨论各部分实现功能，共有5个功能，分别由5名成员负责各自的后端接口，2名同学负责前端界面，1名同学负责美工；
2. 在11月8日前，美工组同学先完成界面主体设计，然后交由各参数于前端小组；
3. 在11月8日——11月15日期间，前端小组根据美工小组同学的设计，完成前端的编程，与此同时，后端组自发讨论学习各自功能的实现算法；
4. 在11月15日——11月20日期间，后端组完成各自的后端功能实现，并与前端接口相连接；
5. 在11月20日——11月25日期间，团队成员组织探讨合并该项目，对于有缺陷或者未能实现的功能集中讨论，改善项目。

• 线上推广
  • 在本院、校学生会以及各个班级组织推广免费使用
• 线下推广
  • 与福建省其他高校一起推广使用，体验高效便捷的微信办公软件服务
  • 另外，在办公区域，通过添加小程序等服务，赠送相关办公用品

• 线上推广

  • 在本院、校学生会以及各个班级组织推广免费使用

• 线下推广

  • 与福建省其他高校一起推广使用，体验高效便捷的微信办公软件服务
  • 另外，在办公区域，通过添加小程序等服务，赠送相关办公用品

  Part 2. 项目logo

  

因为我们的项目名称是WeEdit，所以我们的LOGO象形E，即办公的意思，另外，用“...”以及铅笔象形结合，展现出我们的主推功能“共享编辑”。底色的绿色的，主要是为了契合微信的图标底色，我们竭尽全力地使这个小程序与微信进一步的贴切，减少用户的使用难度，方便使用。

Part 3. 思维导图

•  

  Part 4. 团队中个人的贡献比例

  

   

  图中已经细分了各个成员在本次的团队实践任务中的具体工作分工，并以工作量的比例进行分数的评定，详细见图。本次的需求规格说明书具体参照了“GB-T 9385-2008，《计算机软件需求规格说明规范》”，以大纲为框架逐渐完善内部内容，后续经审核补充完成最终的文档。

  姓名	得分（百分制比例%）
  柯奇豪	18.575
  蒋熊	8.675
  黄志铭	7.775
  黄毓明	14.975
  林翔宇	16.775
  丁水源	14.975
  杨礼亮	16.775
  陈超星	1.475

• Part 5. 评审表格设计

  

  对其他组评分结果审表PDF版

• Part 6. 答辩总结

• 去除最高分（90）最低分（63）后的平均分：80

  • 第一组：82
  • 第二组：77
  • 第四组：87
  • 第五组：63
  • 第六组：82
  • 第七组：79
  • 第八组：69
  • 第九组：90

• 第一组的问题

  • Q1:在宣传中讲到应用的文档编辑倾向于“轻量化的编辑”，这与现有的移动端文档编辑应用相比有独到的竞争力吗？
    A1:我们主推微信群聊群体，简单编辑易上手就是我们的竞争力。
  • Q2:产品比起之前的需求分析又增添了新功能，能否阐述一下产品的核心功能是？
    A2:我们的核心功能还是共享编辑。
  • Q3:是否对文档协同编辑时可能出现的问题制定相应的验收标准（比如文档在多端编辑时没有同步更新）
    A3:后期会制定一个标准，及时更新，谢谢。

• 第二组的问题

  • Q1:市面上有很多做的很成熟且使用很方便的竞品，其功能也很丰富，为什么客户要选择你们的？
    A1:首先，微信小程序便于安装和分享，其次捕获定位信息的功能能够方便用户们的使用而不同于其他软件的选取地点。
  • Q2:你们产品为小程序且介绍的功能较多，加上小程序本身有局限，能够真正实现你们所介绍的功能吗？
    A2:可以的。
  • Q3:是否有考虑增加更佳新颖功能或界面设计更加突出来吸引用户使用？
    A3:没有，我们认为能使用户更加便捷地适应这个项目和使用就是我们的最初目的。

• 第四组的问题

  • Q1:请问你们开发的产品相比于如腾讯文档这类多人实时在线编辑的软件，存在有哪些附加功能呢，还是仅是以微信小程序形式来实现？
    A1:我们还有现场签到、发布通知等一系列附加功能的呀。
  • Q2:微信小程序能实现的功能存在局限性，是否能有效完成该项目呢？
    A2:目前看来是可以的。
  • Q3: 仅依赖于微信小程序是否显得拓展性不够，扩展成APP的形式是否会效果更好呢？
    A3:我们认为微信小程序更为简单便捷，而且其实目前微信的使用量似乎要远远超过其他的APP，因此我们认为这边比较有市场需求。

• 第五组的问题

  • Q1:既然是链式功能服务，有没有考虑做成app，可供多种社交账号进行登录使用？并且不同账号之间的文件可以共享编辑？
    A1:我们暂时主要是为了微信用户来考虑，因为从目前来看，微信这边市场需求比较大
  • Q2:文档编辑授权问题，发起人能否进行批量授权？
    A2:我们的初始授权是对于分享到的这一个群聊，即群聊里的人数都可以进行提供建议。
  • Q3:现场签到的防止虚拟定位是否繁琐了点，能否有更加高效的签到方式？
    A3:好的，感谢建议，我们会尽量实现。

• 第六组的问题

  • Q1:你好，请问1分钟的视频用来展示原型的操作时间过短，且没有声音，观看者很难看清楚具体功能，是否可以考虑采用截图置于PPT中由演讲者大致讲解功能模块？
    A1:好的，我们会考虑的，谢谢你。
  • Q2:你好，请问签到功能是否能够解决代签问题？
    A2:我们目前已经在考虑这方面内容，会尽能力解决的。
  • Q3:你好，请问PPT内容相对比较少，是否可以考虑丰富PPT内容? 如增加原型的界面截图。
    A3:嗯嗯好的。

• 第七组的问题

  • Q1:你们提到签到的时候会限制IP或者WIFI，不知道这个方法的可行性有多高呢？是否可以给出一些例证来说明？
    A1:就比如你到一定的地点使用上此IP，然后你才可以进行签到，你在其他IP地址上签到是无效的。
  • Q2:”收集想法“这个功能和在朋友圈发一条消息或者在QQ空间发说说有什么差别？
    A2:emm，你会一直在QQ空间或者朋友圈发动态吗？
  • Q3:”共享编辑“这个功能是否有历史修改记录，能实现版本回退？如果回退到较早的一个版本，这个版本之后的改动是否会一直保存着，还说是在这次操作里还能保留，但退出本次操作后，那些版本就会被清空？
    A3:会有记录保存着，即可以退回使用。

• 第八组的问题

  • Q1:产品与其他同类型产品拉开距离的核心竞争力是什么？
    A1:我们使用微信小程序，给用户更便捷的体验。
  • Q2:对于协同编辑功能有没有考虑到在线用户数量会暴增，那会不会造成编辑的不稳定，有什么对策解决？
    A2:目前我们考虑的是小群体用户，即一个部门或者一个小团队的内部使用，针对于这个，我们也会考虑解决的谢谢谢
  • Q3:对于签到，为防止代签之类的问题，是不是会用gps定位功能，但若是组员没有开启这个功能，那这样不就有漏网之鱼了吗？
    A3:可以根据他们的具体要求来选择是否开启，有时候人家也想水一点点呢？

• 第九组还未提问。

　　
• Q1:既然是多人编辑文档，以微信小程序实现的话，在手机端会不会不方便编辑文档？
  A1:我们会考虑尽可能的去使得用户满意并愿意使用我们的小程序，关于不方便操作的问题我们正在设法简约操作，谢谢你们给予的意见。
• Q2:如果在电脑端实现，那么该产品跟目前以有的产品相比较，你觉得你们的优势在哪里？
  A2:可以进行配套使用，因为主打的群体面向微信用户，目前市面上的公司等等大型组织一般都更经常的使用微信，因此其存在的意义就是以其方便快捷来拉拢这些潜在的既有用户，拓展更多的新用户涌入。
• Q3:微信小程序的编辑文档界面是否真的能方便用户的使用，有没有考虑调查一下用户的使用感受？
  A3:可以在后续进行若干次产品调研，提升使用质量。

• 【其他组提出的意见和建议】

• 第一组

  • 产品需求说明书的规格和视频的音频部分修改。

• 第二组

  • 考虑不在微信上也能使用，提高安全性和用户数据真实性。

• 第四组

  • 在视频展示环节增加更多创意元素

• 第五组

  • 签到功能应该要简单便捷且高效

• 第六组

  • 丰富ppt内容，ppt排版再优化一点

• 第七组

  • 加强文档撰写，共享编辑能否支持多样的文件形式。

• 第八组

  • 完善相关功能，保证能真正的在办公上实现高效。

• 第九组还未提问。

  • 　　更加方便的用户操作

Part 7. 软件需求规格说明书(有大幅度的丰富改动)

WeEdit需求规格说明书
修改了上次答辩过程中出现的问题和不足，并且增加了数据流图等内容。

Part 8. 遇到的困难及解决方法

• 困难描述

  • 对于签到系统的精准实时定位
  • 想法收集模块的创意性
  • 更便捷的分享
  • 界面美观

• 做过哪些尝试

  • 了解模拟定位软件的实现方式，希望能从这之中找到突破
  • 对于想法收集模块参照了当前几款做的比较好的软件，但我们想要与他们有些区别
  • 分享依旧保持链接分享，界面上稍作改善

• 是否解决

  • 定位我们打算采取IP或WIFI
  • 界面上有了一定改善

• 有何收获

  • 第一是了解到技术上的实现问题，清楚自己当前的技术实力和前进方向
  • 第二是对自己审美也是一种锻炼吧

 

Part 9. PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	5	5
· Estimate	· 估计这个任务需要多少时间	120	150
· Development	开发	10	10
· Analysis	· 需求分析 (包括学习新技术)	10	10
· Design Spec	· 生成设计文档	20	30
· Design Review	· 设计复审 (和同事审核设计文档)	20	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	50	80
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	0	0
· Reporting	报告	0	0
· Test Report	· 测试报告	0	0
· Size Measurement	· 计算工作量	0	0
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	5	15
	合计		160

Part 10. 学习进度条

第N周	新增代码	累计代码	本周学习时间	累计学习时间(小时)	重要成长
1	200	200	5	5	对Axure的学习
5	200	400	12	17	html,css的学习
7	400	800	7	24	学习C的函数、Xhtml的语法
7	100	900	7	24	微信web开发者工具的使用