|
学 院 |
计算机学院 |
|
专 业 |
计算机科学与技术 |
|
班 级 |
计科1705 |
|
学 号 |
173401010517 |
|
姓 名 |
王跃霖 |
|
指导教师 |
张翼飞，李哲洙 |
1. 引言
本章将从概述开发本系统的意图，编写本文档的用途和主要作用；概述描述项目开发的背景；将用户需求报告中的术语、缩写进行定义，包括用户应用领域和计算机领域的术语与缩写等方面入手，对其进行简单的描述，旨在让预期读者——负责人、教师、学生读懂。
1.1. 编写目的
计算机技术高度发达地今天，利用信息技术对大量复杂的信息进行有效的统计成为一种普遍而实用的手段。一方面，这极大的减少了簿记和人力的开销，另一方面，现代计算机强大的计算能力和网络的普遍部署，大大简化了大量信息的处理和流动。高校问卷系统是统计学生信息的一个简单便捷的方法，他对教师的工作效率有很大的提高，它不但可以降低对纸质问卷的要求，同时也体现了节约型社会的要求。
该系统设计了问卷填写，发布，以及很多相关信息的综合处理。对于问卷发布者，该系统可以自主便捷的进行创建，编辑和发布等功能，同时可对账号进行锁定，仅允许一个账号提交一次问卷，达到防止恶意刷卷的现象；对于问卷填写者，该系统可以让其看到自己有哪些需要填写的问卷，以及问卷的截止日期和自己已填过的问卷。
编写此文档的目的是进一步定制软件开发的细节问题，希望能使本软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对该软件的初始规定有一个共同的理解，它说明了本软件的各项功能需求、性能需求和数据需求，明确标志各项功能的具体含义，阐述实用背景及范围，提供客户解决问题或达到目标所需要的条件或权能，提供一个度量和遵循的基准。具体而言，编写软件需求说明的目的是为所开发的软件提出：
- 软件设计总体要求，作为软件开发人员、软件测试人员相互了解的基础。
- 功能、性能要求，数据结构和采集要求，重要的接口要求，作为软件设计人员进行概要设计的依据。
- 软件确认测试的依据。
1.2. 背景
将要开发的软件名为《高校调查问卷管理系统》，本项目的提出者是张翼飞，李哲洙老师，而本团队的开发者是17级沈阳航空航天大学计算机科学与技术班级，主要用户是教师、大学本科生、研究生。基于现在各大高校每天充斥大量的问卷，无论是学生还是教师都厌烦不已，而且还容易出现纰漏，所以创建此软件，该软件独立于其他系统，自成一个完整的系统，应用方便。
1.3. 名词术语定义
对用户需求报告中的术语、缩写进行定义，包括用户应用领域和计算机领域的术语与缩写等请看表1。
表1. 术语说明
|
术语、缩略语 |
解释 |
|
H5,C3,JS,java,MySQL/MongoDB |
H5为html 5，C3为CSS 3，JS为JavaScript，以上为前端编程语言；java为后端编程语言；MySQL，MongoDB为数据库语言，以上仅了解即可。 |
|
负责人 |
负责人为项目的管理人员，在编程过程中方便开发人员测试，在开发结束后供使用者拥有最高权限。 |
|
MVC三层架构 |
MVC是在应用程序（BS结构）的视图层划分出来的不同功能的几个模块。 |
1.4. 参考资料
[1] 李文新, 郭炜. 北京大学程序在线评测系统及其应用[J]. 吉林大学学报:信息科学版, 2005(S2):170-177.
2. 项目概述
本章将从项目目标，用户特点，假定与约束三个方向对项目进行概述。通过对其进行概述，旨在让所有人对项目有一个大概的理解。
2.1. 项目目标
对于系统总体：
① 用户注册
② 用户信息管理
③ 用户身份识别
对于问卷发布者：
① 为此人提供收集者对问卷的总体要求，导入所有需要调查的对象。
② 帮助问卷发布者进行问题的详细设计，为问卷发布者提供模板。
③ 将所有发布的问卷保存到MySQL数据库当中，并通过调用api发送到需求方，提醒填写问卷并进行填写。
对于问卷填写者：
① 从MySQL数据库获取需要填写的问卷，调用api将界面展示给问卷填写者，提醒填写问卷并填写。
② 在填写完问卷并提交后，将数据发送到MySQL数据库中存储。
③ 在统计问卷的同时记录传回的IP，并禁止相同IP继续填写。
对于问卷收集者：
① 获取问卷发布者对问卷设计的答题要求与问卷调查对象。
② 将①中的数据上传到MySQL数据库中作为备份。
③ 查询MySQL数据库中的问卷填写信息，并对数据进行可视化处理，以更直观方式获得信息。
2.2. 用户特点
表2. 角色说明
|
角色名 |
角色说明 |
|
负责人 |
根据项目要求，负责人拥有最高的权限，可以增删改查所有用户的信息，学校管理人员可通过此账号登入并操作；也可只录入教师的个人信息，然后由教师录入学生的个人信息。学校管理人员可执行的操作有查看所有人员的账号密码并修改，填写的表单，及表单的内容，建立表单并发放。 |
|
教师 |
根据项目要求，教师拥有权限低于管理员的权限，可以增删改查学生的信息，教师可通过自己的账号登入并操作。教师可执行的操作有查看学生的账号密码并修改，建立表单并发放，仅可以看见自己创建的表单。 |
|
学生 |
根据项目要求，学生拥有最低的权限，可以查看自己的信息，可以修改自己的密码，可以填写表单。 |
2.3. 假定与约束
软件设计的约束以及有关说明如下所示。
开发环境：Windows
编程语言：H5,C3,JS,java,MySQL/MongoDB。
遵循的规范：软件的设计和开发过程将严格按照老师要求，根据软件的设计方案来进行。软件开发过程中将遵循软件工程规范，对过程和版本进行管理和控制。
测试环境：在Windows本机环境和阿里云服务器中做测试，电脑配置为四核8G，服务器配置为单核2G。
3. 需求分析建模
本章将从系统业务需求、系统用例模型、功能模块分析、系统非功能需求、特性要求、故障处理要求、其他专门要求进行概述。通过对其进行概述，旨在让读者了解系统的总体以及系统非功能需求。
3.1. 功能需求
3.1.1. 系统业务需求描述
此系统为高校调查问卷管理系统，主要提供三个业务服务目标。
对于负责人，可以是学校领导或者教师；对于教师，对上可接受问卷，填写问卷等，对下可录入学生信息等；对于学生，仅需向上提交报告，完成调查即可。
系统总体需求与需求编号如下：
- 发布者需求
发布者拥有最高的权限，可以增删改查所有用户的信息，学校管理人员可通过此账号登录并操作。
发布者可只录入教师的个人信息，然后由教师录入学生的个人信息。
发布者可执行的操作有查看所有人员的账号密码并修改。
发布者可以查看、创建或填写表单，建立表单并发放。
本人在设计时定死了一个发布者账号：adimn（密码：admin），此账号权限最高，拥有增删改查所有用户的信息，发布者可通过此账号登入并操作；也可只录入收集者的个人信息，然后由收集者录入填写者的个人信息。收集者可执行的操作有查看所有人员的账号密码并修改，填写的表单，及表单的内容，建立表单并发放。
发布者登录==>验证登录合法性==>操作==>登出
2. 收集者需求
收集者拥有权限低于管理员的权限，可以增删改查学生的信息。
收集者可通过自己的账号登录并操作。
收集者可执行的操作有查看学生的账号密码并修改。
收集者可建立表单并发放，仅可以看见自己创建的表单。
本人同时设计了一个测试用的收集者账号：testt（密码：123），此账号权限低于管理员账号，拥有对填写者的个人信息的增删改查，在项目创建结束后此账号会删除，收集者可通过学校管理人员导入好的信息登录，登录后可执行的操作有更改密码，查看填写者的账号密码并修改，创建并发放问卷。
收集者登录==>验证登录合法性==>操作==>登出
3. 填写者需求
填写者拥有最低的权限，可以查看自己的信息。
填写者可以修改自己的密码。
填写者可以填写表单。
与之对应的是填写者账号：tests（密码：123），此账号权限最低，仅拥有查看自己的信息（故意设置成收集者不能修改自己的个人信息），更改自己账号的密码，填写表单的权限。
填写者登录==>验证登录合法性==>操作==>登出
图3.1.1 业务流程模型图
3.1.2. 系统用例模型
表3. 用例模型说明
|
参与者 |
说明 |
|
问卷填写者 |
由发布者指定的填写问卷的人员。 |
|
问卷发布者 |
系统的管理人员，规定问卷的发布与使用。 |
|
问卷收集者 |
收集填写完的问卷并进行数据分析。 |
3.1.3. 功能模块分析
表4. 登陆模块分析
|
标题 |
内容 |
|
用例名称 |
登录 |
|
用例简要说明 |
实现登录效果 |
|
前置条件 |
用户单击链接进入页面。 |
|
事件流 |
|
|
后置条件 |
用户登录成功 |
|
扩展点 |
输入错误有提示信息错误 |
|
优先级 |
高 |
图3.1.3.1 登陆活动图
图3.1.3.2 登陆界面示意图
表5. 问卷收集者用例说明
|
标题 |
内容 |
|
用例名称 |
问卷收集 |
|
用例简要说明 |
此用例为问卷收集者收集问卷的信息并对已完成的问卷进行查看与统计。 |
|
前置条件 |
问卷发布者已发布问卷并且问卷填写者已完成问卷填写，完成的问卷不为空。 |
|
事件流 |
2.1 验证成功到下一步。 2.2 验证失败返回1。 3. 当收集者点击查询问卷按钮时，显示所有可查看的问卷，单击链接系统将进入相应的问卷管理页面。 4. 问卷收集者选择对应操作： 4.1 问卷收集者选择查询问卷情况，系统显示问卷信息，并询问是否导出。 4.1.1 若导出将后台跳转到下载链接，询问框消失，界面无变化。 4.1.2 若不导出询问框消失，停留在此页面。 4.2 问卷收集者选择问卷结构反馈，系统统计问卷填写者的参与情况，并显示信息。 5. 用例结束 |
|
后置条件 |
若用例成功，数据库将记录访问角色、访问时间、访问内容。否则将错误记录在文件下.log文件中。 |
|
扩展点 |
关于错误可通过管理员权限访问错误日志——.log文件进行解决。 |
|
优先级 |
中 |
图3.1.3.3 问卷收集者活动图
表6. 问卷填写者用例说明
|
标题 |
内容 |
|
用例名称 |
问卷填写 |
|
用例简要说明 |
此用例为被允许的问卷填写者对问卷进行填写并对自己完成的问卷查看。 |
|
前置条件 |
身份被成功录入，且被允许填写问卷。 |
|
事件流 |
2.1 验证成功到下一步。 2.2 验证失败返回1。 3. 问卷填写者进入界面后若有未填写的问卷则会收到未填写的提示，点击提示进行访问。 4. 将用户访问的IP传到数据库中。 4.1 该IP已存在，则跳转到请勿重复答卷页面。 4.2 该IP不存在，跳转到问卷页面。 5. 显示问卷发布者发布的问卷，由问卷填写者进行填写。 6.1 问卷填写者手动提交，系统将问卷信息录入到数据库中。 6.2 时间到达上限，系统强制提交，并将问卷信息录入到数据库中。 7.用例结束。 |
|
后置条件 |
若用例成功，数据库将记录访问角色、访问时间、访问内容。否则将错误记录在文件下.log文件中。 |
|
扩展点 |
关于错误可通过管理员权限访问错误日志——.log文件进行解决。 |
|
优先级 |
中 |
图3.1.3.4 问卷填写者活动图
表7. 问卷发布者用例说明
|
标题 |
内容 |
|
用例名称 |
问卷发布 |
|
用例简要说明 |
此用例允许问卷发布者对问卷进行修改或发布问卷至调查对象。 |
|
前置条件 |
系统已被录入成员信息，已生成问卷。 |
|
事件流 |
2.1 验证成功到下一步。 2.2 验证失败返回1。 3. 问卷发布者选择需要进行的操作。 3.1 问卷发布者按照指定格式将成员导入到数据库中，便于系统进行人员核实与信息导出。 3.2 问卷发布者导入预设的模板。 3.3 问卷发布者对问卷进行修改。 3.4 问卷发布者对问卷保存，直接存到数据库中，方便下次使用。 4. 问卷发布者确认无误后发布问卷。 5. 系统对有权限回答问卷的成员发送提示邮件。 6. 用例结束。 |
|
后置条件 |
若用例成功，数据库将记录访问角色、访问时间、访问内容。否则将错误记录在文件下.log文件中。 |
|
扩展点 |
关于错误可通过管理员权限访问错误日志——.log文件进行解决。 |
|
优先级 |
中 |
图3.1.3.5 问卷发布者活动图
3.1. 非功能需求
3.2.1. 系统非功能需求
(1) 可用性：系统最基本的要求，既可以按要求运行。
(2) 简便性：系统极可能简单，针对所有人均可食用。
(3) 可靠性：要求系统在处理任务时，能解决一般的死锁问题以及用户错误的输入。
(4) 高性能性：要求系统响应速度尽可能快，通过使用合适算法提升速度。
3.2.2. 特性要求
(1) 可用性：通过访问web网站，正确登陆账号密码即可操作。
(2) 简便性：将设计、填写问卷放在明显位置，简便寻找的过程。
(3) 可靠性：错误数据可以直接拒绝录入到数据库中，防止脏数据的影响；密码加密传输，不使用明文传输。
(4) 高性能性：数据库采取遍历优化算法。
3.2.3. 故障处理要求
(1) 录入信息错误：提示警告，并提示重新输入。
(2) 提交信息错误：因为资金不足，服务器性能不高，同时访问过多会导致此情况的发生，建议重新提交。
3.3. 其他专门要求
（1）进度要求：于5月底完成后端框架的构建，6月完成前后端的交互。
（2）安全性需求：系统会获取用户IP，但保证仅用来进行防止重复提交的操作。
（3）培训需求：为使用者提供说明书以及视频教学，以及专人客服。
（4）推广需求：仅需要一个链接即可。
4. 运行环境规定
4.1. 基础架构
使用MVC三层架构，示意图如下：
图4.1.1 三层架构示意图
图4.1.2 问卷系统架构示意图
4.2. 支持软件
由于可用web直接访问，即支持PC，IOS，安卓等多平台访问。