实验八 团队作业4—基于原型的团队项目需求调研与分析
《Blue Flke》团队项目原型设计：http://www.cnblogs.com/ruanjgc/p/9007541.html
GitHub的链接地址：https://github.com/13993013291/ruanjianguigexuqiu/tree/master
任务1：实施团队项目软件用户调研活动。要求：
（1）真实的用户调研对象；
（2）利用实验七所开发的软件原型；
（3）要有除原型法之外的其他需求获取手段；
（4）收集用户需求调研活动的佐证材料（访谈录音、问卷、调研人员名单等等）。
1、调研对象：周围同学；
2、调研方法：主要是问卷调查，其次通过即时通讯工具访谈了其他同学；
3、问卷样本链接：https://www.wjx.cn/jq/1787408.aspx
4、问卷调查结果分析
通过调查发现，通讯录管理软件使用用户很多，使用手机自带的通讯录管理软件很少。调查用户年龄大部分在21~29，但是大部分人在抱怨通讯录管理软件占用的内存大。因此，对于我们团队开发的系统大部分人很感兴趣。有些用户给出了很好的建议，比如说他们希望比系统好用快捷的拨号盘，一目了然的好友名片，可对联系人进行分组，带头像的对话列表，有些女性用户希望有美观的界面。有些用户希望通讯录管理系统可以保存联系人的其他社交账号，例如QQ、微信等，在管理系统中可以直接打开好友对话框，而不用打开社交软件后在搜索好友。
通过调查用户需求，我们收集了很多的建议，这对于我们完善管理系统功能方面有很大的帮助。所以，我们在以后设计系统功能，完善系统功能有明确的指引方向，尽最大能力实现用户的需求，相信我们的通讯录管理系统有很多的用户。
任务2：采用UML模型描述任务1所获取的用户需求，请调研用户复查。
采用在线作图工具ProcessOn:如下图：
任务3：参考国标GB8567——88中《软件需求规格说明书》格式，撰写团队项目软件需求规格说明书，并将该文档上传到团队项目Github仓库。
1. 引言
1.1编写目的
编写本说明书的目的在于说明用户对《通讯录管理系统》的应用方法，描述《通讯录管理系统》的需求模型、功能和性能要求以及其他约定，以便用户能够很准确的需求以及操作，具体说明了软件的界面原型以及类图等，方便用户简易操作。
1.2 背景
该文档介绍的产品是通讯录管理系统，这个系统的适用对象是手机用户，这个软件解决了市场上的通讯录管理系统占用内存大的问题，方便用户管理联系人。
1.3 参考资料
1、系统软件需求规格说明书.pdf.zl5aqwp
2、软件设计详细说明书
2.任务概述
2.1 目标
- 信息记录：可以根据用户的需求记录和读取用户的通讯资料
- 提高效率：对联系人进行有效的管理
- 优点：占用内存小，容易操作，换手机时不用导入，可以直接登录获取联系人信息
- 可以直接跳转到社交APP进行通讯
2.2 用户特点
- 联系人数量大，且联系人信息量多
- 手机内存小，希望管理系统有简洁界面
2.3 假定和约束
假定：
1、用户对此系统比较认可，使用用户量大
2、易于维护，可以转接到大部分社交软件
约束：
1、目前我们尚无正规的编写过一个软件，经验少
2、相对团队来说，技术不是特别的成熟
3、时间相对不是很充裕
4、无资金支持
3.需求规定
3.1 对功能的规定
3.1.1 主要功能
通讯录的读取、通讯录的存储
3.1.2 功能描述（详细）
<1>通讯录的读取：要能实时且正确的读取通讯录文件的联系人信息。
<2>通讯录的存储：能够正确的按照用户的需求存储通讯录信息和及时更改和的通讯录信息。
<3>通讯录的排序：在正确读取通讯录的情况下，根据用户的要求对通讯录实现按姓名排序、按电话号码排序，从而能让用户更为方便的使用通讯录。
<4>删除联系人：在正确读取的情况下，根据用户的需求对通讯录中的联系人进行删除操作，然后从新更新通讯录文件。
<5>增加联系人：在正确读取通讯录的情况下，根据用户的要求对通讯录增加联系人，并及时更新通讯录文件
<6>编辑联系人：在正确读取通讯录的情况先，根据用户的要求对通讯录中的联系人进行编辑，然后对通讯录文件进行更新。
<7>加密通讯录：在读取的时候需要对通讯录进行密码验证，对于新建立的通讯录根据用户要求进行加密操作。
<8>转接到社交APP
3.1.3 用户界面
登录界面：
系统主界面：
添加联系人：
系统修改界面：
删除联系人：
系统登出界面：
4.运行环境规定
4.1 设备
硬件设备：手机；
软件设备：Android操作系统以及IOS操作系统
4.2 开发环境
Windows10 操作系统 java语言 eclipse
4.3 界面要求
<1>要求整体界面和谐美观，简洁大方
<2>要有菜单栏，能对整个通讯录进行一些相应的操作和错误处理
<3>对于一些基本操作的控件能在界面上列出来
4.4 其他需求
<1>可使用性：要求软件容易使用，适用于任意人群
<2>安全性：对于通讯录在拥有者不允许的情况下其他人不得访问他人的通讯录，保证通讯录的保密性。
5、验收总结
- N（need）：
现在的手机软件自身占据的内存很大，对于手机内存小的用户来说，需要一款不用占据很大内存的软件。
- A (approach)：
我们决定开发一款自身内存很小的，拥有基本的联系人增加、修改、删除、合并等功能的基于安卓系统的web版应用软件。
- B（benefit）：
对于手机内存很小的用户来说，可以很大程度上节省手机内存，可以创建桌面快捷方式，可以实现手机自带的通讯录的全部功能。
- C（competitors）
我们的初衷来自于我们自身使用的手机通讯录系统，该系统占据内存很大，且功能繁多，有很多不实用的功能，在很大程度上浪费了手机内存，但同时，也有很多此类的软件，很受用户青睐，在一定程度上，存在很大的竞争。
- D（delivery）：
我们会首先让一部分人使用我们的软件，然后根据反馈，做出相应的调整，然后再使用，再接着调整，直到没什么大问题之后，再通过啊传单、发说活的路劲进行宣传。
任务4：在团队博客发布博文，陈述团队项目的用户需求调研过程、需求调研方法与建模工具，需求调研结果、描述团队成员的具体分工及占整个需求文档任务的工作量比例，总结团队项目需求分析心得。
-
需求调研方法
问卷调查法
-
建模工具
UML模型
-
需求调研结果描述团队成员的具体分工及占整个需求文档任务的工作量比例
|
用户调研统计及解决问题 |
牛瑞鑫 |
15% |
|
总结及撰写博客 |
王胜海 |
15% |
|
需求调研建模及建立模型 |
邓英蓉 |
20% |
|
制作问卷调查及调查 |
马中林 |
15% |
|
软件原型设计 |
妥志福 |
15% |
|
用户需求分析规格说明书 |
董润园
|
20% |
总结团队项目需求分析心得
通过此次的问卷调查更加明确用户对软件需求的具体期望，收集了各方资料，为软件的继续开发提供了很大的帮助，并就一些很疑惑的问题得到答案，对软件的设计有了更大的自信心，这次主要应用UML模型工具，可以一一列举软件能实现的所有功能，初步判断再设计过程中可能遇到的困难，更系统的设计，总结各个模块的具体实现方法，通过这次实验，发现原型法在软件设计中的作用是巨大的，可以节约人力、物力等。总的来说这次调查为我们团队在接下来的工作中指明了更加明确的方案。
