第一篇：读《学生饭卡管理系统需求分析规格说明书》有感

第一次的作业

读《学生饭卡管理系统需求分析规格说明书》有感

学以致用才是真的有用。——题记

第一次阅览这样的文档，揣摩了好几天，觉得此篇写得还不赖，以下就是本人的一点点体验领会。大概的纵观你会发现此文档文中带图，图中兼文，若是浏览一下的话，你根本发现不了，理解不了图文要表达的意思。

本文档——《需求分析规格说明书》的项目名称是《学生饭卡管理系统》，从本文档需求规定中我们可以看出此ID卡除了具备饭卡的存款、消费外，其还兼备着在图书馆里借书还书的重要角色——借书卡，充分呈现了这种“二合一”的结构思想，体现了设计者在原有熟练的图书管理系统的基础上插播了富有生命力的——《学生饭卡管理系统》，使其达到了预期需求规定的系统界面清晰，操作简单。

不得不提及的是该文档还通过结构化的方式进行了系统的分析，也就是我们所说的结构化分析，在0层，在1层，在2层，在3层，无不体现着结构化分析的“分解”和“抽象”的这两个基本手段，这种自顶向下，层层分解的结构化分析方法。感觉该设计者实在有点牛啊！可以将书本的理论与自己的实践结合得如此天衣无缝，让我联想到的是感叹啊！感叹以后作为领导的我们在职场生涯道路上该何去何从啊？

本文档运用了E—R图，状态转换图，层次方框图还有我们经常见老师在黑板上画得（IPO图），文档图文虽多但并不繁杂，而且无不一一将要表达的精髓一一呈现，力求描绘（讲述）对饭卡信息进行查询和更新管理的简单，反应敏捷，准确地特性。

文档的详尽，我只能读懂皮毛，以上就是本人经阅览文档后挤出来的一点点感想，不足的地方，若有若无的错句希望老师帮我改之纠之。。。

（谢谢阅读）

10大专计机 梁福根

第二篇：饭卡管理系统需求规格说明书

一、引言

1.编写目的本需求分析文档的目的是说明饭卡管理系统最终所运行的条件，性能要求及要实现的功能，为进一步设计与实现打下基础。本文档以文档形式将用户对软件的需求固定下来，是与用户沟通的成果，也供用户验收项目时参考

本文档预期读者为：用户，项目管理人员，软件设计人员，编程人员，测试人员等项目相关人员

2.开发背景

系统名称：《饭卡管理系统》

需求背景：

随着我国经济的发展，电子管理系统的多功能化，企业，学校等纷纷使用电子记账卡对于员工，学生等的消费进行管理，故对合理，高利用率的饭卡管理系统有着迫切的需求

系统用途：

本系统智能化地管理饭卡系统的运作，从而提高管理的效率

系统开发人员：

陈永林小组

二、任务概述

1.任务目标

能对饭卡信息进行及时的管理及查询，提高用户工作效率

2.用户特点

本系统是面向学校饭卡管理而开发的，由于系统的界面清晰、美观，操作简单、方便，所以操作人员只需要具备一定的电脑操作技能即可。管理员（维护人员）不需要任何数据库专业技能知识。本系统可以极大的提高工作效率。

三、系统环境

1.系统构架

系统由刷卡器、管理员端和客户端构成。刷卡器主要为学生提供日常消费功能，客户端完成学生自助查询、挂失功能，而管理员端则主要完成新建、存款、注销等功能。

四、需求分析

1.1

业务需求

本系统会涉及到的业务包括注册用户（新建）、饭卡充值（存款）、饭卡信息查询、刷卡消费、饭卡挂失/解锁、饭卡注销、修改用户信息六大功能

1.2

注册用户功能

注册功能权限只开放给管理员，该功能由管理员输入正确的用户注册信息并设置原始密码，然后录入数据库。

1.3

饭卡充值功能

该功能权限只开放给管理员，由管理员确认金额无误后更新饭卡余额信息。

1.4

饭卡挂失/解锁功能

该功能用户及管理员均可以使用，用户凭借用户密码通过客户端登入后可对饭卡进行挂失/解锁。

1.5

饭卡注销功能

该功能仅开放给管理员，由管理员输入用户ID并确认注销。

1.6

饭卡信息查询功能

该功能管理员及用户均可以使用，用户需凭用户密码登入进行简单查询。

1.7

消费功能

该功能开放给用户及管理员，用户通过刷卡器端进行消费，也可通过管理员进行日常缴费。

五.功能概述

经分析，该饭卡管理系统主要实现以下功能：

1、登录/注册

2、存款/消费

3、查询/修改

4、挂失/解锁

5、注销/学生端

食堂刷卡管理系统管理端

业务流程图：

余额

查看

卡号挂失冻结

消费信息查询

充值信息查询

卡号信息记录

学生信息记录

登

录

管

理

办

卡

管

理

充

值

管

理

消

费

管

理

注

销

管

理

管理端登录

学生端登录

学生信息录入

学

生

信

息

管

理

卡号信息激活

饭卡挂失冻结

解锁补办饭卡

卡号充值

充值记录查询

消费类型

消费信息

卡号注销

注销信息查询

学生端

第三篇：车辆管理系统需求规格说明书[模版]

车辆管理系统

软件需求规格说明书

班 级 08软工A2 组 号

拟制人 陆美娟

2011年3月14日

第四篇：车辆管理系统需求规格说明书

车辆管理系统

软件需求规格说明书

班 级 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、本软件可能产生的错误为数据库的错误信息，应由数据库管理员对数据库进行维护。为了确保系统恢复的能力，数据库管理员要定期对数据库进行备份。但产品投入使用后，则由维护人员跟进。

第五篇：宿舍管理系统需求规格说明书

需求规格说明书

1.引言 1.1编写目的

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享，提高工作效率。

本文档从用户、功能、性能、运行环境等各方面对系统进行了分析，以确保在系统开发过程中，确定好具体目标，使工作能有条不紊的进行，提高工作效率。

1.2背景

很多学校特别是中等及高等院校中，学生在校住宿的情况极其普遍。随着高校的扩招，需要住宿的学生人数和学生公寓楼房越来越多，宿舍管理人员的需求量也相应地增加。许多高校后勤实施社会化改革，学生住宿条件得到了很大改善，宿舍安排上打破了原来按专业班级强制集中住宿的限制，可供学生选择的余地也越来越大，相关部门对公寓管理的要求越来越高，导致公寓管理的难度越来越大，原来的手工管理已经无法适应，需要用信息化手段来实现。因此，开发一个学生宿舍分配软件是十分必要的，希望能够为广大教师、校院领导、宿舍管理员和学生提供便利，加强学生住宿管理、规范高校公寓日常工作、提高公寓管理效能的有效工具。

1.3 定义

用例图(Use Case)：是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图。呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

顺序图：是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。

类图(Class diagram)：是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息。

状态图(Statechart Diagram)：是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。

活动图（activity diagram）：是阐明了业务用例实现的工作流程。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。

协作图/通信图(Communication Diagram)：而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。

1.4参考资料

（1）殷建民 主编，《软件系统分析与设计》，中国水利水电出版社，2008（2）《学生宿舍基本需求》（3）《2012级软件系统分析与设计实验指导书（16学时宿舍分配系统）》

2．任务概述

2.1 目标

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享

2.2 用户特点

学生：若要住宿需提交住宿申请，然后等待分配。如有特殊要求，务必专门说明。一旦得到批准通知，可以查询个人宿舍安排。住宿后若有特殊原因，可以申请调整宿舍或床位，但依然要经过审核、批准。一旦调换了宿舍，其所使用的设备也要随之变更记录。

教师：分为班主任和辅导员。辅导员负责查看、初审学生提交的住宿申请，对基本符合要求的，转交给宿舍负责人。班主任和辅导员可以随时查看、了解所负责班级住宿学生的情况。

宿舍负责人：负责对住宿申请进行综合审查，通过的则以班为单位分配床位。可以随时查看和了解宿舍的基本情况、所有住宿情况和设备使用情况，对特殊情况及时进行统计，并报送相关领导。学生一旦毕业或提出退宿，其宿舍和床位会立即变空，等待重新分配使用。

宿舍管理员：负责宿舍设备情况的记录（购入登记、各建宿舍配置、损坏和修理登记、报废登记）、每日查房结果记录、学生晚归记录、宿舍具体情况管理（新房间登记、房间撤消、格局调整）。

校院领导：可以随时查看、了解学校和学院宿舍的详细信息、学生住宿状况和宿舍管理员的基本情况以及每日查房的情况。

2.3 假定与约束

经费限制：由于是学习之作，资金的不足限制了本软件的研发。

开发期限;在时间方面，只能在课余时间完成本软件，对时间的安排需做到合理，恰当才能很好的完成本工程。

3.需求分析建模

3.1功能需求

3.1.1系统需求描述

本学生宿舍分配系统以公寓房间、入住学生为基础信息源，可以对房间和床位分配，可以使教务处、学生处、保卫处、公寓管理中心、财务处等学校职能部门及学校学院领导随时获得全方位的公寓管理信息，实现信息共享。

基本流程图如下:

宿舍学生提交住宿申请返回不同意返回同意结束N查看住宿申请初审Y判断宿舍负责人是否同意NYN复审负宿人责舍教师查看申请Y分配床位领校导院管宿员理舍

3.1.2 总体功能分析

各类角色的大体功能分析：

学生:填写申请表、提交住宿申请、查看申请结果、申请宿舍调整 辅导员:查看学生住宿情况、查看住宿申请、初审、返回申请结果给学生 班主任：查看本班学生住宿情况

宿舍负责人：复审、分配床位、查看住宿信息、宿舍住退更新、特殊情况报送领导 宿舍管理员:宿舍查房记录、宿舍设备情况记录、晚归记录、宿舍集体情况 校院领导：查看宿舍详细信息、查看住宿情况、宿舍管理员情况、每日查房情况 具体用例图如下： 填写申请表查看学生住宿情况提交住宿申请查看住宿申请初审查看申请结果学生辅导员返回申请结果给学生班主任申请宿舍调整复审宿舍查房记录查看宿舍详细信息分配床位宿舍设备情况记录查看住宿情况查看住宿信息晚归记录院校领导宿舍管理员情况宿舍管理员宿舍负责人宿舍住退更新特殊情况报送领导宿舍集体情况每日查房情况3.1.3 功能模块分析(详述 学生申请)☆由学生申请住宿用例：当学生登录后，进入申请界面，填写申请报告，出现两种情况，即填写正确或错误/部分错误，对应的成功提交申请或返回重新填写申请...构建活动图、协作图、顺序图等来完成功能的具体分析。

活动图：

学生登陆进入申请界面填写申请表还有未审核的申请填写正确保存新申请表填写错误返回主界面重新填写提交申请等待申请结果回到主界面

状态图：

学生申请这一事件对应的状态：首先是要进行申请表的填写预准备工作，即新建一张空白申请表，进行填写，完成后进行提交，即等同于进入等待审核状态；等待后台审核完成后，学生进行查看可以找到‘审核通过’‘不通过’以及‘不通过（部分不符合要求）’三种状态，一次审核通过后二审，产生‘批准’‘不批准’两种状态，批准通过，进入入住状态。

新建批准保存已入住审核通过不批准提交审核不通过部分通过顺序图: 根据流程图和活动图，可以建立学生申请的工作顺序图，首先是登陆到首页>进入申请界面，申请表的填写与是否可以成功提交由提交控制检测并返回可申请/不可申请/有错重新填写，提交成功则学生等待来自辅导员以及宿舍管理员的的审核结果以及宿舍分配结果。

学生首页申请界面提交控制辅导员宿舍负责人登陆登陆成功退出不可以申请可以申请填写申请提交给辅导员有错重新填写反馈同意请求复审同意驳回不同意 协作图：

学生功能界面申请表审核控制辅导员返回不同意返回同意及宿舍分配 3.2性能需求

3.2.1精度

在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数据（如申请表，住宿信息等）时，要求输入准确学生姓名，身份证，学号，班级，宿舍号等，按需求设定字符数。

3.2.2时间特性要求

（1）查询类页面响应时间<=3s（2）更新处理时间，如新建、提交等最长时间不超过2s。（3）数据的转换和传送时间，如远程数据传输不超过5s。

3.3数据需求

3.3.1 输入输出数据要求

1）宿舍的详细数据、学生住宿的情况以及宿管人员的具体数据要完整保管，且一旦发生变化，必须及时变更记录。

2）上述数据要能够导出到excel文件中，或从excel文件导入。3）分配床位时可以采取二种方法：

● 第1是按照一定的算法进行自动分配，● 第2是针对特殊要求进行手工分配 4）学生住宿需要记录的内容主要包括：

学号、姓名、所属学院、所属系、宿舍房间号、床铺号、柜子号、入住时间、联系电话等。5）每个房间需要记录的内容主要包括：

宿舍房间号、面积、可容纳人数、目前空床数、6）为简化宿舍分配过程中学生信息的重复录入，保证数据的一致性和统一性，最好可利用现行的学籍管理系统中的信息。

3.3.2数据分析模型(类图)

people-memberName-memberName学生-memberName-memberName职工-memberName-memberName教师-memberName-memberName院校领导-memberName-memberName宿舍负责人-memberName宿舍管理员-memberName-memberName-memberName辅导员-memberName班主任-memberName-memberName-memberNamec各种记录学生住宿信息班级-memberName-memberName-memberName-memberName-memberName-memberName住宿申请-memberName-memberName住宿登记表-memberName-memberName床位-memberName宿舍-memberName-memberName设备-memberName-memberName-memberName

类图分析：用户主要分为学生和职工两大类，学生类和职工类继承于people类，而教师类、领导类、宿舍负责人类和宿舍管理员类继承于职工类，辅导员和班主任类继承于教师类；学生与辅导员、班级、住宿登记表、床位、宿舍、住宿申请等都是关联关系。

3.4故障处理要求

正常使用时不应出错，对于用户的输入错误应给出适当的改正提示。若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损，可以通过日志来了解故障现象、发生时间。

3.5其他专门要求

（1）进度需求：系统开发的阶段进度要求。（2）运行环境需求：平台、体系结构、设备要求。

（3）培训需求：无实体培训，系统配备《用户使用手册》，提供多媒体教学光盘。

4.运行环境规定 4.1设备

服务器

PC机（建议配置：操作系统 windows 2000/XP/Vista CPU PentiumⅣ以上 内存 128M以上 硬盘空间 100M以上）DVD光驱，打印机等。

4.2支持软件

软件运行基于windows平台上的2000，NT，XP,Vista等。数据库：MySQL 4.3接口

无