拟制: 于海 日期:2018/03/29
审核: 朱文焜 日期:2018/07/08
[TOC]
该文档首先给出了整个系统的整体网络结构和功能结构的概貌,试图从总体架构上给出整个系统的轮廓,然后又对功能需求及其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式,主要描述了每一用例的基本事件流,若有备选事件流则描述,否则则省略。而且还给出了非常直观的用例图。这些文字和图形都为了本文档能详细准确地描述用户的需求,同时也为用户更容易地理解这些需求的描述创造了条件。 该文档依照用户需求访谈详尽说明了iTraining的需求和规格,这些规格说明是进行设计的基础,也是编写测试用例和进行系统测试的主要依据。
本文档的主要内容共分5个部分:总体概述、具体需求、设计约束、软件质量属性及其他需求。总体概述部分主要对系统的整体结构进行了大致的介绍;系统特征对具体功能需求做了详细描述,是本文的主要部分,非功能性需求和其他需求则是对该系统相应方面的补充描述。 本文档面向多种读者对象:
项目经理:
项目经理可以根据该文档了解预期产品的功能,并据此进行系统设计、项目管理;
设计员:
对需求进行分析,并设计出系统,包括数据库的设计; 程序员:配合《设计报告》,了解系统功能,编写《用户手册》;
测试员:
根据本文档编写测试用例,并对产品进行功能性测试和非功能性测试; 用户:了解预期产品的功能和性能,并与分析人员一起对整个需求再行讨论或协商;
其他人员:
其他人员可以根据此了解产品的功能和性能。在阅读本文档时,首先要了解产品的功能概貌,然后根据自身的需要对每一功能进行适当的了解。
iTraining是几个15级本科生在没有项目经验的基础上开发的微信小程序,将适用于大学校运动队训练打卡,主要完成队长创建队伍社区、队长发布训练计划、队员打卡执行、发布并查看队伍成员打卡动态、查看运动小知识等业务。
队伍社区:
可以是高校的一个运动队,运动社团,临时组件的小群体,需要通过移动互联网将他们联系起来。
训练计划:
综合分析传统训练方式并与某运动队教练沟通后,我们小组发现,日常训练中一个训练计划通常需要指定这个训练计划的时间地点,需要完成哪些训练项目,这些训练项目又有哪些具体的要求。并需要将这个训练计划通知到每个队员。
训练项目:
日常训练中运动项目可能多种多样,例如校龙舟队日常的训练项目包括:12人龙舟,皮划艇,深蹲,卧推,扒拉,测功仪,跑步等等。
训练指标:
训练指标是指一个训练项目中客观反映训练状态的指标,例如测功仪训练中的风阻(单位n)、桨频(单位f),距离(单位km)。例如深蹲训练,考察的指标包括负重的重量(单位kg),每组的个数,组间间隔 (单位min)等等。
完成度:
对于每个训练计划,我们需要考察每个队员的完成情况,这个完成情况用完成度来定义,范围在1%到100%
动态:
每个队伍成员可以将自己今日的训练计划完成情况发布成动态,队员之间可以查看发送的动态信息。
大学校运动队常规训练基本采取队长在微信或qq群内发布公告说明训练计划的开放状态,队员收到后执行训练计划,训练结束后或无反馈,或只是单纯的群内汇报训练情况,缺少训练信息的回馈和统计分析,无法充分挖掘训练效果,所以一个好的训练管理及结果反馈与分析平台对于大学校运动训练队来说是必需的。 好的训练打卡系统可以更好的帮助队长发布训练计划,使得队员打卡的反馈情况更有条理,同时队长可以通过打卡记录及一定的数据分析快速获得全队的训练情况,改进训练计划,从而提高队伍素质,为学校摘金夺银。
iTraining的运行环境分微信小程序窗口、应用服务器端和数据库服务器端三部分:
微信小程序窗口:
用户所接触到的UI界面是在微信小程序窗口;
应用服务器端:
负责相应前端的请求,并对数据库进行增删改查
数据库服务器端:
数据的存储,直接对增删改查
由于我们小组成员之前没有项目经验,所以某些方面的功能实现起来可能会有些欠缺,队员对计划的完成情况,我们暂时还不能达到一个细致的考量,只能是定义一个完成度。
iTraining主要适用于大学校运动训练队,因此角色构成为普通用户,系统管理员。这里的普通用户即可以扮演队长的角色创建并管理一个或多个队伍,同时也可以在其他队伍中充当队员的角色
图2 iTraining用例图
简要描述
用户创建队伍社区
参与者
普通用户
场景描述
队长注册队伍社区账号,并完善社区基本信息
前置条件
点击创建队伍申请注册。
后置条件
返回队伍社区是否成功创建的信息
事件流
图3.1 创建队伍
简要描述
队长创建社区成功后可以通过分享社区二维码邀请队友加入该社区
参与者
队长,队员
场景描述
队长创建队伍社区成功后可以向队友分享社区二维码,队友扫码并确认加入即可加入该社区
前置条件
队长分享社区二维码
后置条件
队友是否成功加入社区
事件流:
图3.2 邀请队友他人队伍
但凡点击进入iTraining的用户,默认是微信账号登录。
简要描述
队长可以在项目专栏里动态添加训练项目
参与者
队伍的队长
场景描述
队长拥有一个项目专栏,进入训练项目专栏编辑页面后可以自己手动添加训练项目名称,定义项目指标,完成添加
前置条件
进入项目专栏编辑页面
后置条件
训练项目添加成功
事件流:
图3.3 添加训练项目
简要描述 队长可以进入制定训练计划页面选定特定项目并输入相应指标数值后选择发布训练计划
参与者 队长
场景描述 队长点击制定训练计划进入制定训练计划页面,在该页面中依次选定待训练项目,输入训练组数、选择训练方式和考量目标、输入某项目相应训练指标的数值并确定是否是强制性指标,选定后点击预览发布计划,如若有误可回退到制定页面再次修改训练计划,无误后点击发布训练计划
前置条件
进入制定训练计划页面
后置条件
训练计划发布成功
注意 如果选定的是集体项目,则需要在原有的组数、训练方式、考量指标以及训练指标的基础上增加参训人员名单专栏供队长输入参训人员名单。此外,训练方式和考量目标是按照术语要求按上下滑动选择格式来呈现。 事件流:
图3.5 发布训练计划
简要描述
队伍成员可在训练计划页面查看训练计划及个人打卡记录
参与者:
队长、队员
场景描述
队伍成员点击训练计划专栏可查看当下及过往的训练计划,具体训练计划包括发布人和发布时间、具体训练内容,若是未完成的训练计划,则下方应是“我要打卡”按钮,若是已打卡的训练计划,则显示个人在该训练计划的的打卡记录。
前置条件
点击训练计划专栏
后置条件
呈现训练计划或个人打卡记录
简要描述
队伍成员查看未完成的训练计划时可点击“去打卡”填写训练情况完成度,填写训练感想,选择展示的图片,完成打卡并发布动态
参与者
队长、队员
场景描述
队伍成员点击训练计划专栏可查看未完成的训练计划,点击下方“去打卡”填写训练情况完成度,填写训练感想,选择展示的图片,完成打卡并发布动态
前置条件
查看未完成的训练计划
后置条件
打卡成功
图3.7 打卡执行
简要描述
队伍成员在自己和队友的动态页里可以查看动态记录
参与者
队长、队员
场景描述
队伍成员进入动态页,可以查看自己和队友发布的动态记录,动态包括训练的完成情况,个人感想,上传的图片。
前置条件
进入某位队友的动态页查看动态
后置条件
显示最近的自己和队友发布的动态
事件流:
UI界面:与用户之间交互的载体是微信小程序界面,支持一般的移动终端
服务器端建议使用专用服务器。
无特殊需求。
无特殊需求。
-
小程序一般响应时间不超过1秒,成绩报告允许延迟1秒;
-
支持200人同时在线打卡训练情况;
-
支持5000名用户在线浏览并保证性能不受影响
-
记录日志:本平台应该能记录在运行时所发生的所有错误,包括本机错误和网络错误,这些错误记录便于查找错误的原因,日志同时记录用户的关键性操作信息;
-
权限控制:某队伍社区的所有训练计划打卡情况均只可由该队伍社区成员访问,其他成员禁止浏览。
该平台可维护性应该良好,以便运维人员进行日常维护。
iTraining设计之初便是定位在微信小程序,因此可不考虑移植性问题
iTraining要有良好的拓展性,可供开发人员对原有功能进行优化、对新增功能能够加入其中并得到良好的运用。
能够做到数据的持久化,可以保存所有已创建社区的信息,包括所有队伍成员,训练项目,训练计划及全队成员打卡动态。