系统管理用例规约
系统用例规约
系统用例规约
系统用例规约是指对系统用例进行规范化描述的文档，包括用例的名称、编号、参与者、前置条件、后置条件、基本流程、扩展流程、异常流程等内容。
具体而言，系统用例规约需要包含以下内容：
1. 用例编号：每个用例都应该有一个唯一的编号，以便于管理和跟踪。
2. 用例名称：简短明了的用例名称，能够清晰地表达用例的功能。
3. 参与者：用例所涉及的各方参与者，包括主要参与者和次要参与者。
4. 前置条件：执行该用例之前必须满足的条件，如必须登录系统、必须有特定权限等。
5. 后置条件：执行该用例之后的系统状态，如生成订单、更新数据等。
6. 基本流程：用例的主要流程，包括各个步骤和参与者的交互。
7. 扩展流程：用例的可能扩展流程，通常用于描述一些特殊情况的处理方式。
8. 异常流程：用例的异常情况处理流程，包括可能出现的错误、异常和失败情况的处理方式。
总之，系统用例规约是一份详细描述系统用例的文档，能够帮助开发者更好地理解和实现系统功能，同时也能够让用户和参与者更清
晰地了解系统的功能和运行方式。
BBS论坛标准管理系统用例规约描述
用例规约描述（Window）版本 1.0变更统计填表说明本文档目标是依据《需求规格说明书》和系统原型，建立用例模型，并对用例模型进行具体描述。
用例规约描述是面向对象分析和设计关键步骤。
用例规约描述需要进行评审。
1引言文档（《用例规约描述文档》）是描述项目小组对项目进行需求分析得到相关用户和系统之间交互作用文本性描述文档。
目标用例是相关用户和系统之间相互作用文本性描述，从外部角度描述系统行为，表示系统应该做什么。
本文档经过用例规约描述，来深入说明该系统需求，是下一阶段系统设计基础，也是测试用例关键依据。
定义概述伴随Internet技术快速发展，BBS论坛已成为大家相互沟通、交流信息关键方法。
在论坛上，大家能够对某一领域提出自己碰到问题，随即，论坛上其它人会依据自己学识、经验发表意见或提出问题方法。
BBS论坛靠近了大家之间距离，它早已成为大家网上生活必备工具。
所以说BBS 论坛对当今社会是相当关键。
BBS 包含三种角色（Actor ）：系统总体功效模块图以下：图一：系统总体功效模块图BBS 论坛系统前台基础业务模块后台模块游客注册会员发帖回帖浏览帖子板块管理帖子管理会员管理2用例描述2.1 桌面子系统2.1.1 administrator模块member图二：Administrator模块图2.1.1.1 administrator管理会员用例规约：2.1.1.2 administrator管理论坛分类用例规约：2.1.1.3 administrator管理帖子用例规约：2.1.2 members管理模块look图二：members模块图2.1.2.1 members发帖回帖用例规约：用例规约：2.1.2.2帖子状态用例规约：2.1.3 tourist管理模块tourist图二：tourist模块图2.1.3.1 tourist 用例规约：。
公司管理系统的用例规约
公司管理系统的用例规约用例名称：公司管理系统参与者：管理员、员工前置条件：管理员已登录系统用例描述：管理员通过公司管理系统对员工进行管理和操作。
基本流程：1. 管理员登录公司管理系统。
2. 系统验证管理员身份并登录成功。
3. 管理员选择需要进行的操作：包括新增员工、删除员工、修改员工资料等。
4. 管理员输入相应的员工信息（新增员工需要填写所有必要信息，删除和修改员工需要提供员工的唯一标识）。
5. 系统验证输入信息的合法性，如输入员工ID是否已经存在等。
6. 管理员确认提交操作。
7. 系统保存相关信息，并进行相应的操作（如新增员工、删除员工、修改员工资料等）。
8. 管理员成功完成操作，系统提示操作成功。
备选流程：- 如果管理员登录失败（用户名或密码错误），系统提示登录失败并重新要求管理员输入用户名和密码。
- 如果管理员输入的员工信息有误（如员工ID已经存在），系统提示相关错误信息，要求管理员重新输入。
- 如果管理员取消了操作，系统不进行任何保存和操作，提示取消操作。
后置条件：管理员退出系统。
异常流程：- 管理员登录失败：系统提示登录失败并重新要求管理员输入用户名和密码。
- 管理员输入的员工信息有误：系统提示相关错误信息，要求管理员重新输入。
- 管理员取消了操作：系统不进行任何保存和操作，提示取消操作。
特殊需求：- 系统需要保证管理员的登录信息和操作信息的安全性和权限控制。
- 系统需要支持对员工信息的搜索、排序和过滤等功能。
- 系统需要提供数据备份和恢复功能，以保证数据的安全性和可靠性。
网上书店——用例规约
如果管理员输入无效的用户名和（/或）密码，系统显示错误信息。管理员可以选择返回基流的起始点，重新输入正确的用户名和（/或）密码；或者取消登陆，用例结束
前置条件
无
后置条件
用例成功后，管理员登陆进入系统
扩展点
无
9．维护顾客信息
简要说明 本用例用于维护顾客信息。包括添加、修改和删除顾客信息
事件流
基本流
无。
2．个人信息管理
简要说明
本用例用于给顾客维护个人信息。包括修改本人的账号、密码和联系地址等信息。
事件流
基本流
当顾客查看并修改个人信息时，开始执行以下基本流：
（1）系统返回给当前顾客在系统数据库中目前存储的个人信息。
（2）顾客可以对本人信息的一项或几项进行修改。
（3）顾客向系统提交修改后的个人信息。
扩展点
无
进入图书信息修改界面，修改并保存图书信息
S-2：删除图书信息
管理员单击删除按钮，相应的图书被删除并更新数据库
S-3：添加图书信息
进入图书信息添加页面，添加并保存图书信息
特殊需求
无
前置条件
管理员登陆
后置条件
用例成功后，图书信息被添加、改变或删除
扩展点
无
11．订单管理
简要说明
本用例是管理员用来管理顾客订单信息之用。该用例接收从银联系统反馈来的关于某顾客的订单是否扣款成功的信息，然后把该信息以电子邮件的方式通知该客户。对于扣款成功的订单，通知物流系统给该订单的顾客配送所购书籍
备选流
顾客输入的新信息验证错误
如果系统检测到顾客输入的信息格式或内容有错（如输入新密码和确认输入新密码不一致等），会向顾客给予错误提示，并要求用户重新输入或取消修改的操作。
人力资源管理系统用例规约描述(window)
用例规约描述（Window）版本 1.0变更记录引言文档（《用例规约描述文档》）是描述项目小组对项目进行需求分析得到的关于用户和系统之间交互作用的文本性描述文档。
目的用例是关于用户和系统之间相互作用的文本性描述，从外部角度描述系统的行为，表达系统应该做什么。
本文档通过用例规约描述，来进一步说明该系统需求，是下一阶段系统设计的基础，也是测试用例的重要依据。
定义概述ERMS用来对企业员工人力资源进行管理，主要功能包括员工资料管理、部门资料管理、考勤情况管理、业绩评定、用户权限管理。
因本系统包括桌面和WEB两个部分，各角色在使用系统时，因职责会有所偏重。
HRMS 包括3种角色（Actor ）：SystemUserSuperUserDMUDEU1 用例描述2.1 桌面子系统2.1.1 员工资料管理模块DMU2.1.1.1 新增员工信息 用例规约：图-1 HRMS桌面子系统主界面图-2 新增员工信息页面2.1.1.2 删除员工信息用例规约：图-5 删除员工信息界面2.1.1.3 修改员工信息用例规约：图-6 修改员工信息界面2.1.1.4 查询员工档案信息用例规约：图-8 查询员工档案信息界面图-9 查询员工信息界面2.1.2 部门资料管理模块ERAERM2.1.2.1 新增部门信息 用例规约：图-10 WIN -BMZL-1 新增部门页面图-11 WIN -BMZL-1 新增部门信息保存成功2.1.2.2 删除部门信息用例规约：图-12 WIN-BMZL-2 部门资料管理页面图-13 WIN -BMZL-2 删除部门信息页面2.1.2.3 更新部门信息用例规约：图-14 WIN -BMZL-3 部门信息更新页面2.1.2.4 查询部门信息用例规约：图-15 WIN -BMZL-4 部门信息查询页面2.1.2.5 调动员工用例规约：2.1.4 考勤管理模块DMU2.1.4.1 设置考勤策略用例规约：图-19 WIN -JXGL-5 考勤策略设置页面2.1.4.2 更新考勤策略用例规约：2.1.4.3 查询/删除当日考勤记录用例规约：图-20 WIN -KQGL-3 当日考勤查询/删除页面2.1.4.4 查询/删除历史考勤记录用例规约：图-21 WIN -KQGL-4 查询/删除历史考勤页面2.1.6 薪金管理模块ERM2.1.6.1 薪金计算用例规约：图-26 WIN -XJGL-1 薪金计算页面2.1.6.2 查看员工薪金用例规约：图-27 WIN -XJGL-2 查询员工薪金页面2.1.6.3 部门汇总用例规约：图-28 WIN -XJGL-3 部门汇总薪金页面图-29 WIN -XJGL-3 部门汇总薪金显示页面2.1.6.4 薪金设定用例规约：图-30 WIN -XJGL-4 薪金设定2.1.7 系统用户管理模块SuperUser2.1.7.1 新增角色用例规约：图-31 WIN -YHGL-1 系统角色信息编辑页面2.1.7.2 更新角色用例规约：2.1.7.3 删除角色用例规约：2.1.7.4 查询角色用例规约：2.1.8 登陆模块2.1.8.1 登陆用例规约：图-32 WIN-DLXT-1 登陆系统页面图-33 WIN-DLXT-1 修改密码页面。
用例规约
实验室设备管理系统用例规约登录用例简要说明：本用例说明用户如何登录到系统。
角色：管理员、实验员、学生前置条件：启动程序，进入登录界面基本事件流：1.用户输入基本信息（登录名和密码），点击确定按钮2.系统查找数据库，看该用户是否在数据库中。
若存在则进入主页面。
备选事件流： 1.输入无效的用户名或密码，提示用户名或密码不能为空或者提示用户名或密码不正确。
后置条件：登录成功特殊需求：没有和本用例有关的特殊需求。
扩展点：没有和本用例有关的扩展点。
添加学生用例简要说明：本用例说明管理员如何添加学生用户到系统。
角色：管理员前置条件：拥有初始化用户名脚本基本事件流：1.管理员通过脚本等方式初始化以确定的用户名，执行脚本。
2.系统查找数据库，看该用户是否在数据库中。
若不存在则随机生成密码并插入数据库,显示的返回用户名及密码；若用户名存在，则直接返回以待修改。
备选事件流： 1.输入用户名无效，则返回无效的用户名并统计。
后置条件：没有和本用例有关的后置条件。
特殊需求：没有和本用例有关的特殊需求。
扩展点：没有和本用例有关的扩展点。
删除学生用例简要说明：本用例说明管理员如何从系统中删除学生用户。
角色：管理员前置条件：已经成功登陆到系统。
基本事件流：1.管理员输入要删除的学生学号或学号范围，执行删除功能。
2.系统查找数据库，看该用户是否在数据库中。
若存在则删除对应学生信息。
备选事件流： 1.未找到对应学号的学生，系统提示未找到该用户。
后置条件：删除成功。
特殊需求：没有和本用例有关的特殊需求。
扩展点：没有和本用例有关的扩展点。
增加设备用例简要说明：本用例说明管理员如何增加设备并记录进入系统。
角色：管理员前置条件：已经成功登陆到系统。
基本事件流：1.管理员填写设备各种信息，确定添加。
2.系统把对应信息写入数据库，更新数据库。
备选事件流： 1.输入了已存在的设备编号，系统提示编号中已存在。
后置条件：增加成功。
特殊需求：没有和本用例有关的特殊需求。
系统管理用例规约
系统管理用例规约
系统管理用例说明
用例名系统管理
简单描述管理员登录系统，点击系统管理，可以对操作员及密码，权限进行管理。
前置条件管理员登陆成功，商品进销存管理系统能正常运行
后置条件如果用例成功，操作员的信息，密码，权限会发生改变；
事件流
基流1.管理员登陆进入系统；
2.点击打开系统管理；
3.选择要修改的条目；
4.点击按钮
5.进行相关操作；
6.填写相关信息；
7.提交信息
扩展流
7a.未填写完毕或信息有误
7a1.系统提示错误信息 7a2.点击确定
7a3.继续填写信息。
uml用例规约
uml用例规约UML (Unified Modeling Language) 是一种广泛应用于软件工程领域的建模语言，它通过图形化的方式描述软件系统的不同方面。
其中，用例规约是 UML 中用例模型的一部分，用于详细定义系统的功能需求。
用例规约中包含了用例名称、参与者、前置条件、后置条件、基本流程以及可选的替代流程等内容。
下面将详细介绍用例规约的结构和各个部分的含义。
一、用例名称用例名称应简洁明确地描述该用例的功能。
例如，对于在线购物系统，一个用例的名称可以是“用户下单”。
二、参与者参与者是指与系统进行交互的实体，可以是人、其他系统或外部设备等。
在用例规约中，列出参与者的名称和对其的简要描述，以便清楚地了解使用该用例时所涉及的角色。
三、前置条件前置条件是指执行该用例前必须满足的条件。
例如，对于“用户下单”的用例，前置条件可能包括用户已登录到系统并选择了要购买的商品。
四、后置条件后置条件是指执行该用例后的系统状态或结果。
例如，对于“用户下单”的用例，后置条件可能包括生成订单并跳转到支付页面。
五、基本流程基本流程描述了用例的主要执行步骤。
通常按照时间顺序，从开始到结束依次描述每个步骤。
在描述基本流程时，可以使用活动图或流程图等图形工具来更好地展示。
六、可选的替代流程替代流程描述了在特定情况下，用例的执行可能会走不同的流程路径。
例如，在“用户下单”的用例中，用户可能会取消订单或选择使用优惠券等。
这些情况可以在替代流程中进行描述。
除了上述几个部分外，用例规约还可以包含其他内容，如预置条件、扩展点、例外处理和相关文档等。
这些内容可以根据具体的需求和项目进行适当的扩展。
在编写用例规约时，需要注意以下几点：1. 确保用例规约的准确性和清晰性，避免模糊或歧义的描述。
2. 用例名称应该简明扼要，能够准确地传达该用例的功能。
3. 参与者的身份和角色应该明确定义，以便准确描述用例的执行者和相应的交互。
4. 前置条件和后置条件应该具体明确，并确保执行用例时满足前置条件，可以达到预期的后置条件。
用例规约表格模板(基于RUP)
班级：测绘工程学号：1201721193 姓名：杨宇功能需求：1.该系统必须允许注册用户（包括客户和商家）审查他们过去三年的用户历史订单记录或销售记录2.该系统允许用户通过关键字搜索店铺或菜品3.该系统必须允许用户通过销量、评分、距离等条件进行店铺优先级排序4.该系统必须允许登录客户在店铺未打烊且送餐距离合理的情况下下单5.该系统必须允许登录客户给下过的订单评价6.该系统必须允许登录客户下单时使用多种付款平台7.该系统必须保留客户订单记录3年8.该系统必须允许客户和商家两种角色登录该系统9.该系统必须允许商家接单10. 该系统必须允许商家处理订单非功能需求：1. 该系统应满足在ios及android系统运行2. 该系统在10:00-12:30以及5:30-7:00时间段内支800万用户并发使用，其他时间支持200万用户并发使用3. 该系统可以检测用户点评内容是否，若内容违规则可以进行删除。
4. 系统安全：用户在身份认证、授权控制、私密性等方面的要求。
5. 系统易用：系统操作界面美观、简便，通俗，便于操作。
6. 系统可维护：系统在出现故障时可以及时维修，使其数据恢复。
客户用例图：商家用例图系统管理员用例图（1）用例图（1）用例规约：用例编号UC-1 用例名称登录用例描述用户登录该系统主参与者用户前置条件无后置条件登录到系统级别基本事件流程：1.系统提示用户输入用户名和密码2.用户输入用户名和密码3.系统验证用户名和密码，若正确，则登入到系统中。
如果用户输入无效的的用户名和密码，系统显示错误信息，并返回重新提示用户输入用户名和密码或者取消登录候选事件流程：1.点击注册按钮，注册一个新账号特殊需求无扩展点无备注无（2）用例图（2）用例规约：用例编号UC-2 用例名称提交订单用例描述客户提交订单主参与者客户前置条件用户已经成功登入该系统后置条件无级别基本事件流程：1.成功登录系统2.通过查找将需要的菜品添加到购物车3.点击提交订单按钮候选事件流程：1.退出该系统特殊需求无扩展点无备注无（3）用例图2）用例规约：用例编号UC-3 用例名称接收订单用例描述商家接单主参与者商家前置条件商家成功登入商家版系统后置条件无级别基本事件流程：1.成功登录系统2.进入订单处理模块3.点击接单按钮候选事件流程：1.退出该系统特殊需求无扩展点无备注无（4）用例图4）用例规约：用例编号UC-4 用例名称增加菜品用例描述商家通过该系统增加店铺的菜品（包括菜品的名称数量上传图片等）主参与者商家前置条件商家成功登录商家版系统后置条件无级别基本事件流程：1.成功登录商家版系统2.进入管理模块3.点击菜品进入菜品管理模块4.添加菜品名称、相关促销信息以及上传菜品图片5.点击保存按钮候选事件流程：1.返回到主界面2.退出系统特殊需求无扩展点无备注无（5）用例图5）用例规约：用例编号UC-5 用例名称增加活动模块用例描述系统管理员根据需要增加美团外卖活动模块如“今日特价2折”模块主参与者系统管理员前置条件管理员成功登录该系统后置条件完成模块管理级别基本事件流程：1.管理员成功登录系统2.进入活动管理模块3.点击增加活动按钮4.输入相关活动信息（包括活动规则）5.确认、提交候选事件流程：1.退出该系统特殊需求无扩展点无备注无用户下单付款数据流图。
需求之系统用例规约
需求之系统用例规约
如何寻找涉众
• 如果系统的这个用例做得不好，谁会遭殃？
WANGC☺HUN
需求之系统用例规约
执行者
• 软工货物送达日期超过计划中的交付日期，扣减 15%的金额
• 合同的总金额不超过买方的信用额度
需求之系统用例规约
非功能需求
WANGC☺HUN
• 可用性。
–如果系统按照程序员的意图工作，并且完成能完成任务， 但用户不喜欢用。
• 人事专员第一次使用时30分钟内能学会添加新员工
需求之系统用例规约
非功能需求
录入保单() 录入保单()
经理
审核保单()
需求之系统用例规约
书写路径步骤的注意事项
WANGC☺HUN
• 按照交互四部曲书写
–执行者和系统一个个回合交互，直到达成目的。每个回 合的步骤分为四类：请求、验证、改变、回应。
• 例子：
–1.顾客请求注册 –2.系统反馈注册界面 –3.顾客提交注册信息 –4.系统验证注册信息充分 –5.系统生成顾客账户 –6.系统反馈所创建的顾客账户
达想通知的联系人 • 技术专家：担心通知内容搞错损害声誉 • 被通知联系人：担心收到太多垃圾信息 • 公司助理：担心操作太复杂
需求之系统用例规约
案例
• 基本路径： • 1.公司助理选择公开课，请求创建通知任务。 • 2.系统验证所选公开课适合创建通知任务 • 3.系统反馈设置通知任务界面 • 4.公司助理提交通知任务设置 • 5.系统反馈公开课通知任务的范围 • 6.公司助理确认 • 7.系统为所选公开课生成通知任务 • 8.系统反馈已经创建的通知任务
UML旅店管理系统用例图、用例规约
UML旅店管理系统⽤例图、⽤例规约
⼀.旅店管理系统⽤例图
⼆．⽤例规约
1.预定房间
1 .1简要说明
本⽤例允许客户预订旅店的未被预订的房间，系统提供未被预订的房间的信息列表。
1.2 先置条件
客户进⼊旅店管理系统，并选择预订房间功能。
1.3 事件流
（1）基本事件流
A 客户选择要预订的房间的类型，双⼈间或单⼈间。
B 根据客户选择的房间类型，从所有该类型房间中，筛选未被预定的房间，将这些房间的信息列表显⽰，供客户查询。
C 客户选定房间，并输⼊要预订的天数。
（2）备选事件流
A 客户所需要类型的房间已全部被预订，则提⽰客户，该类型房间已全部被预订，询问客户是否选择另⼀类型的房间。
B ⽤户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发⽣冲突，则系统提⽰，该房间在哪些⽇期⾥已被预订，并询问当前客户是更换房间还是修改预订天数。
1.4 后置条件
A 客户选择房间和预订天数并确认后，系统要求客户输⼊客户信息，包括客户的姓名、地址、联系电话、有效证件号。
另外，系统将计算出客户需要缴纳
的定⾦和总费⽤，并显⽰出来。
B 客户重新选择房间类型，或修改天数，则刷新⽤户界⾯。
餐饮管理系统 软件工程 用例规约
查询菜品信息的参与者是顾客，用于查看酒店所有菜品的详细信息。
查询菜品用例规约
修改菜品信息的参与者是管理员，用于修改酒店所有菜品的详细信息。
修改菜品用例规约
删除菜品信息的参与者是管理员，用于删除酒店菜品的详细信息。
删除菜品用例规约
查询员工信息的参与者是管理员，用于查看酒店所有员工的详细信息。
查询员工用例规约
修改员工信息的参与者是管理员，用于修改酒店所有员工的详细信息。
修改员工用例规约
删除员工信息的参与者是管理员，用于删除酒店员工的详细信息。
删除员工用例规约
查询vip客户信息的参与者是管理员，用于查看酒店所有vip客户的详细信息。
查询vip客户信息用例规约
修改vip客户信息的参与者是管理员，用于修改酒店所有vip客户的详细信息。
修改vip客户信息用例规约
删除vip客户信息的参与者是管理员，用于删除酒店vip客户的详细信息。
删除vip客户信息用例规约。
需求之系统用例规约
系统用例关系规约
总结词
系统用例之间的关系规则，包括依赖关系、 包含关系等。
详细描述
系统用例关系规约规定了系统用例之间的关 系规则，包括依赖关系、包含关系等。依赖 关系是指一个系统用例依赖于另一个系统用 例的存在或执行结果，包含关系是指一个系 统用例包含另一个系统用例的全部或部分功 能。关系规约还规定了不同用例之间的关系
系统稳定性
保证系统的稳定运行，避免因 系统故障影响生产。
系统可维护性
方便对系统进行维护和升级， 降低维护成本。
系统可扩展性
支持系统的扩展和升级，满足 企业未来发展的需求。
02
需求规约
功能性需求
用户管理
系统应提供用户注册、登录、信息修改、 密码找回等功能，确保用户能够方便地
使用系统。
报表生成
系统应提供报表生成功能，根据用户 需求生成各类报表，便于用户对数据
系统功能
生产计划管理
制定生产计划，安排生产任务，监控生产进 度。
工艺流程管理
定义生产工艺流程，控制生产过程，确保产 品质量。
设备管理
管理生产设备，监控设备运行状态，保证设 备正常运行。
数据分析与决策支持
收集和分析生产数据，为企业决策提供支持。
系统非功能需求
系统安全性
确保系统数据的安全性，防止 数据泄露和被篡改。
进行统计分析。
数据管理
系统应对数据进行增、删、改、查等 操作，确保数据的准确性和完整性。
权限管理
系统应对不同用户角色进行权限控制， 确保数据的安全性和系统的稳定性。
非功能性需求
性能要求
系统应满足一定的响应速度和吞吐量要求，确保 用
系统应具备友好的用户界面和操作流程，方便用 户快速上手和使用。
用例规约——精选推荐
学籍管理系统1.术语表2.系信息管理（系统管理员）2.1用例规约2.11 查询系信息2.12删除系信息用例规约：2.13 修改系信息用例规约：2.14录入系信息用例规约：图SSM-XXXM-1图SSM-XXXM-2图SSM-XXXM-3图SSM-XXXM-4 3.补充规约补充规约3.1简介3.1.1目的本文档的目的是定义学籍管理系统的需求。
本补充规约列出了不便于在用例模型的用例中获取的系统需求。
补充规约和用例模型一起记录对系统的一整套需求。
3.1.2范围本系统适用于学校的学籍信息管理，使得管理员和教师从繁重的管理工作中解脱出来，轻松管理学生的相关信息。
3.1.3参考资料适用的参考资料包括：1.补充规约说明（百度文库）2.UML说明与Rose建模3.2功能3.2.1系统错误记录所有的系统错误都应当记录下来。
系统的致命错误会导致系统的有序关闭。
系统错误消息应包括错误的文本说明、操作系统的错误代码（如果适用于该错误）、检测错误状态的模块、数据戳和时间戳。
所有的系统错误都应保存在错误日志数据库中。
3.2.2在线操作学生可以在线查询和修改个人信息，导师可以查询学生的信息，并对其信息进行提出建议或修改，管理员对系统进行维护及时发布信息。
3.3可用性3.3.1Windows 兼容性桌面用户界面应与Windows XP/7 兼容。
3.3.2易于使用的设计学籍管理系统用户界面的设计应当着眼于易于使用，使具有一定计算机知识的用户群体不需要经过更多的培训就能够使用该系统。
3.4可靠性本节列出了所有的可靠性需求。
3.4.1 <可行性>该系统必须提供一个Windows XP /7 的用户交互界面。
3.4.2 <平均故障间隔时间>MTBF（平均故障间隔时间）需求将在下次迭代中定义。
3.5性能3.5.1<性能需求一>该用户的数据库应能够支持3000 名用户对数据库的同一时刻的访问，并且该系统的服务器应能够支持1000名用户对其的同一时刻的访问。
图书管理系统用例规约1
借阅图书（Borrow the book）
用例描述
借阅者通过此用例向系统查询并向图书管理员提交借书请求
执行者
借阅者
前置条件
1.借阅者借阅证件在有效期内
2.借阅者没有逾期未归还的图书
后置条件
1.创建借书清单
2.更新借阅人借阅记录
主过程描述
1.计算机显示图书管理系统界面，用户用借阅证提供的帐号登录系统
2.用户选择查询图书，计算机显示查询界面
3.用户按书名Hale Waihona Puke 作者或出版社查询，计算机显示查询结果
4.用户可单选或多选书本，并请求图书管理员确认借阅。计算机显示确认借阅图书清单。
5.计算机执行后置条件。用例结束
分支过程描述
4.1.1用户确认后，如果选择继续借书，计算机执行2；
4.2.1用户选择放弃，计算机执行2；
4.3.1用户选择放弃并退出系统，计算机执行1；
异常过程描述
1.1.1借阅证已过期，拒绝登录，用例结束
1.2.1借阅人有逾期未归还书本，启动归还图书用例(Return the book)
业务规则
4.至少选择一本,至多选择三本
涉及的业务实体
图书
借阅证
上表是用例规约内容。过程描述中的章节号标明每一个可能的活动。例如,4代表“用户可单选或多选书本，并确认借阅。计算机显示确认借阅图书清单”这个活动，而4.1.1代表第4步的第一个可选分枝的第一步，4.1.2.1.1代表第4步的第一个可选分枝的第二步中的第一个可选分分枝的第一步。