“志愿先锋”微信小程序软件需求规格说明
目 录 1.引言 1.1编写目的 1.2背景 1.3预期的读者和阅读建议 1.4定义 1.5产品的范围 1.6参考文献 2. 综合描述 2.1产品的前景 2.2产品的功能 2.3用户类和特征 2.3.1志愿者 2.3.2志愿活动组织者 2.3.3管理者 2.4运行环境 2.5设计和实现上的限制 2.6约束 2.7假设和依据 3. 对外接口需求 3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通信接口 4.系统特性 4.1说明和优先级 4.2激励/响应序列 4.3提供的功能 5. 其它非功能需求 5.1性能需求 5.1.1时间特性 5.1.2服务器性能 5.1.3用户数量 5.1.4兼容性 5.2安全设施需求 5.3安全性需求 5.4软件质量标准属性 5.5业务规则 附录A:词汇表 附录B:分析模型 1.结构化需求分析 1.1功能分解图 1.2需求细化 1.3优先级划分 2.过程建模 3.数据建模 4.对象建模
1. 引言
1.1编写目的
为明确软件需求、安排项目规划与进度、组织软件开发与测试,撰写本文档。
本文档供项目经理、开发人员、测试人员、用户参考。
1.2背景
当前社会上存在志愿服务平台(如:志愿北京http://www.bv2008.cn/),但是常存在内容繁杂、志愿项目超出志愿者能力的情况。作为北理工的学子,大家迫切需要一个便利的志愿服务平台,及时获取身边的志愿活动信息,以便开展后续志愿服务。作为志愿活动组织方,需要准确了解志愿者基本情况,方便有针对性地募集志愿者。
1.3预期的读者和阅读建议
表1-1 预期的读者和阅读建议
|
预期读者 |
阅读建议 |
|
项目经理 |
项目经理可以根据该文档了解预期产品的功能,并据此进行系统设计及项目管理。 |
|
开发人员 |
对需求进行分析,并设计出系统,包括页面和数据库的设计。了解与实现系统功能,编写《用户手册》。 |
|
测试人员 |
根据本文档编写测试用例,并对软件产品进行功能性测试和非功能性测试。 |
|
用户 |
了解预期产品的功能和性能,并与分析人员一起对整个需求进行讨论和协商。 |
1.4定义
表1-2 术语定义
|
名称 |
定义或描述 |
|
志愿者 |
参与志愿活动的人 |
|
志愿活动组织者 |
提供志愿活动的人 / 组织,有招募志愿者的需求 |
|
管理员 |
管理的人,管理平台、志愿活动和用户 |
|
系统 / 项目 |
“志愿先锋”微信小程序 |
1.5产品的范围
“志愿先锋”微信小程序是一个集志愿活动报名、志愿招募信息发布、历史志愿活动记录等功能于一身的志愿信息交互平台。
对于志愿者,提供一个便利的志愿服务平台,志愿者可以通过此平台及时获取身边的志愿活动信息,方便地选择并报名志愿活动开展志愿服务。
对于志愿活动组织方,使其可以便捷地发布志愿活动,准确了解志愿者基本情况,方便有针对性地募集志愿者。
1.6参考文献
[1]骆斌等.需求工程——软件建模与分析(第2版).高等教育出版社,2015.2.
[2] 软件需求规格说明书标准模板,迪迈科技,2015.07.10,https://wenku.baidu.com/view/19055bc4fe4733687e21aaa3.html
[3] 构建之法.邹欣.人民邮电出版社,2017.07
2. 综合描述
2.1产品的前景
当前社会上存在志愿服务平台(如:志愿北京http://www.bv2008.cn/),但是常存在内容繁杂、志愿项目超出志愿者能力的情况。作为北理工的学子,大家迫切需要一个便利的志愿服务平台,及时获取身边的志愿活动信息,以便开展后续志愿服务。作为志愿活动组织方,需要准确了解志愿者基本情况,方便有针对性地募集志愿者。
该产品是一个新型的、自含型产品,是一个集志愿活动报名、志愿招募信息发布、历史志愿活动记录等功能于一身的志愿信息交互平台。对于志愿者,提供一个便利的志愿服务平台,志愿者可以通过此平台及时获取身边的志愿活动信息,方便地选择并报名志愿活动开展志愿服务。对于志愿活动组织方,使其可以便捷地发布志愿活动,准确了解志愿者基本情况,方便有针对性地募集志愿者。
2.2产品的功能
1) 用户可以注册成为平台志愿者,填写个人信息;
2) 用户可以注册成为志愿活动发布者;
3) 用户浏览当前平台上的志愿活动的简略信息,点击可查看详情;
4) 用户可以选择申请参加其中正在招募志愿者的活动;
5) 用户在参与后平台会对志愿者的服务时长进行相应的记录;
6) 用户可以查看自己的服务时长;
7) 用户可以根据不同地区筛选查找志愿活动;
8) 用户可以按时间段筛选查找志愿活动;
9) 志愿活动发布者可以在平台上发布志愿招募信息;
10) 志愿活动发布者可以选拔报名的志愿者用户
11) 管理员用户可以删除活动记录;
12) 管理员用户可以查看、导出平台数据;
13) 管理员用户可以审核通过用户的志愿活动发布者申请;
14) 活动信息包括“志愿时间”“志愿地点”“志愿者福利”“组织方信息”“志愿者能力要求”“其他”模块;
15) 可以根据用户的数据特征将用户分类。
2.3用户类和特征
2.3.1志愿者
志愿者为参与志愿活动的人,有注册、填写个人信息,浏览志愿活动信息, 申请参加志愿活动,获取、查看志愿时长,筛选查找志愿活动的需求。
2.3.2志愿活动组织者
志愿活动组织者为提供志愿项目的人或组织,有发布志愿招募信息,筛选、招募志愿者,发放志愿时长,获取志愿者分类的需求。
2.3.3管理者
管理者为管理志愿系统的人,有查看、管理、导出平台数据的需求。
2.4运行环境
- 运行环境:微信6.0及以上
- 硬件平台:移动终端
- 操作系统:Android、iOS等
2.5设计和实现上的限制
项目预期实现形式为微信小程序,由此对开发造成的限制有:
- 特定技术:微信云开发技术
- 特定开发工具:微信web开发者工具
- 特定编程语言:JavaScript、WXML(微信标记语言)、WXSS(微信样式表)
- 特定数据库:微信云开发数据库
- 政策要求:小程序必须符合法律法规及微信平台的规定
2.6约束
- 并发操作:同时最多有10个网络请求连接;
- 控制功能:后台可控制小程序的运行状态,能够监控
- 信号握手协议:信息交流必须可靠,所以信息须通过审核
- 应用的临界状态:当小程序超负载,自动退出
- 安全性考虑:交易须有审核,用户信息足够保密
2.7假设和依据
本项目是否能够成功实施,主要取决于以下的条件:
1) 团队成员的积极合作配合,为了项目的开发和实施,对个人时间进行合理规划同时为团队做出合理牺牲,配合队友完成任务;
2) 团队掌握先进的能够适用于该项目的技术,这是系统的性能是否优化和项目能否成功的保证;
3) 团队为软件系统的运行提供必要的且能够满足系统运行条件的硬件环境和通讯环境,不合适的硬件环境和通讯环境将会影响系统的性能;
4) 团队为系统的调研、开发和实施过程提供必要的工作环境和系统运行环境,这些环境有助于工作的展开。
3. 对外接口需求
3.1 用户界面
界面风格:本系统采用图形化界面,并对用户和管理员的界面风格有所区别,具体来说,用户界面清新、大方、美观、新颖,保证了用户良好的使用体验,而管理员界面简约,易于管理员的各项操作。
界面布局:用户系统主要包含个人信息页、活动详情页、志愿发布页三个页面。其中个人信息页采用列表布局,活动详情页采用瀑布流进行显示,志愿发布页采用表单布局。同时,各页面中的按钮以及选择框的布局也符合用户的操作习惯,从而方便了用户的使用。
3.2 硬件接口
适配搭载微信6.0及以上的基于Android操作系统或iOS操作系统的移动设备。
3.3 软件接口
操作系统:Android或IOS
数据库:微信云数据库
为了方便管理员对系统中的各项数据进行管理,通过与微信云数据库的接口实现与数据库间的用户信息和活动信息交换。
3.4 通信接口
该系统可由微信直接打开,可获取本机信息,其中包含了基于TCP、HTTP协议的通信。
4.系统特性
4.1说明和优先级
表4-1优先级划分
|
优先级 |
需求 |
评分 |
平均分 |
|||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|||
|
1 |
浏览志愿活动信息 |
8 |
9 |
10 |
9 |
10 |
8 |
10 |
9 |
9 |
10 |
9.2 |
|
2 |
填写活动招募信息 |
10 |
8 |
10 |
8 |
10 |
7 |
8 |
9 |
8 |
9 |
8.7 |
|
3 |
申请权限 |
10 |
9 |
5 |
8 |
6 |
10 |
10 |
9 |
9 |
10 |
8.6 |
|
4 |
志愿活动发布到信息栏 |
10 |
9 |
8 |
8 |
10 |
5 |
10 |
10 |
7 |
9 |
8.6 |
|
5 |
登录 |
10 |
9 |
5 |
9 |
10 |
10 |
10 |
5 |
5 |
10 |
8.3 |
|
6 |
查询志愿者个人信息 |
8 |
7 |
10 |
7 |
10 |
7 |
8 |
8 |
9 |
8 |
8.2 |
|
7 |
填写活动申请表 |
10 |
6 |
10 |
8 |
7 |
7 |
8 |
9 |
8 |
9 |
8.2 |
|
8 |
注册成为组织者 |
7 |
8 |
10 |
8 |
5 |
10 |
8 |
8 |
9 |
7 |
8 |
|
9 |
活动信息提交审核 |
7 |
8 |
10 |
8 |
7 |
8 |
4 |
5 |
7 |
9 |
7.3 |
|
10 |
修改招募信息 |
8 |
8 |
7 |
7 |
5 |
7 |
4 |
8 |
8 |
7 |
6.9 |
|
11 |
修改志愿者个人信息 |
5 |
8 |
5 |
8 |
6 |
7 |
6 |
10 |
9 |
3 |
6.7 |
|
12 |
结束志愿活动 |
6 |
4 |
5 |
6 |
10 |
7 |
8 |
2 |
6 |
6 |
6 |
|
13 |
下架志愿活动 |
1 |
7 |
5 |
6 |
4 |
7 |
6 |
8 |
6 |
3 |
5.3 |
说明:每位评分者总计100分,优先级从1至10分逐渐升高,每项最高不超过10分。评分者分布:甲方2人,乙方6人,涉众2人。
4.2激励/响应序列
列出输入激励(用户动作、来自外部设备的信号或其它触发器)和定义这一特性行为的系统响应序列。就像在第8章讲座的那样,这些序列将与使用实例相关的对话元素相对应。
志愿者:登录账号,查询活动,选择活动,提交申请。
组织者:登录账号,发布活动,选择志愿者,发送录取通知。
管理者:登录账号,查询报表,认证组织者。
4.3提供的功能
1) 用户可以注册成为平台志愿者,填写个人信息;
2) 用户可以注册成为志愿活动发布者;
3) 用户浏览当前平台上的志愿活动的简略信息,点击可查看详情;
4) 用户可以选择申请参加其中正在招募志愿者的活动;
5) 用户在参与后平台会对志愿者的服务时长进行相应的记录;
6) 用户可以查看自己的服务时长;
7) 用户可以根据不同地区筛选查找志愿活动;
8) 用户可以按时间段筛选查找志愿活动;
9) 志愿活动发布者可以在平台上发布志愿招募信息;
10) 志愿活动发布者可以选拔报名的志愿者用户
11) 管理员用户可以删除活动记录;
12) 管理员用户可以查看、导出平台数据;
13) 管理员用户可以审核通过用户的志愿活动发布者申请;
14) 活动信息包括“志愿时间”“志愿地点”“志愿者福利”“组织方信息”“志愿者能力要求”“其他”模块;
15) 可以根据用户的数据特征将用户分类。
5. 其它非功能需求
5.1性能需求
5.1.1时间特性
系统的实时性要求一般,因此系统响应时间应在3-5s之间即可。
5.1.2服务器性能
用户范围限制在北京理工大学,所以对服务器性能要求一般。数据库应可承受5000次查询。
5.1.3用户数量
初期用户数量在1000位左右。
5.1.4兼容性
适配市面上各主流手机屏幕分辨率。
5.2安全设施需求
未登录的用户不能查看志愿活动信息,系统提醒用户前往登录,用户同意时直接重定向到登录界面。
5.3安全性需求
- 系统保密性:严格界定不同用户的权限,只有被授权的用户才能动用和修改信息系统的信息,而且必须防止系统信息的非法、非授权的泄露。
- 系统完整性:信息必须完整的被授权的用户使用,只有备授权的用户才能修改信息。
- 可用性:系统数据通过本地缓存和云端数据库进行备份,保证了客户端的意外崩溃不会导致系统信息的丢失,保证系统的正常运行。
5.4软件质量标准属性
- 正确性:软件可以按照需求正确的执行任务。比如用户可以正确的申请或者发布志愿信息、发布者可以正确的完成对活动志愿者的审核、普通志愿者可以正确的提交成为发布者的申请并获得相应的反馈等等。
- 健壮性:软件具有较强的容错和恢复能力。如果某些预期之外的操作发生,本软件可以在一定程度上保护与恢复现场,在软件回到正常的生命周期时可以继续完成之前的未完成任务,软件在发送数据请求的时候,对请求失败设置了相应的回调。在程序意外崩溃后,可以通过重启程序,借助云端数据库的信息,完成数据恢复,保证软件的正常运行。
- 可靠性:在软件的单元测试、集成测试、以及验收测试中,通过大量数据与用户行为的测试,程序体现了高可靠性,未出现影响正常功能使用的错误。
- 易用性:软件充分考虑了用户体验,简化合并了软件功能,借鉴了主流软件设计中的布局与逻辑设计,在用户首次使用时,软件会对用户进行简单的引导,进而让用户更快更简易的学会软件的使用。
- 可拓展性:在软件设计初期,我们明确了数据库结构,减少了页面之间的直接联系,统一了命名规范,在后续的开发维护升级中,可以方便的添加、修改、更换、删减页面,具有较强的灵活性可拓展性。
5.5业务规则
- 只有认证为活动组织者的用户才能发布志愿活动
- 只有拥有管理员密码的用户才能审核用户成为活动组织者
- 只有登录的用户才能查看志愿活动详情
- 只有活动组织者才能从报名的志愿者选择参与活动的志愿者
- 只有被审核成功的志愿者才能参与志愿活动
- 只有参与志愿活动的志愿者才能获得志愿时长
- 只有拥有管理员密码的用户才能查看所有的数据信息
附录A:词汇表
|
术语 |
含义 |
备注 |
|
活动组织者 |
志愿活动的组织方,通常代表了承办志愿活动的组织,在平台上主要进行志愿活动的发布。 |
与志愿发布者、志愿活动组织者含义相同 |
|
交互 |
即交流互动,是很多互联网平台追求打造的一个功能状态。通过某个具有交互功能的互联网平台,让用户在上面不仅可以获得相关资讯、信息或服务,还能使用户与用户之间或用户与平台之间相互交流与互动,从而碰撞出更多的创意、思想和需求等。 |
|
附录B:分析模型
1.结构化需求分析
流程图:

流程图
1.1功能分解图

图B-1 功能分解图
1.2需求细化
- 浏览志愿活动信息
- 填写活动招募信息
- 申请权限
- 志愿活动发布到信息栏
- 登录
- 查询志愿者个人信息
- 填写活动申请表
- 注册成为组织者
- 活动信息提交审核
- 修改招募信息
- 修改志愿者个人信息
- 结束志愿活动
- 下架志愿活动
1.3优先级划分
见表4-1。
说明:每位评分者总计100分,优先级从1至10分逐渐升高,每项最高不超过10分。评分者分布:甲方2人,乙方6人,涉众2人。
2.过程建模
图B-2 上下文图
图B-3 0层图




图B-4 1层图
3.数据建模

图B-5 数据关系图
4.对象建模
图B-6 用例图

图B-7 类图
表B-1 类图注释
|
标识符 |
含义 |
|
Admin |
管理员 |
|
Volunteer |
志愿者,亦即志愿报名者 |
|
Organizer |
志愿组织者,即活动组织者 |
|
Activity |
志愿活动 |
|
id |
身份标识号码(用户或活动) |
|
password |
登陆密码 |
|
headImg |
头像 |
|
name |
用户姓名或活动名称 |
|
serviceTime |
历史志愿时长记录 |
|
activityRecord |
历史发布志愿活动的信息 |
|
time |
志愿活动的时间 |
|
place |
志愿活动的地点 |
|
numOfVolunteer |
志愿活动要求的志愿者人数 |
|
intro |
志愿活动的简介 |
|
duration |
志愿活动的持续时间 |
|
benefit |
志愿活动的福利 |
|
requiredAbility |
志愿活动对志愿者的能力要求 |
|
validity |
志愿活动是否通过审核 |
|
login |
登陆 |
|
authentication |
对志愿发布者身份的审核和认证 |
|
audictActivity |
对志愿活动的审核 |
|
getUser |
获取用户的相关信息 |
|
getAcitivity |
获取志愿活动的相关信息 |
|
getData |
获取运营数据 |
|
deleteUser |
对用户进行删除 |
|
deleteActivity |
对志愿活动进行删除 |
|
register |
用户的注册 |
|
filter |
对志愿活动进行筛选 |
|
sighUp |
报名志愿活动 |
|
getProfile |
获取个人信息 |
|
editProfile |
编辑修改个人信息 |
|
signForOrganizer |
申请成为活动组织者 |
|
uploadActivity |
志愿活动的发布 |
|
changeStatus |
对已发布的志愿活动进行信息修改 |
|
verifyVolunteer |
对报名已发布志愿活动的志愿者进行审核 |

图B-8 交互图(志愿者)

图B-9 交互图(活动组织者)

图B-10 交互图(管理员)

图B-11 状态图(志愿者)

图B-12 状态图(志愿活动组织者)

图B-13 活动图
该文档甲方已确认

浙公网安备 33010602011771号