软件工程团队作业--需求分析成果物
队伍名称：洗衣做饭带孩子队
队长：郑欣 https://www.cnblogs.com/Cloria10086/
队员：魏思梦https://www.cnblogs.com/MiniDream/
邓好https://www.cnblogs.com/DengHao-123/
王艳静https://www.cnblogs.com/wangyanjing/
文本编辑者：全体组员
需求规格说明书
1.引言
1.1.编写目的
高校调查问卷管理系统的开发目的在于便于各高校甚至其他级别学校做各种问卷调查、投票以及这些问卷的填写信息、分析数据的管理，提供这样的平台既利于管理又利于信息的保护。本需求的编写目的在于研究高校调查问卷管理系统的开发途径和应对方法，为以后的开发工作提供可靠的依据；明确项目项目需求范围，实现需求描述的规格化、可跟踪性、可度量性和可测试性。在项目实施和项目交付验收过程中，均以该文档为唯一依据。
1.2.背景
1.2.1开发系统名称
本文档介绍的产品是高校调查问卷管理系统，该软件面向所有高校师生，甚至中小学，为其提供了更方便、简洁、安全且有趣的平台。方便用户在不同领域创建、填写问卷以及对问卷结果进行数据分析，便于达成调查目的、数据存储目的，利于后续工作的进行。
1.2.2项目的相关人员
1.用户：各高校师生
2.开发以及测试人员：郑欣、王艳静、邓好、魏思梦
3.文档编写人员：郑欣、王艳静、邓好、魏思梦
1.2.3该系统与其他项目的基本相互来往关系
该项目仍处于开发阶段，未知和困难都很多。该系统将基于安卓系统进行开发，成品可在安卓系统支持的手机和平板使用。后续可完善其使用平台以及网页版的开发使用，甚至用于常用的通讯软件中作为应用小程序使用。
1.2.4适用范围
1.新产品研发项目
2.新业务开发型项目
3.产品升级项目
4.产品维护项目
1.3.名词术语定义
表1.术语说明
| 术语、缩略语 | 解释 |
|---|---|
| Android/安卓 | 此两种说法为同一含义。由于本文档编写者不唯一，故而出现两种写法。 |
| MVP | 全称Model-View-Presenter,Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理. |
| MVC | 全名是Model View Controller，是模型model-视图view－控制器controller的缩写. |
1.4.参考资料
（1）朱爱民,柯建勋编著,PowerBuilder 9.0与系统开发,清华大学出版社,2003年11月第1版。
（2）陈建中，吕波编著.营销策划文案写作指要.中国经济出版社,2011.03。
2.项目概述
2.1.项目目标
1.宏观目标：
（1）该问卷调查系统需具有及时性、多样性以及低成本等基本特征；
（2）该问卷系统需要能与学校其他系统相结合使用，相辅相成；
（3）该问卷系统需要具有及时修改性，即在需求发生变化时可以进行随时修改以满足客户要求；
（4）该问卷系统需要具有简洁明了的用户界面；
2.微观目标：
（1）该问卷需要具有自定义问卷信息，例如：问卷名称、说明、收集填写信息项等；
（2）该问卷调查系统需要设置问卷表单权限，例如：限制填写次数，开放时间、设置问卷访问密码等；
（3）该问卷调查系统需要具有灵活表单组件，例如：单选题、多选题、简答叙述题、下拉以及支持附件上传等；
2.2.用户特点
1.流动性及不确定性强：高效问卷调查系统面对的用户群体具有极强的不确定性以及流动性，根据地域以及学校性质不同，各个高校对问卷调查系统的具体要求也不同；
2.主观性强：由于用户群体过于庞大，在设计问卷调查系统时不仅仅要从设计者角度出发，更多的要从使用者的角度出发，以完善设计；
3.可变性强：用户对软件的具体要求时刻变化。
2.3.假定与约束
1.建议开发软件运行的最短寿命2年；
2.使用限制仅限于各大高校；
3.建议开发软件投入使用的最长时间为3个月；
4.该软件设计过程严格按照相关法律规定及政策。
3.需求分析建模
3.1.功能需求
3.1.1.系统业务需求描述
此问卷系统的总体需求主要为设计问卷，问卷调查，创建问卷，设置问卷，发布问卷，填写问卷，提交问卷，数据导出，数据分析等。
通过前期的开发人员进行前期调研收集调研数据，并以此作为依据进行问卷系统的设计和提供给问卷创建者问卷类型的选择。问卷创建者通过创建问卷选择问卷类型并进行投票来进行对将收集的数据进行初始的分类划分，然后根据前期的调研数据设置相应问题并编辑选项，保存并发布问卷。问卷创建者创建问卷类型时可以通过手动创建和由平台模板自动创建两种方式。问卷填写者则通过提交填写问卷使数据收集平台收集问卷数据，并分析数据结果。
3.1.2.系统用例模型
该软件必须满足问卷设计，问卷调查，创建问卷，设置问卷，发布问卷，填写问卷，提交问卷，数据导出，数据分析等基本功能。
| 参与者 | 说明 |
|---|---|
| 开发人员 | 开发人员进行前期调研，调研数据，问卷系统设计等前期工作 |
| 问卷创建者（用户一） | 用户创建问卷，选择问卷类型，设置问题，保存问卷，发布问卷 |
| 问卷填写者（用户二） | 用户打开问卷，填写问卷，提交问卷 |
| 平台维护人员 | 平台维护人员进行模板导入，保存数据，分析数据 |
3.1.3.功能模块分析
系统用例模型：
用例模型详述：
| 标题 | 内容 |
|---|---|
| 用例名称 | 创建问卷 |
| 用例简要说明 | 发布者使用该问卷调查管理系统创建所需的问卷 |
| 前置条件 | 系统能够安全打开 |
| 事件流 | 设置问卷问题、设置问题选项 |
| 后置条件 | 问卷保存 |
| 扩展点 | 无 |
| 优先级 | 高 |
| 标题 | 内容 |
| 用例名称 | 保存问卷 |
| 用例简要说明 | 发布者使用该问卷调查管理系统创建所需的问卷后进行存档保存数据 |
| 前置条件 | 创建问卷 |
| 事件流 | 保存当前问卷 |
| 后置条件 | 发布问卷 |
| 扩展点 | 修改问卷 |
| 优先级 | 高 |
| 标题 | 内容 |
| 用例名称 | 发布问卷 |
| 用例简要说明 | 发布者将创建好的问卷发布出来 |
| 前置条件 | 创建并保存问卷 |
| 事件流 | 发布当前问卷 |
| 后置条件 | 统计问卷填写信息 |
| 扩展点 | 无 |
| 优先级 | 高 |
| 标题 | 内容 |
| 用例名称 | 提交问卷 |
| 用例简要说明 | 填写者打开发布者发布成功的问卷进行填写并提交 |
| 前置条件 | 发布者发布问卷问卷 |
| 事件流 | 上传填好的问卷 |
| 后置条件 | 系统进行填写的问卷信息统计 |
| 扩展点 | 填写问卷信息、修改信息 |
| 优先级 | 高 |
| 标题 | 内容 |
| 用例名称 | 统计问卷填写信息 |
| 用例简要说明 | 系统对提交的问卷进行信息统计 |
| 前置条件 | 填写者提交问卷 |
| 事件流 | 对问卷信息进行汇总统计分类 |
| 后置条件 | 统计好的数据反馈给发布者 |
| 扩展点 | 无 |
| 优先级 | 高 |
3.2.非功能需求
3.2.1.系统非功能需求
一、性能方面
1.响应时间
在大量用户打开问卷、填写问卷、提交问卷的时候，应使系统具备较高的响应要求，以给用户更好的使用体验。也防止出现系统涌入大量数据崩溃的情况。
2.用户数
用户数要考虑用户的增长情况，有以下指标：总用户数、峰值在线用户数、峰值并发用户数、平均在线用户数、平均并发用户数。
3.数据存储量
每年的数据存储容量（G）及未来几年该数量的预期（增长）值。指标包括累计存储容量（G）、年增长（G）。
二、系统可靠性
问卷业务使用应保证在规定时间内的任何时间都可以进行问卷的填写和保存。
三、可扩展性
可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。
3.2.2.特性要求
当出现大量用户需要使用系统的时候，响应时间中最长等待时间不要超过一分钟，以保证用户的系统使用体验；后台保存数据更新周期应为一天，即每天都会有新用户数据保存更新至系统后台；数据的转换和传送时间并无具体硬性需求，但应保持在一个稳定的水平，并尽可能快速而准确的传输数据。
3.2.3.故障处理要求
对出现的一些错误或者故障时需要采取的处理方法和手段进行描述。
1.当系统出现错误或故障时，优先采取本地解决的办法。
2.当本地无法解决故障时，向软件提供商，代理商或维保服务商提出技术支持申请，必要时进行跟踪处理，与技术人员一起到现场解决。
3.当故障严重并牵扯到用户利益时，在解决故障期间应给用户进行通知，并提前做好备份工作。
4.技术人员处理故障时，维护人员应全程陪同并积极协助，并在故障解决后进行书面确认。
5.故障解决后，维护人员应对故障的产生原因，解决方案填写详细记录，对以后出现类似问题提供参考方案。
6.对于系统隐患或暂时不能彻底解决的故障应纳入问题管理，每月对存在的问题进行跟踪分析。
3.3.其他专门要求
（1）进度要求：要求在第一阶段（5~6月）完成系统的设计和开发，在第二阶段（7月）完成系统的测试和完善，在第三阶段（8月）完成系统的投入使用和维护。
（2）安全性需求：要求系统可以稳定使用，并与用户签订协议不将数据外泄。
（3）培训需求：采用软件说明书和软件使用视频以及初次使用软件引导使用的方式对用户进行培训。
（4）推广需求：推广需求拥有较大用户使用量的软件进行宣传推广。
4.运行环境规定
4.1.基础架构
开发该问卷调查管理系统时选用MVP作为基础架构。MVP的全称为Model-View-Presenter，Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP从MVC演变而来，通过表示器将视图与模型巧妙地分开。在该模式中，视图通常由表示器初始化，它呈现用户界面（UI）并接受用户所发出命令，但不对用户的输入作任何逻辑处理，而仅仅是将用户输入转发给表示器。通常每一个视图对应一个表示器，但是也可能一个拥有较复杂业务逻辑的视图会对应多个表示器，每个表示器完成该视图的一部分业务处理工作，降低了单个表示器的复杂程度，一个表示器也能被多个有着相同业务需求的视图复用，增加单个表示器的复用度。表示器包含大多数表示逻辑，用以处理视图，与模型交互以获取或更新数据等。模型描述了系统的处理逻辑，模型对于表示器和视图一无所知。
4.2.支持软件
该系统将基于Android操作系统进行开发，成品可在Android操作系统支持的手机、平板电脑等电子设备上使用。Android是一种基于Linux内核（不包含GNU组件）的自由及开放源代码的操作系统。Android基于Linux 2.6 提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernenl也作为赢家和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。Android包含一个c/c++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架暴露给开发者。