第一篇：车辆管理需求分析
公车管理系统需求分析
1、背景
今年要进行公车管理，以后全市公务人员派车需要进行申请和审核，为提升整个公车的管理水平、公车流转速率、时效性，需要建设一个统一的信息化平台来对所有公车进行管理。
2、项目对象和内容
130辆公务用车，全部安装GPS，后台建设一个综合管理平台，能够调度车辆、管理车辆、实时监控车辆，同时管理驾驶员绩效和出勤以及油卡。
3、业务流程及功能需求（1）用车业务：
用车人发起用车申请（直接电话给调度中心）调度中心录入用车人信息（姓名、单位、电话、用车事宜、用车时间、到达地点、接人地点等）查调空车和对应司机，并配备油卡（也可能不配备油卡）系统生成派车任务（短信通知申请人，车牌，司机号码，将于什么时候到哪接人，同时告知他用车完毕后可以回复短信对本次用车打分）人工通知司机接人调度员全程可实时监督车辆运行情况（有热键可查看该次行车中的实时信息）申请人回复满意度，系统记录纳入司机绩效考核（不回复则默认满意）司机回单位还车调度员系统结束任务，回收油卡，填写加油金额。（2）司机管理：
司机管理模块，记录司机的信息（姓名、年龄、电话、驾驶证号、工号等），司机的相关信息可以修改、删除、新增。
每天调度人员对上班司机进行排班管理（也可以通过导入排班表格的形式设置一周/一个月的初始排班），同时该信息在用车业务派单时可以显示该司机的状态（在班空闲、在班出车、不在班、请假、休假），派车时优先选择在班人员，但不在班、请假、休假也可以派任务，在班出车状态不可再被派发任务。
在用车业务功能中生成了用车任务后，司机日常管理中自动生成相关记录（什么时间出了什么任务，对应车辆是什么），在用车任务结束后自动插入信息（什么时候结束任务的，耗时多少，评价是什么），有热键可查看该次行车中的实时信息。
司机调班或请假，在系统中生成记录（什么时候，因为什么请假，请假时长，代班人员是谁），同时初始排班表自动更改，派车任务时司机显示状态也发生改变。休假的也一样（只是原因就变成了休假）。该请假的方式考虑两种情况，一种是司机手机上装个APP实现请假填报，调度员审核通过系统自动改（这里要包含请假和休假两个流程），一种是司机给调度员人工联系，调度员自己进系统改，先考虑后一种模式，但第一种的接口也要预留。最终可以可以导出绩效管理表格。（3）车辆管理
车辆有基础数据库，一车一档（牌照、行驶证、品牌、车型、空间大小、购车年限、保养信息、年审、保险），可以新增、修改、删除；
当用车业务发起派车后，该车辆自动生成出车记录（什么时间出了什么任务，对应驾驶员是谁），该车状态改为出车（状态为空车、出车、检修、维修四），只有在空车期间才能被指派任务，任务结束后自动生成记录（什么时候结束任务的，耗时多少）该车状态改为（空车），有热键可查看该次行车中的实时信息。
车辆维护和检修，会指定维护厂，给维护长输入的APP终端软件，修理厂先选择车辆是日常检修还是事故维修，然后可以直接将车辆的问题、进修理厂时间、送达人员姓名、电话、维修现已经维修到哪一步、什么时候可以出厂、出厂接车人姓名、电话、出厂接车时间、维修金额进行实时更新，调度员可以实时了解车辆的状态，在检修和维修阶段，车辆状态自动为检修和维修，不可被派发任务。
车辆管理中有每辆车有对应的加油记录查询热键，可以看到该车所有的加油明细，该部分数据来源于加油管理。（4）加油管理：
本次业主的加油全部为中石化的加油卡，业务流程是卡给出车的驾驶员，每次驾驶员用卡加油，然后回来上交。因此，首先要有油卡基础信息库（油卡卡号、充值金额、当前余额），可以修改、新增、删除，当出车配备油卡时，油卡状态改为出库（油卡有出库、在库两种状态），出库油卡不能再配发，油卡出库后自动关联任务生成记录（对应时间、驾驶员、车辆、任务），加油入库后，调度员后台输入加油金额，加油地点【可以不填】，自动生成余额。
加油卡也可以不通过出车业务分配，调度员可以直接将油卡分给司机，填入出库记录（什么时间出库、给谁了、电话号码、分派人是谁），入库时候填写入库记录（什么时间入库、谁接收的、用了多少钱、加油地点【可以不填】），自动生成余额。
充值后调度员后台平台找到对应卡，输入充值金额，自动生成余额。可以导出表格，包括油卡的交易明细表。
在该部分后期将会和中石化对接，加油的信息将会自动传输到后台，即出卡流程一样，但加油的时候如果是在加的油，中石化会将金额和卡号直接传送过来，本系统自动记录并处理，外加的油，还是按照上述流程处理。该功能为本项目的一部分，只是在中石化没做好之前，可以本功能不使用，什么时候中石化做好，什么时候对接。（5）调度员
调度员每个人有自己的账号，账号关联调度员姓名、手机、密码等，可以新增、删除调度员，可以修改密码，可以查询自己的调度记录。以上派车、油卡、维护等功能每个任务的生成、结束、接受，系统都自动记录操作的调度员信息，以备后查。
4、其他需求
前端加装GPS定位设备，要高大上一点，业主明确不能给电动车的那个装备，设备要隐蔽安装，安装由提供厂家负责；
后台有实时监控地图界面，中心先采用电脑加一台液晶电视的方式显示，大屏暂不考虑；
5、文档要求
文档组成一定要有如下因素：
背景（为什么干这个事情，要干成什么样子）； 总体设计（一定要有软件总体架构图和网络架构图）；
功能设计（要清楚的列出每个功能点和模块，并做相应说明，硬件参数也最好说明）； 报价（报价一定按照功能点做一个报价表，详细到每个功能模块多少钱，再就是网络运营费用及硬件费用）.
第二篇：合同管理-需求分析文档（模版）
合同管理需求分析 需求描述：
合同与招标管理主要实现对合同项目的立项审批、招标、合同以及竣工验收的全过程管理。该系统主要由合同项目管理、招标管理、合同管理、客户管理和灰名单管理等几个模块组成。
流程图：
合同管理流程图合同管理外包工程合同项目申请招标否自动创建项目合同项目审批招标书拟定标书签收登记评标报告申请评标报告审批合同申请招标记录填报谈判纪要录入资质与安全协议审查合同拟定付款申请合同记录人员管理合同终止现场管理合同变更竣工/质保验收申请竣工/质保验收审批结束 3 项目管理
3.1 项目申请：
合同项目管理是指所有需要签订合同的项目都要在此进行申请。由各个部门的专工或主任提出申请。
合同项目申请又分为未运行、进行中和已完工。后两者是属于后补项目，后补项目必须增加先履行原因。
合同项目的属性包括：项目编号、申请日期、后补类型（生产抢修、超过50万已书面报分公司同意、后补或不招标超过10万已书面报总经理同意）、项目状况（未进行、进行中、已竣工）、申请方式（招标、不招标）、项目名称、项目性质（新签、续签、变更、终止、补充）、资金来源、项目预算、费用管理部门、项目类型（技术服务、土建、维修、软件等）计划开工时间、计划竣工时间、申请理由、申请人、申请部门、申请部门主管、不招标理由（有多条理由显示，直接让用户勾选）、项目内容、工程量及物料人力资源情况。
合同项目申请时需要填写承包商推荐会签表，需要招标的项目至少选择5家，不需要招标的项目至少选择3家；如果选择的承包商单位不足则需要在【备注】中填写理由。合同申请的界面原型如下：
3.2 项目审批：
项目申请提交后，由各级进行审批，其中系统约定72小时，如果超过72小时，则系统自动推进，无需他在签字审批。但是要在系统中列明原因：“该记录已超过72小时，系统自动推进！”。如果是部门专工提出申请，则还需要部门主任审批，审批后由项目主管部门审批报公司分管领导审批，对于超过多少金额的还需要报总经理审批。对不同类型的项目，主管部门可能不一样，例如生产项目的主管部门是设备部，非生产项目的主管部门是经营计划部。项目审批的界面原型如下：
项目验收
项目验收分为: 竣工验收单、质保验收单和阶段验收单。
验收单包括：验收日期、验收单类别（竣工、质保、阶段）、项目名称、资金来源、项目预算、履行地点、开工日期、竣工日期、质保金截至日期、甲方名称、乙方名称、项目摘要内容、评价等级、合格/不合格、客户评价（符合合同要求、不符合合同要求、达到预期目标、未达到预期目标、可以投入使用、不可以投入使用、质保期质量无问题、质保期有问题）、填写人、填写时间、填写部门、附件。
竣工验收单申请：
由项目负责部门提出竣工验收申请。
竣工验收单审批：
竣工单申请后，经过各级审核通过后，就将该系统置为已竣工。当超过72小时候没有审批就自动推进。
质保验收单申请：
由项目负责部门提出竣工验收申请。
质保验收单审批：
质保单申请后，经过各级审核通过后，就将该系统置为已竣工。当超过72小时候没有审批就自动推进。
阶段验收单登记：
由项目负责部门登记所有阶段验收的记录。
如果项目是来自于外包工程，所有的验收记录和质保记录同步保存到外包工程的记录中。项目验收的界面原型如下：
招标管理
对于需要招标的项目，应该进行招标。招标管理主要是做好三个方面的工作：分别是招标拟定，标书签收登记以及项目评标报告。这三个节点只有在评标报告审批时必须要做的。
4.1 标书签收登记：
标书签收登记就是登记签收标书的投标方单位。由项目负责单位登记所有投标方单位，并记录投标单位名称，投标时间，投标金额，联系人及联系电话。界面原型如下：
4.2 招标书拟定：
招标书拟定就是下载招标书模板后，根据模板要求填写各项数据上传到系统中。
4.3 工程评估报告申请：
由项目负责部门提出工程评估报告申请。
工程评标报告属性：项目名称、资金来源、项目预算、参与投标单位（序号、公司名称、投标报价、资质）、评标意见、综合排序（将投标单位排序）、拟中标单位、中标金额、参与人员、备注、申请人、申请时间、申请部门、各种附件。工程评估报告申请的界面原型如下：
4.4 工程评估报告审批
项目评估报告提出申请要经过审批，经过审批后才发布。由各级领导进行审批，各个上传的附件应直接在屏幕上显示出来。对于超过72小时未审批的要自动推进。
工程评估报告审批的界面原型如下：
合同管理
合同管理包括：合同申请审批、合同拟定、合同谈判纪要、其他付款、付款申请审批、合同变更、合同终止等管理。
5.1 合同申请：
合同申请审批是由合同起草人或项目负责部门提出申请。合同申请的属性有：合同名称，合同编号，合同性质，合同类型，资金来源，合同金额，项目预算，所属项目，签约单位（我方）（承包部门，部门负责人，承办人），签约单位（对方）（承办人，承办人联系电话）,签约时间，签约地点，备注，附件，申请部门，申请人，申请时间。
合同申请的界面原型如下：
5.2 合同审核：
合同申请由项目负责部门提出后，经过部门主任审批、主管部门领导审批、公司领导审批后通过（具体流程可以灵活设置）后生效。合同审核的界面原型如下：
合同拟定
通过下载【合同模板】后，填写合同内容上传拟定好的合同文本到系统中。合同拟定的界面原型如下：
5.4 合同谈判纪要
合同的谈判纪要是在系统中录入合同谈判的纪要内容。合同谈判纪要的界面原型如下：
5.5 付款申请
由项目提出部门提出付款通知单，并经过相关部门和公司领导审批。一个项目可以多次付款。超过总金额后就不能再付款了。系统应该要有剩余质保金的到期提示。付款申请的界面原型如下：
5.6 付款审核
合同付款审核的界面原型如下：
5.7 其他付款
其他付款是申请付款通知单的一种，是多那些没有按正规流程办理的项目的付款。其他付款的界面原型如下：
5.8 合同变更
由项目负责人根据合同的实际情况可以对合同进行变更，需要填写变更原因，记录好变更的时间。合同变更的界面原型如下：
合同终止申请
当合同有效时间到达时，合同自动终止，或者因为其他原因可以由项目负责部门提前终止合同。合同终止申请的界面原型如下：
5.10 合同终止审核
项目负责部门提出合同终止申请后，需要通过各级部门审核通过后才能终止合同。合同终止的审核的流程需要通过工作流来进行配置。
合同终止审核的界面原型如下：
客户管理
合同管理中的承包单位统一在【承包商】模块中进行管理，创建合同项目时自动将对应的承包商信息保存到【承包商】模块中。
第三篇：车辆管理系统需求规格说明书
车辆管理系统
软件需求规格说明书
班 级 08软工A1 拟制人 舒骥
2011年05月10日
目录
1引言.............................................................................................................................1
1.1编写目的.........................................................................................................1 1.2 背景................................................................................................................1 1.3 预期读者........................................................................................................1 1.4参考资料.........................................................................................................1 2综合描述.....................................................................................................................2
2.1产品目标.........................................................................................................2 2.2产品功能.........................................................................................................2 2.3用户范畴和特征.............................................................................................2 2.4运行环境.........................................................................................................3 2.5设计和实现限制.............................................................................................3 2.6 假定和约束....................................................................................................3
2.6.1人力资源约束.....................................................................................3 2.6.2技术约束.............................................................................................3 2.6.3环境约束.............................................................................................3
3外部接口需求.............................................................................................................4
3.1用户界面.........................................................................................................4 3.2硬件接口.........................................................................................................4 3.3软件接口.........................................................................................................4 3.4通信接口.........................................................................................................4 4功能性需求.................................................................................................................4
4.1功能分析.........................................................................................................4 4.2用例图.............................................................................................................5 4.3用例分析.........................................................................................................9 4.4功能活动图...................................................................................................19 4.5状态图...........................................................................................................21 5非功能需求...............................................................................................................22
5.1性能需求.......................................................................................................22
5.1.1时间、界面、响应要求...................................................................22 5.1.2灵活性...............................................................................................22 5.2数据管理需求...............................................................................................22
5.2.1系统数据流图...................................................................................22 5.2.2数据整理与保存...............................................................................24 5.2.3数据安全性.......................................................................................24 5.3故障处理需求...............................................................................................24
1引言
1.1编写目的
需求说明的编写是为了研究车辆管理软件的开发途径和应用方法。同时它也是进行项目策划、概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。本文档将对车辆管理系统软件开发需求进行描述。
1.2 背景
物流系统是现代经济系统的主动脉，物流的最简单理解就是货物运输，所以运输在物流运作中的地位十分重要，而车辆是运输企业的命脉，有机的管理好车辆十分关键。传统的运输业已不能满足市场需求。运输企业的信息化管理具有重要意义。
开发软件名称：车辆管理系统 项目开发者：08软工A1 舒骥 用户：运输集团公司
1.3 预期读者
本需求的预期读者是开发组成人员，软件测试人员，支持本项目的老师，软件维护人员。
1.4参考资料
[1].《软件需求工程》 毋国庆 梁正平袁梦霆 李勇华 编著[2].《UML基础与Rose建模教程》 蔡敏 徐惠惠 黄炳强 编著
[3].《C#数据库系统开发完全手册》 明日科技 张跃延 许文武 王小科 编著
[4].《软件工程实验与实践教程》 陈佳 曹妍 编著 [5].《实用软件文档写作》 肖刚 古辉 程振波 张元鸣 著 2综合描述
2.1产品目标
车辆管理系统将为企业提供各种车辆管理和快速查询的功能，以提高公司的运作效率，降低运作成本。
2.2产品功能
* 车辆基本信息管理 * 车辆购置管理 * 车辆调拨管理 * 车辆报废管理 * 车辆信息管理查询
2.3用户范畴和特征
本软件最终用户为汽车运输集团公司。该公司主要设有技术服务部、客货运输部、企业管理部等职能部门，下属运输公司有零担运输公司、客运公司、整车运输公司、旅游公司等，其组织结构如下图1：
图1：运输集团公司组织结构图
2.4运行环境
运行该软件所适用的具体设备必须是奔腾
4、内存512MB以上的计算机。操作系统在Windows xp及以上。
数据库为SQL Server2000版本
2.5设计和实现限制
仅设计为本地版本，无需联网，没有服务器端。
2.6 假定和约束
2.6.1人力资源约束
1、开发工作量约需1个人2月工作量。开发完成后，可减少为1名作为维护人员；
2、辅导老师1人，开发人员2人。
2.6.2技术约束
本项目的设计是在ASPAsp.Net程序设计语言的条件下进行的，技术设计采用软硬一体化的设计方法。
2.6.3环境约束
运行该软件所适用的具体设备必须是奔腾
4、内存512MB以上的计算机。操作系统在Windows xp及以上。
3外部接口需求
3.1用户界面
见《系统设计说明书》
3.2硬件接口
考虑到大量数据的备份等要求，需要保持与磁带机、光盘刻录机及USB的接口，这较易实现。
3.3软件接口
这里，主要考虑软件与操作系统、数据库管理系统的接口。由于不存在从其他文件导入的功能，所以无需担心格式转换的问题。该软件更趋向于单一封闭的单机版软件。
3.4通信接口
无需与网络连接，只需考虑与外部移动设备的通信。
4功能性需求
4.1功能分析
1、车辆基本信息管理模块
(1)用户的登录管理：不同级别的用户通过特定的用户名和密码登录系统，对相应的信息进行管理。
(2)查询车辆基本信息：通过输入车辆的基本信息对车辆的整体信息进行查询。(3)删除车辆基本信息：有相关权限的用户可对某些不再需要的车辆信息进行删除。
(4)修改车辆基本信息：有相关权限的用户如有必要，可对车辆的基本信息进 行修改。
(5)添加车辆基本信息：有相关权限的用户可添加车辆的基本信息。
2、车辆购置管理模块
用户可添加、修改、删除、查询车辆购置管理申请单，然后交由总工程师申请审批，如通过再有总经理申请审批，实现二级公司要提交车辆的购置申请，集团公司职能部门根据车辆的产权归属，由总工程师或总工程师及总经理对申请进行审批，生效后产生调拨单下发所属公司及各有关部门。
3、车辆调拨管理模块
与车辆购置管理类似，用户可添加、修改、删除、查询车辆调拨管理申请单，然后交由总工程师申请审批，如通过再有总经理申请审批，实现二级公司要提交车辆的购置申请，集团公司职能部门根据车辆的产权归属，由总工程师或总工程师及总经理对申请进行审批，生效后产生调拨单下发所属公司及各有关部门。
4、车辆报废管理模块
与车辆购置管理类似，用户可添加、修改、删除、查询车辆报废管理申请单，然后交由总工程师申请审批，如通过再有总经理申请审批，实现二级公司要提交车辆的购置申请，集团公司职能部门根据车辆的产权归属，由总工程师或总工程师及总经理对申请进行审批，生效后产生调拨单下发所属公司及各有关部门。
5、车辆信息查询管理模块
实现对多种信息的快速模糊查询，可根据车辆所属的二级公司，车牌号，车辆的厂牌，规格，型号等信息进行不同的组合来查询车辆，还可根据申请购置，调拨，报废车辆的二级公司，申请时间等查询车辆的购置，调拨，报废的申请及审批情况等。
4.2用例图
1、车辆管理信息系统用例图
2、车辆购置管理用例图
3、车辆调拨管理用例图
4、车辆报废管理用例图
5、车辆基本信息管理用例图
4.3用例分析
一、车辆购置管理
用例1 用例名称：添加车辆购置申请 用例识别号：1.1.1 参与者：二级公司用户
简要说明：二级公司用户添加一个车辆购置申请单。前置条件：二级公司用户已经登录车辆管理信息系统。基本事件流：
1)二级公司用户单击“插入”按钮。2)系统出现编辑窗口。
3)二级公司用户可以在相应的文本框上添加或修改申请单，也可以完全删除，重新填写。
4)二级公司用户编辑完相应的文本框，单击“存盘”按钮，一条新的车辆购置申请记录就被插入到数据库中。5)用例终止 其它事件流：
在单击“存盘”按钮之前，二级公司用户随时可以单击“取消”按钮，窗口内的任何内容都不会被保存。异常事件流：
1）提示错误信息，二级公司用户确认。2）返回到管理系统主界面。
后置条件：一条新的车辆购置记录被插入到数据库中并显示出来。注释：无。
其它事件流：
在单击“是”按钮之前，二级公司用户可以单击“否”按钮，车辆购置申请记录不会被删除。
异常件流：
1）提示错误信息，二级公司用户确认。2）返回到管理系统主界面。
后置条件：选中的默认的车辆购置申请记录从数据库中被删除，同时显示界面被更新。
注释：删除之前，要先使用查询功能，以便选择要删除的内容。
用例3 用例名称：总工程师购置申请审批 用例识别号：1.2.1 参与者：总工程师
简要说明：总工程师对二级公司用户提交的车辆购置申请单进行审批。前置条件：总工程师已经登录车辆管理信息系统、存在未审批的车辆购置申请。
基本事件流：
1)总工程师单击选中要审批的车辆购置申请记录。2)总工程师单击“审批”按钮。3)系统出现编辑窗口。
4)总工程师可以在审批意见文本框上添加或修改审批意见，也可以完全删除，重新填写。
5)总工程师选择“同意”或“不同意”单选按钮审批结果。
6)总工程师编辑完相应的文本框及选择完审批结果后，单击“存盘”按钮，该车辆购置申请记录就被审批，并在数据库中修改该记录的审批标志，审批结果和审批意见。7)用例终止。其它事件流：
在单击“存盘”按钮之前，总工程师随时可以单击“取消”按钮，审批内容及审批结果都不会被保存。异常事件流：
1）提示错误信息，总工程师确认。2）返回到管理系统主界面。
后置条件：选中的车辆购置申请记录被审批，并在数据库中修改该记录的审批标志、审批结果和审批意见。
注释：审批之前，要先使用查询功能，查出未审批的车辆购置申请记录。
用例4 用例名称：总经理购置申请批复 用例识别号：1.3.1 参与者：总经理
简要说明：总经理对二级公司用户提交的公司所属车辆购置申请进行批复。前置条件：总经理已经登录车辆管理信息系统、存在满足如下条件的车辆购置申请记录，即：总工程师已审批、总经理未批复的公司所属车辆购置申请记录。基本事件流：
1)总经理单击选中要审批的车辆购置申请记录。
2)总经理编辑完相应的文本框及选择完批复结果后，单击“存盘”按钮，该车辆购置申请记录就被批复，并在数据库中修改该记录的批复标志，批复结果和批复意见。3)用例终止。其它事件流：
在单击“存盘”按钮之前，总工程师随时可以单击“取消”按钮，审批内容及审批结果都不会被保存。异常事件流：
1）提示错误信息，总经理确认。2）返回到管理系统主界面。
后置条件：选中的车辆购置申请记录被批复，并在数据库中修改该记录的批复标志、批复结果和批复意见。
注释：审批之前，要先使用查询功能，查处总工程师已审批，总经理未批复的公司所属车辆购置申请记录。
二、车辆调拨管理
用例5 用例名称：添加车辆调拨申请 用例识别号：2.1.1 参与者：二级公司用户
简要说明：二级公司用户添加一个车辆调拨申请单。前置条件：二级公司用户已经登录车辆管理信息系统。基本事件流：
1)二级公司用户单击“插入”按钮。2)系统出现编辑窗。
3)二级公司用户可以在相应的文本框上添加或修改申请单，也可以完全删除，重新填写。
4)二级公司用户编辑完相应的文本框，单击“存盘”按钮，一条新的车辆调拨申请记录就被插入到数据库中。5)用例终止。其它事件流：
在单击“存盘”按钮之前，二级公司用户随时可以单击“取消”按钮，窗口内的任何内容都不会被保存。异常事件流：
1)提示错误信息，二级公司用户确认。2)返回到管理系统主界面。
后置条件：一条新的车辆调拨记录被插入到数据库中并显示出来。注释：无。
用例6 用例名称：删除车辆调拨申请 用例识别号：2.1.2 参与者：二级公司用户
简要说明：二级公司用户删除一个车辆调拨申请记录。
前置条件：二级公司用户已经登录车辆管理信息系统、将要被删除的车辆调拨申请没有被审批。基本事件流：
1)二级公司用户单击选中要删除的车辆调拨申请记录。2)二级公司用户单击“删除”按钮。3)系统出现“提示是否删除”窗口。
4)二级公司用户单击“是”按钮，该车辆调拨申请记录就被从数据库中删除。5)用例终止。其它事件流：
在单击“是”按钮之前，二级公司用户可以单击“否”按钮，车辆调拨申请记录不会被删除。异常件流：
1）提示错误信息，二级公司用户确认。2）返回到管理系统主界面。
后置条件：选中的默认的车辆调拨申请记录从数据库中被删除，同时显示界面被更新。
注释：删除之前，要先使用查询功能，以便选择要删除的内容。
用例7 用例名称：总工程师调拨申请审批 用例识别号：2.2.1 参与者：总工程师
简要说明：总工程师对二级公司用户提交的车辆调拨申请单进行审批。前置条件：总工程师已经登录车辆管理信息系统、存在未审批的车辆调拨申请。
基本事件流：
1)总工程师单击选中要审批的车辆调拨申请记录。2)总工程师单击“审批”按钮。3)系统出现编辑窗口。
4)总工程师可以在审批意见文本框上添加或修改审批意见，也可以完全删除，重新填写。
5)总工程师选择“同意”或“不同意”单选按钮审批结果。
6)总工程师编辑完相应的文本框及选择完审批结果后，单击“存盘”按钮，该车辆调拨申请记录就被审批，并在数据库中修改该记录的审批标志，审批结果和审批意见。7)用例终止。其它事件流：
在单击“存盘”按钮之前，总工程师随时可以单击“取消”按钮，审批内容及审批结果都不会被保存。异常事件流：
1）提示错误信息，总工程师确认。2）返回到管理系统主界面。
3）后置条件：选中的车辆调拨申请记录被审批，并在数据库中修改该记录的审批标志、审批结果和审批意见。
注释：审批之前，要先使用查询功能，查出未审批的车辆调拨申请记录。
用例8 用例名称：总经理调拨申请批复 用例识别号：2.3.1 参与者：总经理
简要说明：总经理对二级公司用户提交的公司所属车辆调拨申请进行批复。前置条件：总经理已经登录车辆管理信息系统、存在满足如下条件的车辆调拨申请记录，即：总工程师已审批、总经理未批复的公司所属车辆调拨申请记录。基本事件流：
1)总经理单击选中要审批的车辆调拨申请记录。2)总经理单击“审批”按钮。3)系统出现编辑窗口。
4)总经理可以在审批意见文本框上添加或修改批复意见，也可以完全删除，重新填写。
5)总经理选择“同意”或“不同意”单选按钮批复结果。
6)总经理编辑完相应的文本框及选择完批复结果后，单击“存盘”按钮，该车辆调拨申请记录就被批复，并在数据库中修改该记录的批复标志，批复结果和批复意见。7)用例终止。其它事件流：
在单击“存盘”按钮之前，总工程师随时可以单击“取消”按钮，审批内容及审批结果都不会被保存。异常事件流：
1）提示错误信息，总经理确认 2）返回到管理系统主界面
后置条件：选中的车辆调拨申请记录被批复，并在数据库中修改该记录的批复标志、批复结果和批复意见。
注释：审批之前，要先使用查询功能，查处总工程师已审批，总经理未批复的公司所属车辆调拨申请记录。
三、车辆报废管理
用例9 用例名称：添加车辆报废申请 用例识别号：3.1.1 参与者：二级公司用户
简要说明：二级公司用户添加一个车辆报废申请单。前置条件：二级公司用户已经登录车辆管理信息系统。基本事件流：
1)二级公司用户单击“插入”按钮。2)系统出现编辑窗口。
3)二级公司用户可以在相应的文本框上添加或修改申请单，也可以完全删除，重新填写。
4)二级公司用户编辑完相应的文本框，单击“存盘”按钮，一条新的车辆报废申请记录就被插入到数据库中。5)用例终止。其它事件流：
在单击“存盘”按钮之前，二级公司用户随时可以单击“取消”按钮，窗口内的任何内容都不会被保存。异常事件流：
1）提示错误信息，二级公司用户确认。2）返回到管理系统主界面。
后置条件：一条新的车辆报废记录被插入到数据库中并显示出来。注释：无。
用例10 用例名称：删除车辆报废申请 用例识别号：3.1.2 参与者：二级公司用户
简要说明：二级公司用户删除一个车辆报废申请记录。
前置条件：二级公司用户已经登录车辆管理信息系统、将要被删除的车辆报废申请没有被审批。基本事件流：
1)二级公司用户单击选中要删除的车辆报废申请记录。2)二级公司用户单击“删除”按钮。3)系统出现“提示是否删除”窗口。
4)二级公司用户单击“是”按钮，该车辆报废申请记录就被从数据库中删除。5)用例终止。
其它事件流：
在单击“是”按钮之前，二级公司用户可以单击“否”按钮，车辆报废申请记录不会被删除。异常件流：
1）提示错误信息，二级公司用户确认。2）返回到管理系统主界面。
后置条件：选中的默认的车辆报废申请记录从数据库中被删除，同时显示界面被更新。
注释：删除之前，要先使用查询功能，以便选择要删除的内容。
用例11 用例名称：总工程师报废申请审批 用例识别号：3.2.1 参与者：总工程师
简要说明：总工程师对二级公司用户提交的车辆报废申请单进行审批。前置条件：总工程师已经登录车辆管理信息系统、存在未审批的车辆报废申请。
基本事件流：
1）总工程师单击选中要审批的车辆报废申请记录。2）总工程师单击“审批”按钮。3）系统出现编辑窗口。
4）总工程师可以在审批意见文本框上添加或修改审批意见，也可以完全删除，重新填写。
5）总工程师选择“同意”或“不同意”单选按钮审批结果。
6）总工程师编辑完相应的文本框及选择完审批结果后，单击“存盘”按钮，该车辆报废申请记录就被审批，并在数据库中修改该记录的审批标志，审批结果和审批意见。7）用例终止。其它事件流：
在单击“存盘”按钮之前，总工程师随时可以单击“取消”按钮，审批内容及审批结果都不会被保存。异常事件流：
1）提示错误信息，总工程师确认。2）返回到管理系统主界面。
3）后置条件：选中的车辆报废申请记录被审批，并在数据库中修改该记录的审批标志、审批结果和审批意见。
注释：审批之前，要先使用查询功能，查出未审批的车辆报废申请记录。
用例12 用例名称：总经理报废申请批复 用例识别号：3.3.1 参与者：总经理
简要说明：总经理对二级公司用户提交的公司所属车辆报废申请进行批复。前置条件：总经理已经登录车辆管理信息系统、存在满足如下条件的车辆报废申请记录，即：总工程师已审批、总经理未批复的公司所属车辆报废申请记录。基本事件流：
1)总经理单击选中要审批的车辆报废申请记录。2)总经理单击“审批”按钮。3)系统出现编辑窗口。
4)总经理可以在审批意见文本框上添加或修改批复意见，也可以完全删除，重新填写。
5)总经理选择“同意”或“不同意”单选按钮批复结果。
6)总经理编辑完相应的文本框及选择完批复结果后，单击“存盘”按钮，该车辆报废申请记录就被批复，并在数据库中修改该记录的批复标志，批复结果和批复意见。7)用例终止。其它事件流：
在单击“存盘”按钮之前，总工程师随时可以单击“取消”按钮，审批内容及审批结果都不会被保存。异常事件流：
1）提示错误信息，总经理确认。2）返回到管理系统主界面。
后置条件：选中的车辆报废申请记录被批复，并在数据库中修改该记录的批复标志、批复结果和批复意见。
注释：审批之前，要先使用查询功能，查处总工程师已审批，总经理未批复的公司所属车辆报废申请记录。
4.4功能活动图
1、用户登录活动图
2、车辆基本信息管理活动图
3、车辆购置管理活动图 4.5状态图
1、车辆购置申请单状态图
2、车辆基本信息状态图
5非功能需求
5.1性能需求
5.1.1时间、界面、响应要求
由于此系统主要用于信息的保管查询，即对数据的安全性要求极高。为防止对信息资料和管理程序的恶意破坏，及恶意的窃取私人信息，要求有较为可靠的安全性能。另外也需要高速的响应，要求稳定、安全、便捷，易于管理和操作。另外使用者大多为非计算机人员，所以要求界面友善，交互性强。查询速度：不超过5秒；
其它所有交互功能反应速度：不超过3秒； 可靠性：平均故障间隔时间不低于300小时。信息容量：不低于10G时可能出现系统崩溃。
5.1.2灵活性
当用户需求，如操作方式，运行环境，结果精度，数据结构与其他软件接口等发生变化时，设计的软件要做适当调整,灵活性非常大。
5.2数据管理需求
5.2.1系统数据流图
车辆购置业务流程图
车辆调拨业务流程图 车辆报废业务流程图
5.2.2数据整理与保存
应满足随时整理的需求，用户可随时更改数据，保存数据。对于数据唯一性的识别应放在多个关键字之上。
5.2.3数据安全性
数据应具有极高的安全性，为了保护用户的隐私，仍需设置登陆及密码保护，以防用户的信息被人窃取。
5.3故障处理需求
1、内部故障处理: 在开发阶段可以随即修改数据库里的相应内容。
2、外部故障处理: 24 对编辑的程序进行重装载时，第一次装载认为错，修改。第二次运行，在需求调用时出错，有错误提示，重试。
3、本软件可能产生的错误为数据库的错误信息，应由数据库管理员对数据库进行维护。为了确保系统恢复的能力，数据库管理员要定期对数据库进行备份。但产品投入使用后，则由维护人员跟进。
第四篇：车辆管理系统需求规格说明书[模版]
车辆管理系统
软件需求规格说明书
班 级 08软工A2 组 号
拟制人 陆美娟
2011年3月14日
第五篇：图书管理系统需求分析
云南工商学院09信息管理1班
图书管理系统需求分析
班级：09信息管理1班
组员： 唐学悦，段敏，杨文燕，胡勇毅，余科辑，林春宇，李波
任务分配情况：
云南工商学院09信息管理1班
目录 系统需求概述...............................................................................................................................3 1.1 图书管理系统功能概述....................................................................................................3 1.2 系统主要业务流程分析....................................................................................................3 1.3 系统功能模块分析............................................................................................................3 1.4 建立用例模型....................................................................................................................4 1.4.1 读者用例图.............................................................................................................4 1.4.2 图书管理员用例图.................................................................................................4 1.4.3 系统管理员用例图.................................................................................................5 1.5 详述用例............................................................................................................................5 2 系统分析.......................................................................................................................................6 2.1 类图....................................................................................................................................6 3 系统设计.......................................................................................................................................8 3.1 用例动态模型设计............................................................................................................8 3.1.1 实现“读者查询个人借阅信息”用例的动态模型.................................................8 3.1.2 实现“查询图书信息”用例的动态模型.................................................................9 3.1.3 实现“借阅图书”用例的动态模型.........................................................................9 3.2 类图设计..........................................................................................................................11 3.3 物理架构设计..................................................................................................................12 3.3.1 组件图...................................................................................................................12 3.3.2 配置图...................................................................................................................13 2
云南工商学院09信息管理1班
1.系统需求概述
1.1 图书管理系统功能概述
图书管理主要是借书、还书以及其他一些附带操作（例如，超期罚款、催还图书等）的处理。一个简单的图书管理系统应提供如下功能：
·借书处理：完成读者借书的流程处理。·还书处理：完成读者还书的流程处理。
·信息查询：包括图书信息查询和读者借阅情况查询。·图书管理：包括输入新书记录和删除旧书记录。
1.2 系统主要业务流程分析
与系统功能相对应，系统主要有4个流程：结束流程、还书流程、图书查询、图书资源管理。各流程的主要过程描述如下：
·借书流程：读者借阅所需的图书，借出后图书记录中的借阅标志被置为false(不能再借)，借书文件中增加一个借书记录。
·还书流程：读者归还所借的图书，还书后图书记录中的借阅标志被置为true(可被外借)，在借书文件中删除一个借书记录。
·图书查询：读者和工作人员可以进行图书信息查询，输入图书的编号或书名，可从图书对象列表中查找相应的记录。
·图书管理：首先由工作人员在“录入新书资料”和“删除旧书资料”两个选项中选择。若是“录入新书资料”，则由工作人员输入新书资料，将新书添加为对象列表的新纪录。若是“删除旧书资料”，则查找需要删除的图书，将其从图书对象列表中删除。
1.3 系统功能模块分析
满足上述需求的系统主要包括以下几个系统模块：
·基本业务处理模块：主要用于实现图书管理员对读者借阅图书和归还图书的处理。
·信息查询模块：重要用于实现读者对图书信息和自身借阅信息的查询。
云南工商学院09信息管理1班
·系统维护模块：主要用于实现系统管理员对读者信息、图书管理员信息、图书信息、和数据库的管理。
1.4 建立用例模型
根据功能需求构造用例模型，主要任务是识别系统中的所有参与者，并对每个参与者找出其用例，建立用例模型。
系统主要的参与者为“读者”、“图书管理员”、和“系统管理员”。各个参与者的用例图如下：
1.4.1 读者用例图
<
图1-1 读者用例图
1.4.2 图书管理员用例图
<
图1-2 图书管理员用例图
云南工商学院09信息管理1班
1.4.3 系统管理员用例图
添加书目添加读者删除书目删除读者系统管理员查询图书查询读者
图1-3 系统管理员用例图
1.5 详述用例
在识别了参与者和主要用例并创建了用例图之后，如果有必要，还可以按顺序详述每个用例，包括用例如何开始、结束以及如何与参与者进行交互。
表1-1 读者查找个人借阅信息用例
用例：读者查找个人借阅信息(用例名称)(唯一标识符)(涉及用例的参与者)(用例开始时，系统必须满足的条件)ID：1参与者：
1、读者前提条件： 读者已登录到系统事件流：
1、读者选择查找个人借阅信息界面
2、读者输入图书证编号
3、系统按图书证编号查找读者借阅信息结果：系统向读者显示读者借阅信息，该用例结束(用例中的实际步骤)(用例结束时，系统的状态)
云南工商学院09信息管理1班
表1-2 读者查找图书信息用例
用例：读者查找图书信息(用例名称)(唯一标识符)(涉及用例的参与者)ID：2参与者：
1、读者(用例开始时，系统必须满足的条件)前提条件： 读者已经启动图书管理系统，并已知书名或书号事件流：
1、读者选择查找图书信息界面
2、读者输入书名或书号
3、系统按书名或书号查找图书信息结果：系统向读者显示图书信息，该用例结束(用例中的实际步骤)(用例结束时，系统的状态)系统分析
2.1 类图
在定义系统需求后，下一步就是确定系统中存在的对象类。系统中对象类的识别可以使用名词/动词分析法来进行，即文本中的名词和名词短语暗示类或类的属性，动词和动词短语暗示职责或者类的操作。
通过用例图的分析可知，在图书管理系统中可以确定的主要对象类包括 “读者”，“图书”、“图书管理人员”和“系统管理员”。其中“读者”和“图书”通过借阅关系可以构成一个新类“借阅记录”。
另外，分析用例图可知，用例“身份验证”和“图书资料查询”是对象类“读者”和“工作人员”共同拥有的，并且用例“身份验证”是除用例“图书资料查询”之外其余用例执行的前提，因此可以将“身份验证”与“图书资料查询”定义为接口类中的操作(接口类是不含属性且操作函数没有具体实现的抽象类，接口类通过一个实现联系获得其它对象类的支持，这些对象类实现接口类中定义的全部操作)。其余用例则抽象为与该用例交互的参与者所属对象类的操作。因此，最后可获得的对象类图为：
云南工商学院09信息管理1班
系统管理员-name-password1*读者-name-number-password+借书()+还书()+借阅情况查询()***<
图1-4 系统对象类图
除了定义上述用于系统数据信息存储管理和业务逻辑控制的类之外，在用图形用户界面开发系统时，我们还可以定义一些相应的用户界面类：
(1)MainWindow类—MainWindow是图书管理员与系统交互的主界面，系统的主 界面具有菜单，当用户选择不同的菜单项时，MainWindow对象调用相应的方法完成功能操作。
(2)BorrowDialog类—BorrowDialog是进行借书操作时需要的对话框。(3)ReturnDialog类—ReturnDialog是进行还书操作时需要的对话框。(4)QueryDialog类—QueryDialog是查询某借阅者的借阅信息或图书库存信息的对话框。
(5)MaintenanceWindow类—MaintenanceWindow是系统管理员对系统进行维护的主界面，它也提供菜单项。
ReturnDialogBorrowDialogMainWindowQueryDialogMaintenanceDialog 图1-5图书管理系统的用户界面类
云南工商学院09信息管理1班 系统设计
系统设计的主要工作是用例实现—设计。即对每个用例进行动态建模，包括建立序列图、协作图等，描述如何通过类对象的协作来实现用例中的功能。随着动态建模的深入，会发现原来建立的类存在缺陷或不够完整，需要对分析中得到的类图进行不断的修正和调整。所以，还应该通过动态建模来修正和完善类图。
3.1 用例动态模型设计
3.1.1 实现“读者查询个人借阅信息”用例的动态模型
:MainWindow:QueryDialog:BorrowBookBorrower1:queryLoan2:createDialog3：queryLoanInfo4:getBook5:消息查询6：返回借阅信息7：显示借阅信息
图1-6 读者查询个人借阅信息序列图
1:queryLoan():MainWindowerBorrower6:显示借yLoanInfo()阅信息5:返回借阅信息:Borrower-Book4:getBook():QueryDialog2:createDialog()3:qu
图1-7 读者查询个人借阅信息协作图
云南工商学院09信息管理1班
3.1.2 实现“查询图书信息”用例的动态模型
:MainWindow:QueryDialog:BorrowBookBorrower1:queryLoan2:createDialog3：queryLoanInfo4:findBook5:图书信息查询6：返回图书信息7：显示图书信息 图1-8 读者查询图书序列图
1:queryLoan():MainWindowerBorrower6:显示图yLoanInfo()书信息5:返回图书信息:Borrower-Book4:findBook():QueryDialog2:createDialog()3:qu
图1-9 读者查询图书协作图
3.1.3 实现“借阅图书”用例的动态模型
云南工商学院09信息管理1班
:MainWindow:BorrowDialog:QueryDialogBorrower1:queryLoan2:createDialog4:查询图书库存5:返回图书是否可借6:修改读者的借阅信息及库存信息7:修改成功8:显示借书成功
图1-10 读者借阅图书序列图
2:createDialog()oan():MainWindow:BorrowDialogry1:queL息6:显示借书成功存库信书借存图可库询否及查是息功:4书信成图阅改修Borrower回借:7返者:读5改修:6:QueryDialog
图1-11 读者借阅图书协作图
云南工商学院09信息管理1班
3.1.4 实现“归还图书”用例的动态模型
:MainWindow:ReturnDialog:QueryDialogBorrower1:queryLoan2:createDialog3:修改读者的借阅信息及库存信息4:修改成功5:显示还书成功
图1-12 读者归还图书序列图
1:queryLoan():MainWindowBorrower6:显示还书成功4:修改成功:QueryDialog3:修改读者的借阅信息及库存信息:ReturnDialog2:createDialog()
图1-13 读者归还图书协作图
3.2 类图设计
进一步扩充和细化分析阶段定义的类，包括定义新的类来处理用户的需求。随着动态建模的深入，也会发现原来建立的类存在缺陷或不够完整，需要对分析中得到的类图进行不断的修正和调整。所以，还应该通过动态建模来修正和完善类图。
云南工商学院09信息管理1班
系统管理员-name:string-password:string+AddBook()+QueryBook()+AddBorrower()+QueryBorrower()借书记录-borrower:string-book:string-date:Date+newLoan()+getBorrower()+getBook()11*读者-name:string-number:string-password:string+Borrow()+Return()+QueryLoan()***<
图1-14 设计类图
3.3 物理架构设计
物理架构设计就是用UML图形描述系统软件和硬件的大致结构，包括画出组件图和配置图。
3.3.1 组件图
组件图：表示构成软件系统的各物理组件及其相互之间的联系。它能明确表示软件系统各部分的功能职责。图书管理系统的组件图如下所示，其中包含“借/还书处理”、“信息查询”、“图书资源管理”和“身份验证”等组件。
云南工商学院09信息管理1班
图书管理系统借/还处理信息查询图书资源管理身份验证图书信息借阅信息
图1-15 系统组件图
3.3.2 配置图
图书管理系统是一个基于网络和数据库的应用系统,可以采用B/S结构,系统配置图下图所示：
数据库服务器图书信息借阅信息读者客户端借/还书处理工作人员客户端公共客户端身份验证图书资源管理借阅信息图书资料查询 图1-16 系统配置图
点击咨询 