第一篇:电子商务系统(java)需求分析说明书
电子商务系统需求分析说明书
一. 引言...............................................................................................................................................1 1.编写目的............................................................................................................................................1 2.背景..................................................................................................................................................1 3.定义..................................................................................................................................................1 二. 任务概述.......................................................................................................................................2 1.目标.................................................................................................................................................2 2.用户的特点......................................................................................................................................2 3.系统功能示例..................................................................................................................................2 三. 需求细则.......................................................................................................................................2 1.对功能的规定...............................................................................................................................2 2.对性能的规定...............................................................................................................................5 3.对排版的规定...............................................................................................................................5 4.对可维护性的规定........................................................................................................................5 5.对个性的规定...............................................................................................................................6 6.对项目过程的规定........................................................................................................................6
一. 引言
1.编写目的
通过与多位软件使用者进行全面深入地探讨和分析,并完成《电子商务系统》市场的前期调查后,提出了这份软件需求分析说明书。
此需求分析说明书对《电子商务系统》软件做了全面细致的用户需求分析,明确所要开发的系统应具有的功能、性能与界面,使系统分析人员及软件开发人员能清楚地了解用户的需求,并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。
本说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。
2.背景 3.定义
二. 任务概述 1.目标 2.用户的特点 3.系统功能示例
需求:
1、购物车管理
购物车内商品的增、删、改 生成订单
2、订单管理
订单的增、删、查
3、使用数据库(mysql)保存用户信息、商品信息、订单信息 用户表,商品表,订单表,订单项表
技术要求:
1、商品类
2、购物车类
3、购物项类
4、订单类
5、订单项类
6、用户类
7、应用MVC模式
购物流程:
用户登录,浏览商品页面,挑选商品加入购物车,继续浏览商品页面…… 购物车页面显示当前所购商品信息(名称、数量、价格),提交生成订单,保存到数据库中(订单表存储订单基本信息:订单号、用户名、订单总价、生成时间
订单项表存放各订单详细订单项信息:所属订单号、商品号、数量)
三. 需求细则 1.对功能的规定
分必选项和任选项,其中,必选项是必须完成的,属于项目答辩的入口条件,所有人都要做,未完成者取消答辩资格;任选项不是入口条件,但每完成一项都会加分,对于完成了必选项的同学,尽可能地多完成一些任选项,以期获得更高的答辩成绩。如果所有项(包括必选和任选)都完成,那么功能分就是满分。如果设计思路、界面效果、代码组织等方面有个性(或和别人的不同),则获得附加分。
1.1 注册、登录功能
属性:必选
描述:用户必须注册,登录之后才能使用本电子商务系统
1.2 商品浏览功能
1.2.1 商品类定义 属性:必选
描述:商品信息必须包含如下项(包括但不限于):
● ID:要求全局唯一
● 商品名称(字符串)● 商品单价 ● 商品库存 ● 商品类别
1.2.2 用户类定义 属性:必选
描述:用户信息必须包含如下项:
● 用户ID:要求全局唯一 ● 用户密码 ● 用户名
● 用户送货地址 ● 用户邮箱 ● 用户等级
1.2.3 浏览商品 属性:必选
描述:用户登陆以后能够按类别浏览商品信息。
1.2.4 数据库保存商品和用户信息 属性:必选
描述:商品信息(用户信息)能够存于数据库中,掉电后信息不丢失。必须完成下面两种情况:
在数据库中,以表的形式存放商品和用户信息。
1.3 购物车功能 1.3.1 购物车类 属性:必选
描述:购物车类必须包含如下项(包括但不限于):
● 购物项集合(购物项类类型)
● 购物总额
1.3.2 购物车功能实现 属性:必选 描述:增删改查。
● 添加购买商品 ● 修改购买商品数量 ● 删除购物项 ● 显示购物车内容
● 计算购物车内商品总价(考虑用户等级折扣)
1.3.3 购物项类 属性:必选
描述:购物项类必须包含如下项(包括但不限于):
● 商品ID
● 购买数量
1.3.4 通过购物车下订单 属性:必选
描述:根据购物车内购物项集合下订单,生成订单内容信息必须保存在数据库中
1.4 订单处理功能 1.4.1 订单类定义 属性:必选
描述:订单信息必须包含如下项(包括但不限于):
● ID:要求全局唯一
● 订单明细集合(订单明细项类型)● 订单总额 ● 下单用户ID ● 下单时间
● 订单状态(提交、审核、等待付款、发货、完成)
1.4.2 订单明细项类定义 属性:必选
描述:订单明细信息必须包含如下项(包括但不限于):
● 商品ID
● 购买数量 ● 订单ID
1.5 数据库功能 属性:必选
1.5.1 用户信息表 1.5.2 商品信息表 1.5.3 订单信息表
1.5.4 订单明细项信息表
1.6 商品评价
属性:任选
描述:购买过某商品的用户可以对该商品进行评价,评价内容保存在数据库中,用户浏览商品时可以查看评价信息
1.7 管理员后台管理模块
属性:任选
描述:管理员登录系统,查看商品库存,查看用户订单,进货处理,订单状态管理
2.对性能的规定
本系统在设计方面本着方便、实用的宗旨,性能方面应遵循如下原则: ● 执行效率(时间): 软件运行应该尽量高效;避免没有必要的循环处理、重复处理; ● 资源损耗(空间):设计尽量节约资源(内存、数组、链表等); ● 初始化: 局部变量、数组成员、内存块等都要初始化; ● 健壮性:
◎ 申请内存之后,应该立即检查引用值是否为null; ◎ 方法的入参必选进行有效性判断;
◎ switch-case一定要有default;if-else if等后要有else; ◎ 数组的下标不要发生“多1”或者“少1”操作。
3.对排版的规定
● 缩进要对齐; ● 长行拆分;
● 二元操作符的前后应当加空格,包括如下操作符:
赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”, “^” 等;
● 空行:
◎ 类声明之后、每个方法定义结束之后都要加2行空行;
◎ 逻辑上密切相关的语句之间不加空行,其它地方应加空行分隔; ◎ 一行代码只做一件事情;
◎ “if”、“for”、“while”、“do”等语句自占一行,执行语句不得紧跟其后。不论执行语句有多少都要加 “{ }”;
4.对可维护性的规定
对可维护性的最终要求:别人能够轻松上手你的代码。
● 结构清晰:
◎ 模块化:对界面(显示)、菜单管理、逻辑管理、文件操作等等代码要独立; ◎ 封装:一个模块只做一件事,模块功能要单一;一个方法不能超过50行;
避免重复、冗余代码; ◎ 代码块清晰。
● 变量命名规范,变量名应该具有自明性:
◎ 常量定义命名
常量名由全大写字母组成,单词间通过下划线来界定; ◎ 方法的命名:
使用“动词”或者“动词+名词”(动宾词组)的形式,由一个或多个单词组成且以小写字母开头,以后每个单词的首字母要大写便于界定 ◎ 变量的命名与定义
应当使用“名词”或者“形容词+名词”,由一个或多个单词组成且以小写字母开头,以后每个单词的首字母要大写便于界定。
● 注释充分:变量、方法(包括参数、返回值)、代码功能块、一些复杂算法„„等都需要
清晰明了地说明;
5.对个性的规定
把项目做出个性出来。下列各项中有和比人不同之处、或很有创意,即可认为有个性。独立设计的软件,一般都会出现一些个性。参考、抄袭不会出现个性。
● 设计思路:包括软件的整体架构、功能块的设计思路、类封装等等; ● 功能实现:从用户的角度,使用上发现与众不同的地方; ● 其它方面;
6.对项目过程的规定
本着紧张但不急躁、不参考、不拷贝的原则进行。 紧张但不慌张
项目周期只有一周,这还包括项目答辩时间。所以项目时间比较紧张,但不能慌张。要有自己明确的设计思路,一步步沿着思路走下去,以此来巩固自己所学,锻炼自己的独立工作能力。 能自己做,绝不参考别人
自己还没有做,还没有想,就去看比人的,这样尽管功能做出来了,但却没有什么意义,真正面试时还是不会。作者和读者,天壤之别。
如果自己实在无法搞定,一个问题卡了快一天了,则可以咨询别人一下想法,再行编码;尽量不直接看别人代码。 不拷贝
一旦发现拷贝,取消答辩资格。答辩时发现,答辩成绩减半。
copy别人的代码,甚至直接运行别人的代码,以此作为自己的项目进展,这是严禁的。严禁运行效果出来了,却不知道是哪些代码造成的,严禁明明是自己写的代码,但却不知道为什么这么写。
第二篇:教师工资管理系统需求分析说明书
学校内部工资管理系统
需求分析报告
系统分析员:张倩、施婷婷、毛思雨、吴园希、陈金淼
日期:2011-5-3
1、目导言
1.1 目的
为工资管理系统提供一套具有基本功能的模拟软件支持系统提供基本的需求分析和描述,为软件的开发参与者(系统设计人员、程序员、测试人员、开发商、管理人员等)提供完整的需求信息。
1.2 范围
本软件适用于我校工资系统的管理和应用,它是完善、安全、稳定的系统管理模拟软件。待开发软件系统的名称:基于Web应用的学校教师工资管理系统
本产品能具体化、合理化、安全的模拟实现基于Web应用的工资管理系统的各种基本操作。
2、系统定义
2.1 项目来源及背景
本系统是一个学校内部工资管理系统。对教职员工的基本信息和工资信息进行添加和修改,能够调整工资项目,根据需要对教职员工基本信息和工资信息的查询,本系统能够生成各个月的工资表,能够打印报表方便保存和管理,还包括对系统的一些基本操作功能,比如为完善系统管理功能,增加工资系统用户管理功能,系统应该包括系统用户数据的添加,修改和删除。教职员工为系统普通用户,只能运行系统个人工资查询功能;系统管理员则能运行系统所有功能,从而有效保证系统数据的安全性,系统应该具有简单,易用,小巧,经典的特色,应该能够对高校工资管理进行优化,使其系统化,高效化,智能化。并保证工资管理的准确性,简易性,为学校财务人员提供便利。
2.2 用户的特点
本系统的用户主要有以下几类:
教职工:提交各人信息和查询总工资表;
财务处:查询总工资表,生成正确的工作表,生成各教职工工资条; 人事处:提交人员变动情况,制定奖惩实施细则,生成可变工资; 学校各部门:提交出勤情况,提交业绩情况,读取工资条。
本软件的使用对象是我校全体教职员工,必须通过IE浏览器访问该系统,然后再登陆页面输入正确的用户明和密码方可使用(即成功登陆)。
3、功能规格
3.1 角色定义
角色或者执行者指与系统产生交互的外部用户或者外部系统。
3.1.1 教职工
学校教职工通过系统可以实现以下使用需求:提交个人信息,登陆修改个人信息,查询个人工资各项详情。
3.1.2 财务处
学校财务处可以通过系统实现以下需求:读取工资表,生成正确工资表及查询工资情况。
3.1.3 人事处
学校人事处可以通过系统实现以下使用需求:输入教职工调动信息,读取教职工出勤及业绩情况,制定奖惩实施细则,生成教职工出勤工资、奖金及扣款清单。
3.1.4 学校各部门
学校各部门可以通过系统实现以下使用需求:给出教职工出勤情况,给出教职工业绩考核情况,读取各部门汇总表,得到工资条。
3.1.5 数据库数据库是一个与系统产生交互的外部系统,这个角色负责系统的数据查询、增加、删除、和修改等操作。
3.1.6 学校人事处
在学校教师工资管理系统中,管理员可以提交人员变动,提交可变工资(统计出勤工资、奖金及扣款项目),制定奖惩明细,查询工资表。具体描述如下。
用例描述:学校人事处管理; 执行者:学校人事处;
前置条件:人事处管理者已登录系统;
后置条件上:如果人员和工资产生变化,则数据库中的随之变化。基本路径:
登录成功,进入管理界面。
然后根据选择不同的操作分别进入不同状态,如:选择提交人员变动,可以对员工调入、调出、校内调动、离退休等数据进行修改,进入的状态为一个系统
反馈的信息表。若选择提交可变工资,则会再次给出选择分别进入状态为:出勤工资表,奖金表后者扣款清单表。
根据相应选择查询不同信息。查看信息完毕后,最后退出系统。
在学校教师工资管理系统中,财务处管理员可以查询工资表,然后每月月底将教职工的工资表做好并将数据送往银行。每月初(3日前)将工资条发给各单位。具体描述如下。
4、性能需求
4.1 界面需求
1.以通信功能作为界面设计的核心
人机界面设计的关键是使人与计算机之间能够准确地交流信息。一方面,人向计算机输入信息时应当尽量采取自然的方式;另一方面,计算机向人传递的信息必须准确,不致引起误解或混乱。
2.界面必须始终一致
统一的人机界面不致于会增加用户的负担,让用户始终用同一种方式思考与操作。最忌讳的是每换一个屏幕用户就要换一套操作命令与操作方法。
3.界面友好、使用方便
4.2 响应时间需求
系统能设置登录等级,对于使用服务器端工作者可以先行响应;
4.3 开放性需求
一个优秀的软件应该提供在线求助功能,甚至提供使用向导,这将给用户带来极大的方便。在多媒体环境下,以语音提示作为操作向导,不会干扰屏幕信息,是一个极佳的选择。
4.4 可扩展安全性需求
系统对要提供与读取信息的用户进行身份验证,登录后各员工只能可以看到各自工资详情;
第三篇:《社团管理系统》需求分析说明书
系统的前台浏览功能需求
(一)游客的功能
(1)注册成为会员
(2)信息查看,包括公告信息,和各协会活动的情况,照片,视频和文章等
(3)可在交流区浏览帖子
(4)可以留言提出意见或建议
(二)协会会员的功能
(1)会员登录
会员使用自己注册的用户名和密码登录
(2)站内信
有任何活动的发起给改协会成员发送站内信,会员有任何疑问也可以通过站内信进行交流
(3)留言
可以留言提出意见或建议
(4)加入新协会
每个会员都可以加入一到三个协会
(5)查看活动历史
协会成员可以查看历史活动,包括协会活动的所有有关的文档
(6)信息查看
协会认为介绍主要介绍会长和副会长
(7)交流区
协会会员可以发表主题,并可以回复评论
(8)上传,下载
协会会员可以上传下载图片和视频
(9)新协会申请
会员可以申请注册新协会
(10)协会注册
协会根据规定进行学期注册
(三)协会会长功能
(1)协会会长包括协会会员的所以功能
(2)会员管理
会长可以进行协会会员的添加删除查询等
(3)申请活动
申请活动必须填写活动申请单
(4)填写海报单
为每次活动出海报填写海报单
(5)活动通知
活动审批通过后,系统自动通知协会会员有
(6)活动评分
每次活动会长都必须给自己组织的活动进行 评分
(7)系统设置
会长可以对自己协会页面的相关内容进行设置
(8)飞信功能子系统
为确保活动通知到位,设置的附加功能
(9)协会换名
协会换名必须填写换名申请单
(10)协会外请教师申请
申请外教必须填写外请教室申请单
(11)十佳学生社团申请
十佳学生社团申请须填写厦门理工学院十佳学生社团创建申报表
(12)外出活动申请
外出活动需填写外出活动申请表
(13)周末文化大舞台
周末文化大舞台分单项节目申请表,专场活动项目申请表
系统的后台管理需求
一.社团部管理
(一)部长功能
(1)部长审核新协会的申请:
部长对新协会申请的条件进行审核,审核通过后提交给社团部老师审核。
(2)部长对协会注册的审核:
各协会每学期需进行注册,部长对协会的注册条件进行审核,审核通过后提交给社团部老师审核。
(3)审批社团外请教师:
协会会长填写“社团外请教师申请表”后,提交给部长,由部长对具体内容进行审核。
(4)部长对工作时间的设置:
对整个社团部的工作,进行时间的控制,如:
1、活动必须在周几之前提交申请,2、由部长必须在周几审批活动,然后提交社团社团老师,3、再由社团部老师必须在周几进行审批,超出规定的时间,将不能进行活动申请。
(5)审批活动申请:
对协会申请的活动进行审核,主要对活动申请表事项的审核,活动预算经费重点关注,应填写详细,包括宣传经费等。
(6)审核活动质量汇报单、并评分:
会长审核完后,汇报单提交给部长,再由部长进行审核,主要针对各协会秘书、秘书组长、会长的意见内容。
提交前,并对此次活动进行评分,总分10,对应栏位后面有个下拉列表框,可选择分数。
(7)协会分类管理:
部长可根据协会的定义,对协会原本类型进行修改,也可添加新类型、删除类型。
(8)协会分级管理:
部长可根据协会的学年来的表现、活动总分数,对协会级别进行评定后录入,并可进行修改,也可添加新级别、删除级别。
(9)协会风采挑选:
部长可进步各协会界面,对所上传的活动照片进行挑选后,关联发布到社团部首页的社团风采展示区。
(10)审批学生社团换名:
协会会长填写换名申请表格,提交给部长,部长根据情况进行审批。
(11)协会解散、恢复审核:
部长对不符合协会条件的,可进行解散功能、恢复功能。
(12)部门管理与干事考评:
对各部们成员、协会会长(包括副会长)的管理:包括人员的录入、修改、删除; 期末总结:对副部、各组长、各协会会长进行综合考核评语、评分;
对所有人考核完后,提交给社团部老师审批。
(13)各组干事的考核审评
各组组长对各组干事进行考核后的评语、评分提交给部长后,让部长进行审批。
(14)站内信:
进行通知交流功能,可接收社团内部通知和活动通知,也可给社团内部所有成员发布信息。
(15)飞信功能子系统:
在对应的账号里,嵌入飞信功能模块,方便部长在一些工作上采用短信息通知,如:召开例会时间通知等。
(二)秘书组功能
(1)随机指派秘书跟踪协会活动(秘书组长的功能):
每个协会的每次协会活动,由秘书组长随机指派2个秘书去跟踪协会活动;
(2)填写质量汇报单、并评分:(各协会秘书)
由分派的的协会秘书,在活动过后进行填写质量汇报单,填写完后,点击“提交按钮”,提交给宣传组长。
(3)审核质量汇报单、并评分:(秘书组长)
各协会秘书将提交质量汇报单给秘书组长后,秘书组长对质量汇报单进行审核。
(4)秘书组干事考核:
对本组成员的管理,包括人员的录入、修改、删除;
期末总结对每个干事进行综合考核评语、评分;
对所有人考核完后,提交给部长审批。
(三)宣传组功能
(1)指派宣传成员出海报(宣传书组长的功能):
每个协会的每次活动,提交海报单以后,由宣传组长指派成员去海报;
需设置成员与相应协会关联。
(2)审核海报:(宣传组成员)
对分配到的海报任务进行审核收集、修改。
(3)秘书组干事考核:
对本组成员的管理,包括人员的录入、修改、删除;
期末总结对每个干事进行综合考核评语、评分;
对所有人考核完后,提交给部长审批。
(四)外联组功能
(1)审核赞助事项:
如协会申请的活动需要经费赞助,在提交《活动申请书》时,需同时附加《活动赞助策划书》,方便外联组长对申请进行审核。
(2)赞助商信息发布:
如果通过审核的活动,将活动策划书发布到网站上,方便赞助商浏览;
同时如果有赞助商想进行赞助,可联系外联组长或者部长。
(3)外联组干事考核:
对本组成员的管理,包括人员的录入、修改、删除;
期末总结对每个干事进行综合考核评语、评分;
对所有人考核完后,提交给部长审批。
(五)办公室功能
(1)打印活动总单(社团留档管理):
打印内容包括:活动申请单、活动质量汇报单、活动总结(从活动申请到活动结束整个过程文档)
(2)例会内容填写:
对每周的例会,进行记录整理后,上传到网站上,方便工作人员浏览。
(3)办公室干事管理与考核:(关系期末加分)
对本组成员的管理,包括人员的录入、修改、删除;
期末总结对每个干事进行综合考核评语、评分;
对所有人考核完后,提交给部长审批。
(4)飞信功能子系统:
在对应的账号里,嵌入飞信功能模块,方便办公室在一些工作上采用短信息通知,如:召开例会时间通知等。
(5)注意事项提醒:
系统自动检测部长、社团部老师、宣传组长、秘书组长、外联组长(下称工作人员)未登录时间;
在规定的时间内未登录,则发送站内信给办公室成员;
检测各工作人员账号的站内信状态,如果有信息,则用飞信自动通知,否则不通知; 飞信自动通知后,返回发送提示,如果未发送成功,则办公室人员手动通知。
(6)通知各协会、宣传组活动教室地点:
(7)收集各部门人员名单,分类收集:
(六)网络部功能
(1)社团网站维护后台子系统(对应页面管理内容+附加内容):
(2)页面风格设置:
(3)校园音乐广播:
(4)网络部干事考核:
二.教师管理
1、社团部老师
(1)站内信:
进行通知交流功能,可接收社团内部通知和活动通知,也可给社团内部所有成员发送信息。
(2)审核新协会申请:
部长对新协会申请的条件进行审核,审核通过后提交给社团部老师,再由老师进行审核。
(3)审批协会注册:
各协会每学期需进行注册,部长对协会的注册条件进行审核,审核通过后提交给社团部老师审核。
(4)审批活动申请:
部长对协会申请的活动进行审核通过后,提交到老师这边,再由老师审核。
(5)审批社团外请教师:
协会会长填写“社团外请教师申请表”后,提交给部长,由部长对具体内容进行审核。
(6)审批学生社团换名:
部长根据协会会长填写换名申请表格,审批通过后,由老师再次进行审批。
(7)审核质量汇报单,并评分:
由部长进行审核后,提交给老师进行审核,(8)社团成员查询:
可查看社团部各部门名单及相应职位,与各协会成员名单及相应职位,但不能进行修改等操作,此功能由社团部工作人员进行操作。
(9)社团部门组织管理:
可对社团内各部门进行增、删、改,方便今后社团的组织结构变化。
(10)协会解散、恢复审核:
不符合协会条件的,部长审核后,提交给老师再次进行审核,可进行解散功能、恢复功能。
(11)部门干事考核审评:
通过部长将部门干事的审评后的结果提交给老师,让老师进行再次审评:
老师审评对象:部长、副部长、各部们组长、协会会长(包括副会长);
审评内容:进行综合考核评语、评分;
对所有人考核完后,提交给社团相应成员。
2、团委书记
审批外出活动:
第四篇:车队管理系统需求分析说明书
车队管理系统需求分析书 基本档案
1.1 公司信息管理
名称、营业范围、联络方式、其他
1.2 车辆信息
车辆基本信息
车辆资料的添加、修改、删除、导出、打印:记录车辆的基本信息,包括车辆编号、车牌号码、发动机编号、车辆颜色、车辆类型、载客数量、营运种类、营运证编号、所属公司、部门、车队(组)、备注其他。 车辆购买信息
厂牌型号、出厂日期、购买店家、购买日期、购入价格、购置税及其他费用。
1.3 司机信息
司机基本信息
编号、姓名、性别、出生年月、家庭电话、移动电话、住址、驾驶证号、准驾车型、驾驶证核发日期、发证机关、驾驶证有限期、就职时间等 司机违章信息
时间、地点、描述、其他。
1.4 人车配属关系
车与驾驶员的关联关系,一辆车对应1或多位驾驶员。
1.5 站点管理
行车站点资料维护、统计查询
1.6 线路管理
行车路线统计维护,查询
1.7 电子围栏设置
设置电子围栏相关信息
行驶范围:车辆有规定的营运范围;
电子围栏:把行驶范围转换成电子围栏,支持矩形、圆形等区域
1.8 其他
用户、车队、组织、部门、权限管理等。车辆监控
Inhand GPS可以为我们提供经度、纬度、速度、航向四个参数。
基于GPS,我们可以实现的主要功能:车辆定位、车辆实时轨迹、车辆行驶里程(obd)、历史路线、数据分析报表等。
注:以下截图中有些参数需要obd上传,可以不用考虑。
2.1 车辆定位
某车某时在某地。
2.2 车辆实时监控
车辆实时位置、速度、航向、及其他车辆参数。
2.3 历史路线
随时清查指定车辆某时段运行状态的详细运行轨迹线图以及轨迹回放。
2.4 轨迹明细
列表显示过去某天某车辆状态,包括车辆信息、位置、回传时间、当前速度(回传时)、方向等。运营管理
3.1 司机与车辆调度
司机考勤、身份识别
3.2 车辆年检
年检记录、年检提醒
3.3 加油管理
外地加油、定点加油、内部加油站管理。加油的日期、车辆、油量、费用等。
3.4 维修管理
维修申请、审批、维修记录
3.5 保险管理
保险记录 保险提醒
3.6 保养管理
保养记录(申请、审批)保养提醒
3.7 安全管理
车辆事故记录、驾驶员违章记录等
3.8 预警提醒
车辆年检到期提醒 车辆保险提醒
车辆保养提醒 车辆超速提醒 车辆越界提醒
3.9 费用管理
行车费用管理、加油费用管理、维修费用管理、保险费用管理、年检费用管理、其它费用管理
3.10 其他方向
1、培训以及培训资质相关
2、CRM(客户关系管理)相关
客户管理、合同管理等
3、供应商相关
供应商记录、供应商合同、供应订单、零售件(轮胎)等
4、汽车租赁业务 统计报表
4.1 位置报表
疲劳驾驶统计:车辆持续运行2、4、6以及其他判定为疲劳驾驶等。
疲劳驾驶明细表、疲劳驾驶日报表、疲劳驾驶月报表。
停车统计报表:可随时查找某车辆在任一时间段内的停车时间和停车地点,并可生成报表。
停靠超时统计:车辆停靠某位置超过指定时间,则判定为停靠超时。
里程统计: 根据行驶路线,统计当日里程和月里程,同时支持数据报表导出、打印、其他。
车辆利用率:车辆是否到达某一站点。
里程、油耗都是通过obd上报,里程如果根据GPS计算,不确定是否可以计算,计算结果是否精确。
车辆运行状态(ACC)也是obd连接车载电脑获取状态码来判定行驶还是熄火。通过gps的速度区分,获取到的数据都不精确。
以上功能报表勉强沾边。
超速、时速统计:车辆管理系统自动统计出某段时间时速排名。 偏离航向统计:统计某些车辆没有按照固定轨迹运行。
可以将该部分报表划分到报表管理模块
4.2 运营报表
综合费用统计 车辆保险信息统计 车辆年检信息统计 车辆事故信息统计 行车信息统计 车辆维修信息统计 其他费用信息统计 车辆档案查询 驾驶员档案查询等
第五篇:学生公寓管理系统需求分析说明书
学生公寓管理系统需求概况
在学校面向现代化、面向世界、面向未来、面向互联网的21世纪,现今社会是一个讲究效率的社会,人们有很强的时间观念,如果仍使用手工操作或使用相当繁琐的软件,既浪费了人力,又浪费了物力,效率无法提高,尤其是在学校里。为此开发学生公寓管理系统软件,能够适应现今社会并提高生产效率。该系统软件非常容易被接受,它具有简单易学性,双重操作管理体系,便于管理等功能。它是对学校学生管理的一种工具。为使校园网得到高效、合理的利用,以教育信息化带动教育的现代化,加强学校信息管理,将建设成信息化、现代化的新校园,为新世纪的交院增添新气息、树立新形象,学校于2008年全面启动信息化建设工程。
一、主要功能
1、系统管理
(1)用户设置与权限分配(2)公共数据管理
2、公寓房源管理(1)定义房源信息(2)定义房间设施信息
3、公寓住宿管理(1)学生住宿登记(2)调退房登记(3)设施损毁登记
4、公寓分配管理(1)学生分配住房(2)学生调退房处理
5、公寓财务管理(1)预交费用(2)费用结算
6、报表管理(1)财务报告
(2)学生住宿情况统计报告
7、数据检索(1)房源检索(2)学生住宿检索(3)费用检索
二、用户类别
1、系统用户(系统管理员)
2、房源定义用户(公寓管理中心)
3、住房分配用户(系部)
4、住宿登记用户(公寓管理员)
5、财务用户(后勤财务)
三、业务流程
1、初始化处理(1)系统用户定义各类用户及其权限(2)公寓管理中心定义房源
(3)公寓管理中心定义住宿费用已经房源设施及价格(4)公寓管理中心给各系部分配房源(5)对已分配房源但未住宿登记的房源初始化
2、学生住宿处理流程(1)学生到系部分配房间(2)学生到后勤财务交预付款(3)学生到公寓管理员登记住宿
3、学生调房处理流程(1)学生到系部申请调房(2)学生到财务处理住宿费用(3)学生到公寓管理员登记调房
4、学生调房处理流程(1)学生到系部申请退房
(2)学生到公寓管理员登记退房(注意设施损毁登记)(3)学生到财务结算费用(根据预交费用与实际住宿费用结算)
四、相关报表及凭据(1)学生收费收据(2)班级住宿名册
(4)年费用结算报表(按)
(5)房源报表(空置房、房源分配情况、房源登记情况)(6)设施损毁报告(按、按设施类型)(7)房间住宿人员台账(按指定区间)(8)学生住宿情况台账(按指定区间)