图书馆管理系统需求规格说明书.docx
《图书馆管理系统需求规格说明书.docx》由会员分享，可在线阅读，更多相关《图书馆管理系统需求规格说明书.docx（19页珍藏版）》请在冰豆网上搜索。
图书馆管理系统需求规格说明书
图书馆管理系统需求规格说明书
1.导言
1.1目的
该文件夹是关于用户对图书馆管理系统的功能和性能的要求，重点
描述了图书馆管理系统的功能需求，是概要设计阶段的重要输入。
本文档的预期读者是：
〃设计人员；〃开发人员；〃项目管理人员；
〃测试人员；
〃用户。
1.2范围该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型的，
解决整个项目系统的“做什么”的问题。
在这里，没有涉及开发技术，
而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开
发方等不同参与方提供一个交流的平台。
1.3编写要求
，（服务页面）的缩写，一个脚本化的
语言。
（统一建模语言）的缩写，是一
个标准的建模语言。
1.4术语定义
无
1.5引用标准
[1]《企业文档格式标准》，北京长江软件有限公司过程化组织
[2]《需求规格报告格式标准》，北京长江软件有限公司过程化组织
1.6参考资料
[1]《说明》，长江软件有限公司
[2]《需求规格报告格式标准》，长江软件有限公司过程化组织
1.7版本更新
本文档的更新记录如表1所示。
表1版本更新纪录
修改编号修改日期修改后版修改位臵修改内容概述
───────────────────────────────────────
0012009.05.050.1全部初始发布版本
0022009.05.100.2第3.1节增加
0032009.05.150.3第4.1节修改
0042009.05.160.4第5.1节修改
0052009.05.181.0第7章增加
───────────────────────────────────────
2．系统定义我们分别阐述一下项目的来源、背景，项目的用户特点和项目的目
标。
2.1项目来源及背景本项目是为某学校开发的一个图书馆管理系统，由于该学校的规
模比较大，需要借阅图书的同学也很多，如何满足同学的借阅需求常
常是学校的比较棘手的事情，为图书管理员带来很多工作量。
为此学
校希望有一个自动化的图书馆管理系统能够给他们带来工作的便利，
提高工作效率，同时能及时满足同学们的借阅图书的需求。
为实现同学方便的借阅图书馆的图书，弥补以往存在的种种不足，
我们开发了图书馆管理系统。
图书馆的管理员通过这个图书馆管理系
统列表图书、列表用户、查询图书、更改图书的基本资料和更改用户
的资料、借阅管理；读者可以通过图书馆管理系统查询图书信息、预
定图书以及查询自己的资料；图书馆管理员可以通过该系统整理图
书、确认用户信息、管理用户权限、管理图书的借、还、预定以及对
损坏图书者的罚款。
图书管理员可以随时的浏览图书的资料和用户的
相关借阅信息。
2.2用户的特点本用户是在校人员。
包括二类，一类是读者，他们的差异很大有
的学历很高，有的可能很低。
有的经验丰富，有的可能是没有经验等。
另外一类是管理用户，他们是学校的内部人员，对图书馆的借阅流程
很熟悉，总之，他们对使用图书馆管理系统软件比较熟悉。
2.3项目目标
本项目设定的目标如下：
系统能够提供良好的用户界面，是操作人员的工作量最大限度的减
·
少；
系统具有良好的运行效率，能够达到提高工作效率的目的；
·
系统应具有良好的可扩充性，可以容易的加入其他系统的应用；
·
平台的设计具有一定的超前性，灵活性，能够适应图书馆的变化；
·
通过这个项目可以锻炼队伍，提高团队的开发能力和项目管理能
·
力。
3应用环境
根据用户的需求陈述，可以确定本项目分为客户端和管理端，客
户端主要功能是为用户提供图书资料、查看图书详情、用户注册、用
户登录、查看用户的信息、修改用户个人信息、预定图书、借阅图书。
管理端的功能是图书馆管理人员进行图书管理、用户信息管理、借阅
信息管理等。
它们的关系如图2所示。
读者
网
图书信息图书信息
图书管理
选择图书
络
用户信息
用户管理
查看图书
服
务
预定信息预定信息
预定管理
预定图书
器
借阅信息
借阅管理图2图书馆管理系统流程图
3.1系统运行的网络环境本系统的网络运行图如图2，无论是客户端的用户还是管理端的
管理用户都可以通过网络登录到本系统中。
3.1.1系统运行的硬件环境
本系统的硬件环境如下；
客户机：
普通
41.8以上
〃
内存：
256以上
〃
能够运行5.0以上或者4.0以上版本的机器
〃
1024*768像素分辨率：
推荐使用
〃
服务器
:
P41.0
〃
内存：
1G以上
〃
以上硬盘：
80
〃
速度网卡：
K
〃
数据库服务器
:
P42.0
〃
内存：
1以上
〃
以上硬盘：
80
〃
系统
服务器
用户
数据库服务器
系统管理员
系统运行软件
本系统的软件环境如下：
操作系统：
2000或以上版本
〃
数据库：
2000
〃
开发工具包：
1.4.2
〃
服务器：
〃
l浏览器：
6.0以上
〃
4.功能规格我们采用面向对象分析作为主要的系统建模，使用作为建模
语言。
为建模活动提供了从不同角度观察和展示系统的各种特征
的方法。
在中，从任何一个角度对系统所作的抽象都可能需要几
种模型来描述，而这些来自不同角度的模型图最终组成了系统的映
像。
用例描述角色（用户、外部系统以及系统处理）是如何与系统交
互来完成工作的。
用例模型提供了一个非常重要的方式来界定系统边
界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。
设计用例时，我们遵循下列步骤：
（1）识别出系统的角色。
角色可以是用户、外部系统，甚至外部处
理，通过某种途径与系统交互。
重要的是着重从系统外部执行者的角
度来描述系统需要提供功能，并指明执行者（角色）是谁。
尽可能地
确保所有角色都被完全识别出来。
（2）描述主要的用例。
可以采取不断的问自己“这个角色究竟想过
系统做什么”来准确的描述用例。
（3）重新审视每个用例，为它们下一个详细的定义。
图书管理图书借阅系统管理
登陆界面
图书借阅
图书管理用户管理
列表图书
列表图书
列表用户
查询图书
借书
还书
图书的基本资料
增加用户
删除用户
赔偿
信息确认
管理用户权限
增加图书
撕毁图书
删除图书
涂画图书
丢失图书
用户详细信息
浏览图书
修改用户信息
图书馆管理系统活动图
4.1角色定义
角色或者执行者指与系统产生交互的外部用户或者外部系统。
4.1.1用户
用户是指在这个图书馆管理系统中通过用户端提交借阅图书信息的
人员，这个角色主要参与用户端的个人信息查询、图书信息查询、图
书预定等功能。
4.1.2管理用户
管理用户是指管理端的用户，此角色派生两个子类，图书管理员
和系统管理员，图书管理者又可以派生出3个子类，图书信息管理员、
用户信息管理员、预定信息管理员。
系统管理员是指对图书管管理系
统进行相关设臵，进行系统维护的人员，他也是通过管理端登录对管
理端的用户进行设臵，分配权限等。
他们的关系如图3所示。
顶层包:
:
管理用户
顶层包:
:
图书管理员顶层包:
:
系统管理员
顶层包:
:
图书信息管理员顶层包:
:
用户信息管理员顶层包:
:
预定信息管理员
图3管理用户角色的关系
管理用户具体说明如下：
图书管理员
图书信息管理者。
管理图书信息，增加图书信息、删除图书信息、
〃
修改图书信息，读者要借图书，读者要还图书，读者要预留图书，
读者要撤销预留图书
系统管理员。
通过管理端对系统用户进行管理的人员，这个角色主要负责对管理端
用户的增删，权限的设臵等功能。
4.1.3数据库
数据库是一个与系统产生交互的外部系统，这个角色负责系统的数据
查询，增加，删除和修改等操作。
4.2系统主用例图
图书馆管理系统可以分成两个主要的组成部分，一个是客户端子系
统。
一个是管理端子系统。
客户端子系统功能主要是指读者通过登
录图书馆网站进行操作的功能。
管理端子系统功能是图书馆的图书
管理员管理图书信息，增加图书信息、删除图书信息、修改图书信
息，读者要借图书，读者要还图书，读者要预留图书，读者要撤销
预留图书等功能。
系统的主要用例如图4所示。
管理端子系统
顶层包:
:
管理用户
客户端子系统
顶层包:
:
读者
图4系统的主要用例
4.3客户端子系统
用户通过此系统可以进行图书查询（可按分类方式查找图书或通过关
键字进行查询），查看图书详细情况，用户登录，查看用户信息，修
改用户个人信息。
图5客户端的活动图，图6客户端的功能用例
图
查询用户信息
登录系统
确认信息
更改用户信息
查询图书
查询图书信息
顶层包:
:
用户
预定图书
预定图书
退出系统
图5客户端的活动图图6客户端的功能用例图
客户端管理的这些用例描述如下：
1：
查询用户信息。
读者登录到学校的图书馆网站可以通过登录
系统查询个人信息。
2：
更改个人信息、更改密码。
3：
查询图书。
读者可以通过网站查询图书的基本资料，是否可
借阅等信息。
4：
预定图书。
读者可以通过网站来查询图书预定图书，可以取
消预定。
4.3.1查询用户信息
用例描述：
用户信息查询
执行者：
用户
前臵条件：
用户已经打开网页
后臵条件：
用户成为该系统合法用户，可以登录系统
基本路径：
a）用户通过网址打开网页，登录系统。
b）用户填确认用户名，设臵密码。
c）点击确认。
4.3.2更改用户信息
用例描述：
用户修改个人信息
执行者：
用户
前臵条件：
用户已经登录系统
后臵条件：
管理员收到信息，信息更新。
基本路径：
a）按规则填写好用户姓名，性别，专业，密码等基本信息。
b）确认更改后的信息。
4.3.3查询图书信息
用例描述：
查询图书信息
执行者：
用户
前臵条件：
用户已经选择图书。
后臵条件：
选择借阅的图书。
基本路径：
a）选择图书
b）查询图书的基本信息
c）确定要借阅的图书
4.3.4用例描述：
预定图书
执行者：
用户
前臵条件：
用户已经确定要选图书。
后臵条件：
预定借阅的图书。
基本路径：
a）选择图书
b）查询图书的基本信息
c）确定要预借的图书
4.4管理端子系统
管理端子系统主要是提供学校图书馆的管理人员使用的功能，它
的功能分为图书管理，用户信息管理，预定图书管理，借阅图书管理
等部分。
每个登录者首先要通过安全认证然后确认权限，系统根据相
应的权限实现相应的功能。
图7是管理端的用例图。
管理登录
管理图书信息
图书信息管理者
借阅图书管理着
管理图书借阅
管理用户信息
管理图书预定
用户信息管理者
预定图书管理者
图7是管理端的用例图
1：
登录管理
登陆管理负责所有的登录端的登录，管理端的人员要登录到管理
端必须经过登录界面，输入自己的用户名和密码，然后系统判断这个
用户的权限信息，不同的登录人可能具有不同的权限，系统根据不同
的权限实现不同的功能。
1:
图书馆图书管理;由管理员登录到系统，进行对信息图书的
添加修改，删除，查看。
2：
用户信息管理：
由管理员登录到系统，进行对用户信息的查
看，修改，删除。
3：
图书预定管理：
由管理员登录到系统，查看图书预定信息，
对预定图书信息进行确认，修改，删除。
4：
图书借阅管理：
由管理员登录到系统，查看图书信息，核对
用户信息。
对借阅图书信息进行确认。
4.4.1登陆管理
登录到管理端的所有人都需要通过登录界面进入相应的管理界
面。
登录界面输入用户名和密码，系统首先判断用户名和密码的正确
性，然后根据用户名确定其权限，不同的登陆者具有不同的权限，根
据登陆者具有的权限将相应的功能显示在管理界面上，没有权限操作
的功能将不显示在这个界面上。
登录者数据库
登录系统
输入用户名和密码
提交合法性验证
登录到管理界面判断权限图8登录管理活动图
用例描述：
登录
前臵条件：
没有。
后臵条件：
如果用例成功，参与者可以启动系统并使用系统所提供的
功能。
反之，系统状态不变。
扩展点：
没有。
事件流：
基流：
当用户希望登录到系统中时，用例启动。
①系统提示用户输入用户名和密码。
②用户输入用户名和密码。
③系统验证输入的用户名和密码，若正确
（1），则用户登录到
系统中。
替代流：
1如果用户输入无效的用户名和/或密码，系统显示错误
信息，用户可以选择返回基流的起始点，重新输入正确的用户名和/
或密码：
或者取消登录，用全结束。
图书馆管理信息系统
管理图书
<<>>
<<>>
管理读者
<<>>
登录系统
借书
<<>>
还书
图书管理员
取消预约图书
<<>>
登录系统
*
*
<<>>
<<>><<>>
查询书目查询图书预约图书
读者图9图书馆管理信息系统
4.4.2图书信息管理图书信息是读者和管理员去了解图书的准要途径。
具体功能描述
如下：
用例描述：
维护书刊信息
前臵条件：
在这个用例开始前，必须登录到系统中。
后臵条件：
如果这个用例成功，系统添加、修改或删除书刊书目信息。
否则，系统的状态没有变化。
扩展点：
没有。
事件流：
基流
①当图书管理员想维护借阅者信息时，用例启动。
②系统要求图书管理员选择所想执行的活动（添加书种、删除书种
或修改书种）。
③如果选择的活动是“添加书种”，则执行分支流1：
添加书刊信
息。
④如果选择的活动是“删除书种”，则执行分支流2：
删除书刊信
息。
⑤如果选择的活动是“修改书种”，则执行分支流3：
修改书刊信
息。
分支流
1：
添加书刊信息
（1）图书管理员提供书刊的书名、作者、号等信息。
（2）系统添加该书刊信息。
2：
删除书刊信息
（1）图书管理员提供所要删除的书刊信息。
（2）系统查询所要删除的书刊
（2）
（3）系统删除该书刊的所有物理书刊的信息（3）
（4）系统删除书刊信息，以及相关的预定信息。
3：
更改书刊信息
（1）图书管理员提供所要修改的书刊信息。
（2）系统查询并显示书刊信息
（2）
（3）系统修改相应的的信息
（4）系统更新书刊信息。
替代流
1若书刊信息已存在，系统显示提示信息，用例终止。
2若查询不到该书刊，系统显示提示信息，用例终止。
3若有物理书刊借出，系统显示提示信息，用例终止。
4.4.3用户信息管理：
由管理员登录到系统，进行对用户信息的查看，修改，删除。
维
护借阅者信息具体功能描述如下
前臵条件：
在这个用例开始前，系统管理员必须登录到系统中。
后臵条件：
如果这个用例成功，系统添加、修改或删除借阅者信息。
否则，系统的状态没有变化。
扩展点：
没有。
事件流：
基流
①当系统管理员想维护借阅者信息时，用例启动。
②系统要求系统管理员选择所想执行的活动（添加借阅者、删除借
阅者或修改借阅者）
③如果所选的活动是“添加借阅者”，则执行分支流1：
添加借阅
者。
④如果所选的活动是“删除借阅者”，则执行分支流2：
删除借阅
者。
⑤如果所选的活动是“修改借阅者”，则执行分支流3：
修改借阅
者。
分支流：
1：
添加借阅者
（1）图书管理员提供借阅者的信息，如姓名、地址、邮政编码和身
份证号码等。
（2）系统存储借阅者信息
（1）。
2：
删除借阅者
（1）图书管理员提供借阅者的信息。
（2）系统查询借阅者
（2）。
（3）系统查询借阅者的借阅记录（3）
（4）系统删除借阅者的信息，以及借阅者的预定记录。
3：
更改借阅者
（1）图书管理员提供借阅者的信息。
（2）系统查询并显示借阅者的信息
（2），修改相应的信息。
（3）系统更新借阅者的信息。
替代流：
1若借阅者已存在，系统显示提示信息，用例终止。
2若查询不到借阅者，系统显示提示信息，用例终止。
3若存在借阅记录，系统显示提示信息，用例终止。
4.4.4预定图书管理
用例描述：
预定图书
前臵条件：
在这个用例开始前，图书管理员必须登录到系统中。
后臵条件：
如果这个用例成功，系统建立预订记录。
否则，系统的状
态没有变化。
扩展点：
没有。
事件流：
基流：
当图书管理员为借阅者预订书刊时，用例启动。
①图书管理员提供书刊书目、借阅者信息。
②系统检索书刊书目
（1）。
③检索借阅者
（2）。
④系统接受预定，创建预定记录。
⑤系统将预定记录存储在系统中。
替代流：
1该种书刊不存在，系统显示提示信息，用例终止。
2系统中不存在该借阅者，系统显示提示信息，用例终止。
用例描述：
取消预定管理
前臵条件：
在这个用例开始前，图书管理员必须登录到系统中。
后臵条件：
如果这个用例成功，系统删除预订记录。
否则，系统的状
态没有变化。
扩展点：
没有。
事件流：
基流
①图书管理员提供所预定的书刊书目、借阅者信息。
②系统检索所预定的书刊书目
（1）。
③系统检索借阅者
（2）。
④系统删除借阅者的预定信息（3）。
替代流：
1该种书刊不存在，系统显示提示信息，用例终止。
2系统中不存在该借阅者，系统显示提示信息，用例终止。
3预定信息不存在，系统显示提示信息，用例终止。
4.4.5借阅书刊
用例描述：
借阅图书
前臵条件：
在这个用例开始前，图书管理员必须登录到系统中。
后臵条件：
如果这个用例成功，在系统中建立并存储借阅记录，如果
必要还要删除预订记录。
否则，系统的状态没有变化。
扩展点：
借阅者预定了书刊。
事件流：
基流：
当借阅者从图书馆借阅书刊时，用例启动。
①图书管理员提供书刊书目、借阅者信息。
②系统检索书刊书目（）
（1）
③系统确定所借阅的物理书刊是否可以获得
（2），也即物理书刊是
否都已借出。
④系统检索借阅者（3）
⑤图书管理员将物理书刊借给借阅者
⑥记录借阅信息。
⑦若该图书为预定的图书，执行用例取消预定
替代流：
1该种书刊不存在，系统显示提示信息，用例终止。
2物理书刊都已借出，系统显示提示信息，用例终止。
3系统中不存在该借阅者，系统显示提示信息，用例终止。
用例描述：
返还书刊
前臵条件：
在这个用例开始前，图书管理员必须登录到系统中。
后臵条件：
在这个用例成功，系统删除借阅记录。
否则，系统的状态
没有变化。
扩展点：
没有。
事件流：
基流：
当借阅者返还所借的物理书刊时，用例启动。
①图书管理员提供所还物理书刊信息。
②系统检索物理书刊
（1）。
③系统查询物理书刊的借阅记录
（2）。
④系统删除借阅记录。
替代流：
1物理书刊不存在，系统显示提示信息，用例终止。
2若借阅记录不存在，系统显示提示信息，用例终止。
用例描述：
预定书刊
前臵条件：
在这个用例开始前，图书管理员必须登录到系统中。
后臵条件：
如果这个用例成功，系统建立预订记录。
否则，系统的状
态没有变化。
扩展点：
没有。
事件流：
基流：
当图书管理员为借阅者预订书刊时，用例启动。
①图书管理员提供书刊书目、借阅者信息。
②系统检索书刊书目
（1）。
③检索借阅者
（2）。
④系统接受预定，创建预定记录。
⑤系统将预定记录存储在系统中。
替代流：
1该种书刊不存在，系统显示提示信息，用例终止。
2系统中不存在该借阅者，系统显示提示信息，用例终止。
5.性能需求
5.1系统的页面要求如下。
（1）页面内容：
主题突出，站点定义，术语和行文格式统一，规范，
明确，栏目，菜单设臵和布局合理，传递的信息准确，及时。
内容
丰富，文字准确，语句通顺，专用术语规范，行文格式统一规范。
（2）导航结构：
页面具有明确的导航指示，且便于理解，方便用户使
用。
（3）技术环境：
页面大小合适，能用各种常用浏览器以不同的分辨率
浏览，无错误连接和空链接；采用处理，控制字体大小和版面布
局
（4）艺术风格：
界面、版面形象清晰悦目、布局合理，字号大小合适、
字体选择合理，前后一致，美观大方，动与静搭配恰当，动静效果好；
色彩和谐自然，与主题内容相协调。
5.2响应时间需求无论是客户端还是管理端，当用户登录，进行任何操作的时候，
系统应该及时的进行反应，反应时间在5秒以内。
系统应能检测出各
种非正常情况，如与设备的通信中断，无法连接数据客服务器等，以
避免出现长时间等待甚至无响应。
5.3可靠性需求系统应保证7*24小时秒内不宕机，保证20人可以同时在客户端
登录，此时系统能正常运行，正确提示相关内容。
5.4开放性需求系统应具有较强的灵活性，以时应将开功能扩展的需求
5.5可扩展性需求系统设计需求能够体现扩展性要求，以适应将来功能扩展的需求。
5.6系统安全性需求
系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。
系统需能够防止各类误操作可能造成的数据丢失，破坏。
防止用户非
法获得网页以及内容。
6产品提交提交产品为：
（1）应用系统软件包；
（2）数据库初始数据；
（3）系统开发过程文档；
（4）系统使用、维护说明文档，提交方式为介质
7.实现约束
系统地实现约束如下：
（a）操作系统为200
（b）开发平台为：
3.1.232
（c）数据库2000
8.签字本需求规格进过双方认证，特签字如表用户签署信息企业签署信息
单位名称****公司单位名称***********有限公司
签署人姓名***签署人姓名***
签署日期******签署日期******
升级会员 