3.2.p 类/对象 p 3.3 性能需求
正常情况下和峰值工作条件下，在一定时间内要处理的数据总量；响应时间；输出结果 精度。
本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求。静态数量化需求 可能包括：支持的终端数量；支持同时运行的用户数量；要处理的信息量和类型。
有时，静态数量化需求包含在命名为“能力”的独立部分。
动态数量化需求可能包括，如在正常和高峰工作负载条件下，在某时段内处理的事务处 理数、任务数和数据量。所有这些需求宜以可测量的方式规定。如应在小于 1s 内处理 95%的 交易量，而不是操作方不需等待事务处理结束。
注：适用于某个具体功能的数量化限制，通常作为该功能处理描述部分予以规定。
3.4 设计约束
宜规定可能由其他标准、硬件局限等引发的设计约束。
3.5 软件系统属性
有一些软件属性可以作为需求。规定所需求的软件属性是重要的，这样才能客观地验证 属性的实现情况。
3.6 其他需求
3.5 需求分析用例建模案例
在这里以大家熟悉的“图书馆管理信息系统”为例介绍需求分析，并用用例图、用例描 述和活动图表示。
3.5.1 需求陈述
由于“图书馆管理信息系统”很复杂，在这里仅以高校“图书管理”为例进行介绍。在 对图书管理系统进行详细调查与分析后，写出其需求陈述的文档。
“图书管理信息系统”的用户需求陈述如下：
在图书流通管理系统中，管理员要为每个读者建立借阅账户，并给读者发放不同类别的 借阅卡（借阅卡可提供卡号、读者姓名、类别、单位、职称等）。持有借阅卡的读者可以借阅、
归还、预约和续借图书，不同类别的读者可借阅图书的范围、数量和期限不同。读者来图书馆 借书，可能先查询馆中的图书信息，查询可以按书名、作者、图书编号、关键字进行。如果查 到则记下书号，交给流通组工作人员，等待办理借书手续。如果该书已经被全部借出，可做预 定登记，等待有书时被通知。如果图书馆没有该书的记录，可进行缺书登记。
办理借书手续时要先出示借阅证，借阅图书时，先输入读者的借阅卡号，系统验证借阅 卡的有效性和读者是否可继续借阅图书。如果借阅卡无效，让读者到办公室进行补办；如果借 书数量超出规定，则不继续借阅；如果有过期图书，则需要交纳罚款；如果可以借书，则显示
读者的基本信息（包括照片）供管理员人工核对。借书时系统登记图书证编号、图书编号、借 出时间和应还书时间。如果是预约图书，还要修改预约记录。
当读者还书时，流通组工作人员根据图书证编号找到读者的借书信息，察看是否超期。
如果已经超期，则进行超期处罚；如果图书有破损、丢失，则进行破损及丢失等处罚。登记还 书信息，做还书处理，同时查看是否有预定登记，如果有则发出到书通知。
图书采购人员采购图书时，要注意合理采购。如果有缺书登记，则随时进行采购。采购 到货后，编目人员进行验收、编目、上架、录入图书信息、发到书通知。图书馆管理人员定期 对图书进行盘库，如果图书丢失或旧书淘汰，则将该书从书库中清除，即图书注销。
以上是图书管理系统的基本需求。经过与图书馆工作人员的反复交流，他们提出了下列 建议：
1）当借阅的图书到期时，希望能够提前用短信或电子邮件方式提示读者。
2）读者希望能够实现网上查询和预定图书。
3）应用系统的各种参数设置最好是灵活的，由系统管理人员根据需要设定，如借阅期的 上限，还书提示的时间，预定图书的保持时间等参数。
3.5.2 需求分析
为了理解系统所要解决的业务问题， 以便掌握用户需求， 可以采用用例图进行需求建模。
用例图通过列出用例和角色，显示用例和角色的关系，从而给出了目标系统功能。用例建模 如下：
（1）确定参与者。通过对系统需求陈述的分析，可以确定系统有如下执行者：读者，流 通组工作人员，办公室工作人员，采购员，编目人员。读者可查询图书信息和个人借阅信息，
还可以在符合续借的条件下自己办理预约及续借图书；流通组工作人员完成读者借书、还书、
预约和续借图书及罚款等管理工作； 办公室工作人员为读者办理借书证有关事宜； 采购人员对 图书进行订购；编目人员进行图书的编目。
（2）确定用例。在确定参与者之后，结合图书管理的领域知识，进一步分析系统的需求，
识别出的用例有：借书、还书、缺书登记、预约、取消预约、查询、通知、读者管理、图书管 理、处罚、采购、编目、图书催还等。
（3）系统用例的审查与细化。要对系统用例逐一进行审核。用例的审核必须有用户参与，
可以通过用户访谈和讨论会的形式对系统用例进行审核。 确定每一个用例实现了用户的哪些需 求。是不是用户的每一个需求都有相应的用例来实现。基本路径和扩展路径是否完备，是否存 在冗余。
（4）确定用例之间的关系。确定参与者和用例之后，进一步确定用例之间的关系。业务 用例图如图 3.17 所示。
在用例图中的系统用例仅仅是一个名字，还需要对每个用例进行详细描述。在建立完用 例图后， 需要为图书流通管理系统业务用例图中某些用例编写用例文档。 用例文档中应包括如 下内容：名称；描述；前置条件；后置条件；活动的基本过程和扩展活动等。在用例文档中还 可添加一些可选内容，如参与者、状态、扩展点、被包含的用例、变更历史等。如借阅的用例 描述如下：
用例名称：借书
用例描述：当读者前来图书馆借书时，流通组工作人员启动该用例，该用例检查读者的
有效性及借阅记录，检查图书是否在库，实现读者借书活动。
⑧清空读者、图书编号等输入数据；
重复第②～⑧步，直到读者选择结束借阅；
⑨选择“退出” ；
⑩返回上一级界面；
扩展路径：
读者号不存在，显示读者无效
读者号存在，借书数量已经超限，显示数量超限 读者号存在，图书号无效，显示图书不存在 图书号，读者有效，图书不在库存，转预定处理。
每个用例都可以建立一个活动图。读者借书的活动图如图 3.18 所示。
图 3.18 借书活动图
还书 检查图书有效
读者无效/借书超限
图书无效
预借 借书 借书数量超出限制
图书不在库
未预定 不预借
删除预定图书
借书成功
[预定记录]
预借处理
[预定记录]
修改馆藏记录 修改借阅记录
通知图书借阅者 修改借阅者借书信息 检查读者有效
[读者] [借还书记录]
读者 管理员
输入借书证和 图书信息 读者无效
图书无效
图书预约
预借请求
检查借书在库
检查借书数量
3.5.3 系统开发方案
建议新系统采用微机网络系统，能与校园网及 Internet 连接，便于与供书商交流。能够实现业 务管理自动化；输入、输出标准化；文献存储高密度化；情报利用大众化。新系统具有图书的
3.5.4 系统可行性分析 1．技术可行性分析
目前已经成功地建立了许多复杂的管理信息系统，而图书馆管理信息系统是比较简单的，
系统开发人员具备开发的能力，有成熟的 C/S 和 B/S 技术。因此从技术上来说，完全可以建 成一个适用的图书馆管理信息系统。
2．经济效益分析
图书馆管理信息系统所产生的经济效益，与众多的因素有关，不宜采用传统的一次性投 资效益估计，因为开发系统的投资用在管理领域，但经济效益体现在科研、教学等诸多方面。
它可以使管理体制合理化和管理信息标准化， 可以使文献更好地被利用， 可以改进管理的手段。
新系统的统计分析功能更强大， 可以更好地为文献采购提供依据， 使得采购的文献使用性更强；
可以及时了解书库中图书在库情况及读者借阅情况， 可以进行预约和催还， 更好地提高文献的 利用率。管理信息系统所带来的效益是很难定量估计的，但新系统使用后可以减少工作人员，
因此，从经济上说是可行的。
3．运行管理方面
现有的图书馆管理人员只要进行培训完全可以胜任工作，对于缺少的计算机管理人员可 以通过招聘解决。 现有的运行环境只要稍加改进就可以保证新系统运行， 从运行管理方面看也 是可行的。
4．结论
由于管理信息系统的开发在国内外是一个技术上成熟的系统， 并且有可行的开发方案和切实的 工程技术保证，有学校领导的大力支持以及人员和资金的保证，因此开发图书馆管理信息系统是完 全可行的。