软件需求与设计规格说明书-共享单车管理系统Word版
校园共享单车运行管理系统
需
求
与
设
计
规
格
说
明
书
姓名：邵江南
班级：14计科2班
学号：99999999999
目录
1．引言
1.1需求规格说明书编写目的 (2)
1.2 软件产品的产生背景 (2)
1.3 定义、同义词与缩写 (3)
1.4 参考文献 (3)
2.任务概述
2.1目标 (3)
2.2 产品与功能 (4)
2.3 用户特征 (4)
2.4 限制与约束 (5)
3．需求规定
3.1对功能的规定 (5)
3.2 对性能的规定 (13)
3.3 输入输出要求 (14)
3.4 数据管理能力要求（针对软件系统） (15)
3.5 故障处理要求 (15)
3.6 安全保密 (15)
4．运行环境规定
4.1设备 (16)
4.2控制 (16)
5．备注 (17)
1．引言
1.1需求规格说明书编写目的
本要求规格说明书对校园共享单车管理系统进行简单的分析，给出了系统的数据流图。系统主要用户是学生，教师和校内工作人员。同时编写此需求规格说明书，可以加深与用户间的交流，在功能与系统界面上与用户达成一致的看法，以便于开发出用户满意的应用系统。
1.2 软件产品的产生背景
共享单车是指企业与政府合作，在校园、地铁站点、公交站点、居民区、商业区、公共服务区等提供自行车单车共享服务，是共享经济的一种新形态。为解决“最后一公里出行”问题，共享单车应运而生，相比其他出行方式，其价格低。中国这一“自行车上的国家”几十年后通过共享单车再次名副其实。
与网约车不同，自行车的运营受季节变化、天气状况等影响也比较大。至于遇上台风暴雨，则无论地处何方，共享单车出行的订单量，都会直线下降甚至归零，而平台还得面对更加高昂的车损折旧成本。据中国报告大厅发布的
《2017-2022年中国共享单车行业专项调研及投资价值预测报告》显示，与“有桩”的公共自行车相比，这种随时取用和停车的“无桩”理念给市民带来了极大便利的同时，也导致“小红车”和“小黄车”的“乱占道”现象更加普遍，城市空间的管理因而变得更加困难，这也就需要相应的管理规定出台。
在这些共享单车的出没环境中，路途较短，分布集中，用户素质较高，电子支付熟练，易于管理，人流量大，使用率高……等特点的校园，必然集万众焦点于一身，成为各个共享单车平台的必争之地，这也带来了一大堆问题：常有用户或遗忘或故意停车不锁车，这直接导致了车的非正常恶意使用率上升，加速车的损耗，影响正常需求用户的使用，也降低了单车的运营收入；而近期成为热点问题的用户乱停乱放、随手停车等严重影响交通、阻碍大众出行的问题屡禁不止，让本来诞生之初为了减轻交通拥堵问题的共享单车起了反作用；更有甚者，有些用户由于无人监管，便肆无忌惮蓄意破坏单车……
本共享单车运行管理系统，即主要面向此类校园共享单车。
1.3 定义、同义词与缩写
定义关键词如下：
Sbike——校园共享单车；
SMS——校园共享单车管理系统
1.4 参考文献
《软件工程——第2版》齐治昌谭庆平宁洪编著高等教育出版社
2.任务概述
2.1目标
本软件的目标是使校园共享单车管理系统管理电子化、系统化、简单化，以节省Sbike管理方面不必要的资源浪费。该管理系统的最终用户为终端用户，管理人员和其他相关人员。本系统包括了Sblke运行管理的一般功能。还包括一些其他的系统功能，诸如新车上市，旧车退市以及提醒落锁、收费等。目标还包括：
1.减少人力资源的使用和降低管理费用；提高信息准确度和可靠性；
2.改进Sbike内管理和人员服务；
3.建立高效的信息传输和服务平台，提高信息处理速度和利用率；
4.系统设计优良，界面设计精美、友好、快捷，人性化设计，后台管理功能强大效率高；
5.更简便、信息化程度更高的Sbike管理流程；
2.2 产品与功能
针对产品背景、用户需求等初步归纳产品应具备的功能如下：
1. 租赁管理（计费收费等）
2. 设备管理（开锁关锁故障记录报修报失等）
3. 调度管理
4. 故障报修管理
5. 仓库管理
7. 信息推送模块（车辆GPS定位、轨迹及分布查询等）
8. 监控系统模块
9. 统计报表
10. 系统角色及用户管理（记录信息用户信用记录）
2.3 用户特征
小型SMS的工作人员，包括Sbike校园经理、Sbike管理员等掌握基本的计算
注意：借车人员随机性大，频率不稳定，开发人员需定期维护。
2.4 限制与约束
开发与运行的硬件平台要能够支持多用户并发访问。本软件在开发的过程中，分为技术实现与软件工程两大部分，两大部分都有侧重点，若技术支持出现故障或疑难问题无法解决、程序开发出现偏差，会延误工程进度，影响工程的按期完工。若软件工程陈述出现问题，部分描述含混不清，则会影响系统的完整性与可继承性。在管理方面，如管理者没有预见性，对出现的问题无法采用可行的解决手段，都会影响开发模块之间的互动，从而影响工程的顺利开展，导致工程无法按期完工。本次设计的管理系统采用的是B/S结构的软件体系，服务器采用https://www.360docs.net/doc/7212491523.html,技术，后台数据库采用mySQL。
3．需求规定
3.1对功能的规定
3.1.1系统概述
对于本系统划分为：车辆管理子系统、用户管理子系统和借还车辆管理子系统三个主题
域。各个主题域的功能如图3-0-1
图3-0-2 系统概述
3.1.2.1 车辆管理
车辆录入：添加新增车辆的基本信息
车辆退市：将已退市车辆的数量、信息全部清零，并安排回收处理
车辆查询修改：输入车辆号即可获得当前车辆的位置、健康度、是否已借出等信息。当校园内有旧车退市或新车上市时，管理员可通过改系统对车辆信息进行更新。如图3-1-2:
图3-1-2 车辆管理子系统
3.1.2.2 业务事件
1.管理员登陆系统
业务流程分析：
管理员对系统数据库信息进行操作时，需要验证账号和密码登陆成功后才能进行相关的操作。其中主要包括对车辆信息的录入、查询、更新及删除操作。其流程如图3-1-3所示。
图3-1-3 管理员登录系统及操作流程图
2.车辆管理员录入车辆信息
业务流程分析：
车辆管理员在登陆验证成功后可进行车辆信息录入的操作，其流程图如图3-1-3所示。
3.车辆管理员查询及更新车辆信息
业务流程分析：
车辆管理员在登陆验证成功后可进行更新车辆信息的操作，其流程图如图3-1-3所示。
4.车辆管理员删除退市车辆信息
业务流程分析：
车辆管理员在登陆验证成功后可进行删除退市车辆信息的操作，其流程图如图3-1-3所示。
3.1.3.1用户管理
添加用户信息：添加新增借车者的信息。
用户查询及修改：输入用户姓名或用户账号可获得用户的基本信息并可修改其信息。删除用户信息：输入用户姓名删除用户信息如图3-2-1：
图3-2-1:用户管理子系统
3.1.3.2 业务事件
1.车辆管理员登录系统
业务流程分析：
管理员对系统数据库信息进行操作时，需要验证账号和密码登陆成功后才能进行相关的操作。其中主要包括对用户信息的录入、查询、更新及删除操作。其流程如图3-1-3所示。
2.车辆管理员查询及修改用户信息
业务流程分析：
管理员登陆验证成功后，进行修改用户信息的操作，流程图如图3-1-3所示。
3.车辆管理员删除用户信息
业务流程分析：
管理员登陆验证成功后，进行删除用户信息的操作，流程图如图3-1-3所示。
3.1.3.3
管理用户信息：
描述项说明
用例名称管理用户信息
参与者Sbike管理员
概述Sbike管理员将实时的用户的基本信息添加
到系统数据库中并进行管理
前置条件管理员成功登陆系统
后置条件确定没有重复的读用户账号
基本事件流 1. 管理员登陆系统后，选择“车辆信息录
入”操作，进入添加车辆信息的页面，填写
的车辆基本信息。
2．点击“添加”按钮后，系统会将信息添
加到数据库的用户信息汇总表中。
3. 添加成功后管理员可以执行查看和
删除操作。
异常事件流 1. 添加的借车账号信用级别低。
2. 添加的信息不符合要求
3. 管理员添加了错误的用户信息
4. 管理员登陆失败
5. 用户信息添加失败
6. 相关需求与功能点
被包含的用例检查用户合法性用例
3.1.
4.1 借还车辆管理
借车登记：先登录借车帐号,检查信用记录是否合格和历史账单清空的检查.若符合则添加借车账号,车号及借车时间等信息。
借车记录查询及续签：输入借车账号或车号可获得其相关信息并可办理续签手续。
还车手续办理：输入用户帐号及车号,在借车记录添加还车时间。
借车收费：该功能在用户还车时检索用户借车信息计算时间、路程，并得出价格,得出相应的账单，从而让用户付费上锁。
如图3-3-1：
图3-3-1：借还车管理子系统
3.1.
4.2业务事件
1.用户登录验证
业务流程分析：
该流程是用户在进行自己相关信息查询及操作时进行的用户身份验证的过程。其流程图如图3-3-3所示。
2.借车登记
业务流程分析：
该流程是管理员通过与系统的交互将用户的借车信息录入数据库的操作。其流程图如图3-3-3所示。
3.用户还车
业务流程分析：
还车手续办理流程为用户将车辆还回，待用户付清账单并锁车之后完成借车信息的消除，记录数据。其流程图如图3-3-3所示。
4用户付费手续办理
业务流程分析：
付费手续为用户还车后查看自己的借车记录然后进行提取相应车辆的账单信息从而付费。其流程图如图3-3-3所示：
图3-3-3借还车流程图
3.1.
4.3用例模型
描述项说明
用例名称借还车辆管理
3.2 对性能的规定
3.2.1精度
SMS对数据的精度要求是根据信息存储的形式、借车还车的结果等量化而制定的。查询时应保证查全率，所有相应域包含查询关键字的记录都应能查到；
查询时应保证查准率，查到的记录应与给定的单项或组合查询条件不完全匹配的模糊查询；
录入数据合法性的检验应当精确；
密码允许输入6-8个字母或者数字：用户输入查询信息应不区分大小写。3.2.2时间特性要求
由于此开发项目针对校园共享单车市场，使用频度较高，使用性要求比较高。为防止对信息资料和管理程序的恶意破坏，要求有较为可靠的安全性能。总之，要求稳定、安全、便捷，易于管理和操作。
1.查询速度：不超过10秒；
2.其它所有交互功能反应速度：不超过3秒；
3.可靠性：平均故障间隔时间不低于200小时。
4.响应时间：应在1～2秒内，对软磁盘和打印机的操作，以及数据的导入和导出也应在可接受的时间内完成；
3.2.3灵活性
作为独立运行的系统和其他管理系统集成的系统。SMS的设计是做为独立运行的系统而进行的。本系统具有独立的服务器系统和数据库系统，具有完善数据输入输出功能和数据维护及查询的报表生成与打印系统。且发生故障时，能快速恢复系统和故障处理，方便系统升级和扩充，故障恢复时间不超过5小时。为了适应内外机构的数据要求，与国家管理机构相关系统的数据交换，本系统专门设计了与这些系统数据交换扩展接口。本系统采用应用程序（app）标准界面，本身具有操作灵活的特点。
可能提供手机app和电脑网页双重使用功能。方便用户操作和管理。
3.3 输入输出要求
输入：
1.人工输入部分，录入各硬件设备基本信息，注册帐号输入用户信息；
2.机器输入部分，停车柱模块传入，借车停车扣费等操作；
输出：
1.用户基本信息列表，硬件设备列表；
2.自行车借还车信息统计，个人账户借还车统计，以及停车柱管理箱为
单位的使用记录统计；
3.4 数据管理能力要求（针对软件系统）
数据管理分为增加（INSERT）、修改（UPDATE）、和删除（DELETE）。
公告的信息发布的增加、修改、删除与审核控制。车辆的信息发布的增加、修改、删除与审核控制。
用户访问的信息发布的增加、修改、删除与审核控制。
3.5 故障处理要求
正常使用时不应出错，若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损。
要在项目报名时的没隔一段时间进行数据备份，以免在资料意外丢失时，无法进行恢复。
对系统故障的处理要求区分故障的严重程度，尽可能的对错误进行恢复。随时监控，在文档、报表处理，打印机，操作系统等软硬件出现故障时、具备保存数据的功能，并及时反映到主机中。
3.6 安全保密
系统对不同等级的用户提供不同的功能模块，web传输数据要求加密操作，生成严格的操作日志，以及预警提醒信息，对所有的用户资金记录应当及时备份，重复检查完整性。
4．运行环境规定
4.1设备
建议软件寿命：5年
硬件条件：PC机，手机终端
运行环境：
监控计算机：Windows xp 及以上
客户端系统：Windows xp及以上，安卓主流操作系统，ios7.1及以
上
开发软件：mySQL、MyEclipse等
开发限制：开发时间短
4.2控制
本系统初步决定采用B/S架构，用户通过浏览器或手机访问共享单车管理系统，在权限范围内对其所属信息和附件可增删改。管理员可以通过浏览器或app 管理和维护共享单车管理系统，或者远程控制软件对后台系统进行管理和维护。
5.备注
为实现充分实现信用管理，可在后期添加用户举报模块，实现全民监督，全民共享，全民作主，对于信用低的用户，可以采用收押金、罚款、设置黑名单禁用等措施处理。