需求改进&系统设计
《需求规格书》:https://www.cnblogs.com/Yfight/p/13888751.html
一、团队信息
团队名:好耶团队
团队成员
成员 | 学号 | 职责 |
---|---|---|
叶嘉发(组长) | 3118005293 | PM、测试、撰写博客 |
何煜东 | 3118005274 | 前端开发、测试 |
李宇胜 | 3118005277 | 后台开发、测试 |
陈鸿欣 | 3118005268 | 前端开发、撰写博客 |
叶俊毅 | 3118005294 | 后台开发、测试 |
刘宜霖 | 3118005284 | 后台开发、测试 |
二、需求&原型改进
2.1 问题及改进
问题1:“我的”页面板块排序不合理-'关于我们'应该放在最后一栏
修改1:调整板块顺序(详见页面设计)
问题2:标记后的物品在“我的标记”内消除标记比较麻烦
修改2:“我的标记”内增添“取消标记功能
问题3:跟不同社团借东西的时候需要填不同信息,而原本的申请表太过固定
修改3:申请表内容可以由社团自行进行修改
问题4:三大模块之一“物资广场”4个字,而其他板块只有2个字,放一起不太协调
修改4:将“物资广场”修改为“物资”
2.2 用户调查
类型:定性调研
概述:我们在上周采访了广工校团委前任秘书部部长刘润业,通过访谈了解到了他们原产品解决方案为:每年新上任的小干添加其他社团工作人员微信进行了解并更新物资表,待活动有物资需求时向对应社团进行询问请求从而借到物资;而社团内部的物资管理为新上任的小干根据旧的物资表去跟每个退任的物资旧负责人进行确认,过程十分繁琐,需要耗费大量的时间和精力,有些工作人员颇有怨言。他表示他们正在期盼着一个新的产品解决方案。在功能建议上,他表示希望能方便对每个物资都追踪溯源,减轻使用成本。
2.3 需求规格说明书
2.3.1 页面设计
原型链接:https://98fl4a.axshare.com
2.3.2 场景描述
-
情景一:小A是某社团的物资管理部门干事,某次社团晚会需要用到大量物资,部长说按以往情况都是需要去寻找一个个社团联络人的联络方式然后去询问其是否有对应的物资,他感到十分困惑,不同社团有不同物资,不同联络人,不同的租借注意事项,这可如何是好?这个时候,小B给小A推荐了《校园百社通》!小A打开了网站《校园百社通》,授权后注册了账号,认证了学校信息,在平台上申报并认证了社团管理员,然后就在平台上看到各个社团拥有的各种物资的信息,根据上面写明的注意事项和物资信息,他选好了物资后提交了申请表,过了一会就接收到了申请通过的消息,他在平台上开心的联系了联络员沟通好了去借物资的时间,然后就顺利的借到了物资,小A感慨:“科技真的带来便利呀!”
-
情景二:小C是某社团刚上任的物资管理部门部长,又是一年社团换届时,他又得统计本社团物资的数量、位置分布、对外出借记录,他又觉得特别麻烦!这个时候他突然听说原来的部长有在用《校园百社通》,早就已经把物资登记完毕了,原部长给他转让了管理员权限后,他也能看到本社团所有物资分布情况,他开始感慨:“有了《校园百社通》,以后就方便多了呀!”
三、系统设计
3.1 如何解决需求
一个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。
3.2 系统的架构设计
3.2.1 前端页面设计
网页直接与用户打交道,实现优质的前端交换效果,让用户在使用网页的时候有良好体验感,我们页面设计简洁,主页面就“首页”,“物资”,“组织”,“我的”四个。通过点击展示各种小页面,页面力求达到简洁,能快速完成用户的需求,没有过多的复杂操作。
3.2.2 后端系统设计
负责处理请求,并连接搜索系统,为前端提供数据。有些是处理前端用户的请求,如登录、管理等。还有部分是连接搜索系统。
3.2.3 搜索系统设计
负责搜索、整合数据,处理后端的请求,资源是待搜索的内容,通过后台请求,对数据库的数据进行操作。
3.2.4 总设计
三个系统本身为不同的执行体,实现解耦,使得各个部分都可以扩展自己的功能而不会对其他产生很大影响,彼此之间用协议技术实现交互。
四、Alpha任务分配计划
4.1 Product Backlog
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系,在Product Backlog中选取待实现的功能项
- 第一优先级:实现基本页面的搭建以及基本功能的实现(登陆注册功能、管理物资功能、社团管理功能等)。
- 第二优先级:对基本功能进行完善并加入搜索、物资申请以及发起咨询等复杂功能。
4.2 Sprint Backlog
对已选择的功能项再做进一步分解,分解为1-10小时左右的任务,构成Sprint Backlog。在PM的协助下,编码的同学对任务进行认领。**
序号 | 任务 | 负责人 | 时间安排 |
---|---|---|---|
数据库 | 叶俊毅 | 2020.11.4——2020.11.5 | |
前端页面 | 何煜东、陈鸿欣 | 2020.11.4——2020.11.10 | |
1 | 登陆页面 | 陈鸿欣 | 2020.11.4——2020.11.6 |
2 | 注册页面 | 陈鸿欣 | 2020.11.7——2020.11.10 |
3 | 物资页面 | 何煜东 | 2020.11.4——2020.11.6 |
4 | 组织页面 | 何煜东 | 2020.11.7——2020.11.10 |
后端功能 | 李宇胜、叶俊毅、刘宜霖 | 2020.11.4——2020.11.10 | |
1 | 登陆功能 | 叶俊毅 | 2020.11.5——2020.11.7 |
2 | 注册功能 | 叶俊毅 | 2020.11.8——2020.11.10 |
3 | 物资管理功能 | 李宇胜 | 2020.11.4——2020.11.10 |
4 | 社团管理功能 | 刘宜霖 | 2020.11.4——2020.11.10 |
测试 | 叶嘉发、何煜东、李宇胜、叶俊毅、刘宜霖、叶嘉发 | 2020.11.4——2020.11.10 | |
五、测试计划
5.1 引言
5.1.1 项目背景
该产品主要面向用户为中国各个高校内的社团的物资负责人和管理团队。由于在中国每个大学都有很多社团,广工就有134个社团,可以得知大学社团群体是庞大的。但是在每个大学的一百多个社团之间,常常因为物资的统计和租借,需要大量的人力和时间去挨个交流和收集,特别是每年社团换届后,物资信息的迭代这个任务量是庞大的,交流成本也是存在的。同时各个社团之间沟通交流也有些麻烦,没有一个统一的平台给社团进行活动合作交流的。所以我们好耶团队打算制作一个校园小程序,为大学里面的社团搭建桥梁,方便物资的租借、活动的合作洽谈等社团交流。
5.1.2 参考资料
真实性:本产品以简洁为主,无太多的花里胡哨,产品提供认证服务,确保信息真实可靠!
可用性:本系统可为校内各社团之间提供一个共享物资的平台,达到各取所需,资源利用率最大化的目的。且本系统平台是小程序,操作方便简单,较为实用。
价值所在:本系统的理念即为“共享”,现实上来说,确实为校内各组织提供了便利,且在无形中营造了一种“人人为我,我为人人”的互帮互助的氛围,促进了校园生活的和谐发展。
5.1.3 测试术语
黑盒测试,功能测试,测试项,严重性
性能测试(Performance Testing):
在一定负载情况下,系统响应时间、搜索筛选结果等性能是否满足用户特定的性能需求。
负载测试( Load Testing) :
在一定的软甲、硬件及网络环境下,在不同虚拟用户数量的情况下进行一种或者多种业务,测试服务器的性能指标是否在用户要求的范围内,用于确定系统所
能承受的最大用户数、最大有效用户数以及不同用户数下的系统响应时间和服务器的资源利用率。
压力/强度测试( Stress Testing) :
在-定软件、硬件及网络环境下,模拟大量的虚拟用户想服务器产生负载使服务器的资源处于极限状态下并长时间连续运行目的是用来测试服务器商负载情
况下是否能够稳定工作。
配置测试( Configuration Testing) :
在一定的软件,硬件及网络环境下,在数据库中构造不同数量级别的数据记录运行-种或多种业务,在一定虚拟用户数量的情况 下,获取不同配置的性能指标由于
选择最佳的设备及参数配置。通过配置测试可以将性能缺陷放大方便定位行呢瓶颈。
5.1.4 有关项目人员组成
叶嘉发、陈鸿欣、何煜东、李宇胜、刘宜霖、叶俊毅
5.2 任务概述
5.2.1 测试范围
本软件所有功能
5.2.2 测试目标
所有功能均能正常实现,能应对多用户需求
5.2.3 测试用例编写
模拟求借者,测试借物者角度下的功能,如搜索、物资申请功能、咨询发起功能等
模拟管理者,测试被借者角度下的功能,如物资管理功能、社团管理功能等
5.3 测试策略
5.3.1 测试人员需求、分工
何煜东、李宇胜:用户测试
叶俊毅、刘宜霖:压力测试
叶嘉发:性能测试
5.3.2 测试方法
手动测试、黑盒测试、压力测试等
5.3.3 工具引用及测试培训
手动、内训
5.3.4测试阶段计划
(工作内容、人员安排、起止时间等)
5.3.5 测试停止及恢复条件
测试停止条件:开发人员更改代码
恢复条件:代码修改完毕且确认无误
5.3.6 测试文档及缺陷提交管理等
在每次做完测试后都记录并上传
5.4 测试资源
5.4.1 硬件资源需求
计算机、安卓手机、苹果手机
5.4.2 软件资源需求
谷歌浏览器、微信、sql server/my sql
5.4.3 测试坏境需水
校园网
5.4.4 测试人员需求
何煜东、李宇胜:用户测试
叶俊毅、刘宜霖:压力测试
叶嘉发:性能测试
5.4.5 其他
微信小程序服务器
5.5 风险评估
5.5.1 人力方面
人力充足
5.5.2 时间方面
时间充足,可边开发边测试
5.5.3 环境方面
面向百度进行环境配置
5.5.4 资源方面.
资源充足
5.5.5 部门合作方面
前后端进行密切交互,可实现项目的同步改进完善
5.6 其他内容
5.6.1 测试计划制定者
陈鸿欣
5.6.2 日期
2020.11.03
5.6.3 修改记录
暂无
5.6.4 评审人员
何煜东、李宇胜、叶俊毅、刘宜霖、叶嘉发