用例分析之用例规约样例
- 格式:doc
- 大小:57.00 KB
- 文档页数:5
公司管理系统的用例规约用例名称:公司管理系统参与者:管理员、员工前置条件:管理员已登录系统用例描述:管理员通过公司管理系统对员工进行管理和操作。
基本流程:1. 管理员登录公司管理系统。
2. 系统验证管理员身份并登录成功。
3. 管理员选择需要进行的操作:包括新增员工、删除员工、修改员工资料等。
4. 管理员输入相应的员工信息(新增员工需要填写所有必要信息,删除和修改员工需要提供员工的唯一标识)。
5. 系统验证输入信息的合法性,如输入员工ID是否已经存在等。
6. 管理员确认提交操作。
7. 系统保存相关信息,并进行相应的操作(如新增员工、删除员工、修改员工资料等)。
8. 管理员成功完成操作,系统提示操作成功。
备选流程:- 如果管理员登录失败(用户名或密码错误),系统提示登录失败并重新要求管理员输入用户名和密码。
- 如果管理员输入的员工信息有误(如员工ID已经存在),系统提示相关错误信息,要求管理员重新输入。
- 如果管理员取消了操作,系统不进行任何保存和操作,提示取消操作。
后置条件:管理员退出系统。
异常流程:- 管理员登录失败:系统提示登录失败并重新要求管理员输入用户名和密码。
- 管理员输入的员工信息有误:系统提示相关错误信息,要求管理员重新输入。
- 管理员取消了操作:系统不进行任何保存和操作,提示取消操作。
特殊需求:- 系统需要保证管理员的登录信息和操作信息的安全性和权限控制。
- 系统需要支持对员工信息的搜索、排序和过滤等功能。
- 系统需要提供数据备份和恢复功能,以保证数据的安全性和可靠性。
图书管理系统用例规约用例ID: 1角色:借书者,图书管理员用例说明:读者刷卡,系统检索并判断该读者图书数量及借阅期限权限能否再借阅,如可借阅,图书管理员通过读码器读取图书上的条形码进行登记。
前置条件:借书者提出要借的书名,图书管理员查找到该书还有库存基本事件流: 参与者动作系统响应1. 图书管理员选择“借阅登记”,提交“借阅登记”请求;3.借书者输入借阅登记信息2. 系统显示“借阅登记”空白窗口;4.系统列表显示出该读者在借图书信息和该读者借阅期限的权限;若借书者输入借阅登记信息非法,进入4.1.1,若借书者所需书籍不存在,进入 4.2.1若书籍数量不足,进入4.2.2其他事件流: 无异常事件流: 参与者动作系统响应4.1.1登记信息不合法4.1.2未填写登记信息4.2.1图书馆未收录该书籍4.2.2书籍数量不足4.1.1提示用户重新输入4.1.2提示用户输入登记信息4.2.1提示用户预订购买图书4.2.2提示用户预订借阅图书后置条件:用户借书成功用例ID: 2角色:借书者,图书管理员用例说明:读者刷卡,系统检索并显示出该读者在借图书信息和该读者已借阅的时间;前置条件:还书者之前在该图书馆借阅过书籍基本事件流: 参与者动作系统响应1. 图书管理员选择“还书登记”,提交“还书登记”请求;3.还书者输入借阅登记信息2. 系统显示“还书登记”空白窗口;4.系统列表显示出该读者在借图书信息和该读者已借阅的时间。
若超过借阅时限,进入4.1.1其他事件流: 无异常事件流: 参与者动作系统响应4.1.1超过借阅时限 4.1.1提示用户缴纳违约金后再进行还书后置条件:用户还书成功用例ID: 3角色:借书者,图书管理员用例说明:读者刷卡,系统检索并显示出该读者在借图书信息和该读者已借阅的时间;前置条件:图书馆缺少该图书基本事件流: 参与者动作系统响应1. 图书管理员选择“预订登记”,提交“预订登记”请求;3.还书者输入预订登记信息2. 系统显示“预订登记”空白窗口;4.系统列表显示出该读者想要预定的图书信息其他事件流: 无异常事件流: 参与者动作系统响应后置条件:用户预订成功用例ID: 4角色:借书者,图书管理员用例说明:读者刷卡,系统检索并显示出该读者预订图书信息前置条件:用户进行过图书预订基本事件流: 参与者动作系统响应1. 图书管理员选择“取消预订登记”,提交“取消预订登记”请求;3.借书者输入预订登记信息5.借书者选择取消预订2. 系统显示“取消预订登记”窗口;4.系统列表显示出该读者预订图书信息6若用户之前进行过预订,则取消成功。
用例技术-用例规约
1.用例名称:销户
2.简要说明:
帮助银行工作人员完成银行客户申请的活期账户销户工作
3.事件流
3.1基本事件流
1)银行工作人员进行“活期帐户销户”程序界面;
2)银行工作人员用磁条读取设备刷取活期存折磁条信息;
3)系统自动显示此活期帐户的客户资料信息和帐户信息;
4)银行工作人员核对销户申请人的证件,并确认销户;
5)系统提示客户输入取款密码;
6)客户使用密码输入器,输入取款密码;
7)系统校验密码无误后,计算利息,扣除利息税(调用计息用例),计算最终销户金额,
并打印销户和结息清单;
8)系统记录销户流水及其分账信息。
3.2扩展事件流
1)如果存折磁条信息无法读出,需要手工输入帐号;
2)如果销户申请人的证件与客户资料信息不符或其它因素,而不受理的,银行工作人
员直接退出。
3)如果系统密码校验错误,提示重新输入密码;密码校验失败超过3次,系统提示并
自动退出;
4.非功能需求:
申请受理处理的过程操作时间应在30少内;
打印的销户和结息清单应该清晰明了
5.前置条件:帐户为正常状态(即不是挂失、冻结或销户状态)。
6.后置条件
销户成功并将销户信息存入数据库,证件不符而退出,密码不符而退出。
7.扩展点无
8.优先级高。
班级:测绘工程学号: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.退出该系统特殊需求无扩展点无备注无用户下单付款数据流图。
用例模板
用例名称(用例名)
用例目标(用例在系统中的目标)
级别(概要任务/首要任务/子功能)
活动者(此用例的活动者)
状态(未定义路径/只定义了初始路径/路径定义完成)
前置条件(用例执行千系统应具有的状态)
后置条件(用例成功执行后系统应具有的状态)
主路径(用例主路径的名称)
可选路径(用例的可选路径)
例外路径(用例的例外路径)
举例:
用例名称修改密码
用例目标当用户修改自己的密码时用例开始。
它处理修改密码问题。
当用户结束修改市用例结束
级别子功能
活动者用户
状态只定义了初始路径
前置条件用户登录进入系统
后置条件用户的密码已得到修改
主路径用户修改密码,系统保存修改
可选路径用户修改密码,最后放弃对密码的修改
例外路径用户输入的原密码有误,或者两次输入的新密码不一致,系统显示错误信息。
用户可以选择返回主路径的起始点,重新输入正确的原
始密码以及两次一致的新密码;或者取消修改。
ABC 医疗影像后处理系统 V2.0用例规约: Process Colon Series中文名称:分析结肠序列用例编号:CU-ABC-COLON-BASE-001主编:***Version 1.0 1.版本历史:2.目录1.版本历史: (1)2.目录 (1)3.简要说明 (1)4.执行者(ACTORS) (2)5.前置条件(PRE-CONDITION) (2)6.后置条件(POST-CONDITION) (2)7.涉众利益(STAKEHOLDER) (2)8.用例场景 (USE CASE SCENARIO) (2)8.1.基本流程(B ASE F LOW) (2)8.2.扩展流程: (2)9.特殊需求(SPECIAL REQUIREMENT) (3)3.简要说明处理数据,显示结肠的三维图像等。
具体包括:1、读取序列数据,2、自动结肠分割3、自动提取中心线,4、三维图展示,渲染效果;5、在三维图中显示中心线;4.执行者该用例由ABC中的《用例:Process Request Series》启动。
5.前置条件1、Process Request Series用例已经正确地获得了序列数据,并生成了体数据;2、命令已经被正确解析为COLON分析;6.后置条件序列被正确分析成结肠,完成结肠初步路径的提取显示和三维效果显示。
7.涉众利益8.用例场景8.1.基本流程(Base Flow)1.系统分析体数据,对数据进行处理,分割出结肠;2.系统对数据进行处理,提取中心线;3.系统显示数据到默认布局的界面(3D、ACS,ENDO,BAND视图);4.系统显示结肠中心线到3D视图中;5.系统显示渲染效果。
6.如图所示:其中读取序列数据(包括自动生成数据由调用方提供)18.2.扩展流程:9.特殊需求1、结肠包括的视图有:3D,Axial, Coronal, Sagittal,3D Zoom,Axial Zoom, Coronal Zoom, Sagittal Zoom, Endo,Band,Cube。
用户登录用例图用例规约:用例名称:登录用例ID:IBM_ESHOP_002.1 角色:普通用户用例说明:用例主要功能是实现登录,起始于普通用户的登录前置条件:启动程序,进入登录界面基本事件流:参与者动作系统响应 1. 用户输入基本信息(登录名和密码),点击确定按钮2.系统查找数据库,看该用户是否在数据库中。
若存在则进入主页面,若不存在,则进入2.1.1;若未输入,则进入2.2.2其它事件流:无异常事件流:参与者动作系统响应2.1.1未输入用2.2.1用户名不2.1.2未输入2.2.2密码不正确2.1.1 提示用户名或密码不能为空2.2.2提示用户名或密码不正确。
后置条件:登录成功添加联系人用例图用例规约:用例名称:添加联系人用例ID:IBM_ESHOP_002.2 角色:普通用户用例说明:该用例主要功能是添加联系人,用例起始于普通用户点击“添加”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.进入主界面,用户点击“添加”按3.用户添加联系人的相关信息,点击“确定”按钮2.系统响应点击事件,进入添加界面4.判断用户的输入是否合法,若合法,则返回主界面,若不合法:若输入信息为空,则其它事件流:无异常事件流:参与者动作系统响应4.1.1.1若未添加姓名4.1.2.1.1若未添加Emai4.2.1.1 若Email格式不正确4.2.2.1 若输入固定电话格式不4.2.3.1若输入手机格式不正确4.1.1.2 系统提示“必须输入姓名”4.1.2.2系统提示“必填”4.2.1.2 系统显示“邮件格式不正确”4.2.2.2 系统提示“8位电话号码”4.2.3.2 系统提示“只能输入数字”后置条件:添加联系人成功,返回主界面修改联系人用例图用例规约:3.用户对联系人姓名、性别、出生日期、Email、职务、固定电话、手机、住址、备注信息进行修改,点击“确定”按钮5.系统对用户的输入进行判断,若合法,则弹出对话框,提示“修改联系人成功”其它事件流:无异常事件流:5.1姓名未输入,系统给出提示对话框“必须输入姓5.2 Email未输入,系统给出提示对话框“必填”后置条件:修改信息成功,返回主界面删除联系人用例图用例规约:查找联系人用例图用例规约:用例名称:查找联系人用例ID:IBM_ESHOP_002.4 角色:普通用户用例说明:该用例主要功能是从列表中查看联系人信息,用例起始用户点击“查找”按钮前置条件:进入主界面基本事件流:参与者动作系统响应1.用户点击“查找”3.用户可以根据选择分组名称,填写邮箱、职位、姓名、手机。
1、登陆系统
系统中的所有参与者均可以使用本用例登陆系统,要求输入合法的用户名和密码。
登录系统用例规约
查询菜品信息的参与者是数据管理人员、顾客,用于查看酒店所有菜品的详细信息.
查询菜品用例规约
修改菜品信息的参与者是数据管理人员,用于修改酒店所有菜品的详细信息.
修改菜品用例规约
修改菜品信息的参与者是数据管理人员,用于增加酒店菜品的详细信息。
增加菜品用例规约
删除菜品信息的参与者是数据管理人员,用于删除酒店菜品的详细信息。
删除菜品用例规约
查询员工信息的参与者是数据管理人员,用于查看酒店所有员工的详细信息。
查询员工用例规约
修改员工信息的参与者是数据管理人员,用于修改酒店所有员工的详细信息。
修改员工用例规约
增加员工信息的参与者是数据管理人员,用于增加酒店所有员工的详细信息。
增加员工用例规约
删除员工信息的参与者是数据管理人员,用于删除酒店员工的详细信息。
删除员工用例规约
10、查询vip客户信息
查询vip客户信息的参与者是数据管理人员,用于查看酒店所有vip客户的详细信息。
查询vip客户信息用例规约
修改vip客户信息的参与者是数据管理人员,用于修改酒店所有vip客户的详细信息。
修改vip客户信息用例规约
增加vip客户信息的参与者是数据管理人员,用于增加酒店vip客户。
修改vip客户信息用例规约
删除vip客户信息的参与者是数据管理人员,用于删除酒店vip客户的详细信息。
删除vip客户信息用例规约。
UML旅店管理系统⽤例图、⽤例规约
⼀.旅店管理系统⽤例图
⼆.⽤例规约
1.预定房间
1 .1简要说明
本⽤例允许客户预订旅店的未被预订的房间,系统提供未被预订的房间的信息列表。
1.2 先置条件
客户进⼊旅店管理系统,并选择预订房间功能。
1.3 事件流
(1)基本事件流
A 客户选择要预订的房间的类型,双⼈间或单⼈间。
B 根据客户选择的房间类型,从所有该类型房间中,筛选未被预定的房间,将这些房间的信息列表显⽰,供客户查询。
C 客户选定房间,并输⼊要预订的天数。
(2)备选事件流
A 客户所需要类型的房间已全部被预订,则提⽰客户,该类型房间已全部被预订,询问客户是否选择另⼀类型的房间。
B ⽤户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发⽣冲突,则系统提⽰,该房间在哪些⽇期⾥已被预订,并询问当前客户是更换房间还是修改预订天数。
1.4 后置条件
A 客户选择房间和预订天数并确认后,系统要求客户输⼊客户信息,包括客户的姓名、地址、联系电话、有效证件号。
另外,系统将计算出客户需要缴纳
的定⾦和总费⽤,并显⽰出来。
B 客户重新选择房间类型,或修改天数,则刷新⽤户界⾯。
1.注册功能用例的用例实现一、简要说明游客可注册为网上订餐系统的用户。
注册时只要填写登录用户名、密码、联系电子信箱、联系电话以及安全问题和答案六项信息即可。
注册后,用户可以继续填写个人详细信息及收获人信息,同时可以修改密码、查询及维护订单。
二、事件流基本流:1. 游客选择注册。
2. 系统返回一个注册页面。
3. 游客根据提示输入相应的注册信息。
4. 系统验证游客输入成功。
5. 游客提交注册信息。
6. 系统提示注册成功并返回首页。
(默认已登录)备选流:1. 游客输入信息和系统验证不一致(如字段长度超过系统设置等),系统给出相应的提示信息并返回注册页面。
2. 游客输入用户名是已注册用户名,系统给出提示并返回注册页面。
3. 系统异常,无法注册,并给出相应的信息(如网站维护等)。
三、前置条件游客申请注册。
四、后置条件游客注册成功成为会员五、扩展点无。
2.登录\注销用例的用例实现一、简要说明用户:已经注册成功的用户可以通过登录页面登录进入该网站。
登录之后可以实现订餐系统的设定功能。
管理员:管理员必须通过后台进行登录,登陆以后,可以在前台或者后台之间切换,更方便地对系统进行管理及维护。
不提供管理员注册功能,管理员只能在数据库中添加,以保证系统的安全性。
登录后,可在前台或者后台选择注销,以便安全退出系统。
二、事件流基本流:1. 该会员选择登录。
2. 系统返回一个登录页面。
3. 会员输入用户名、密码和验证码并提交。
4. 系统进行系统验证,验证成功,记录该用户为登录用户并返回主页面。
(表明该会员已登录。
)5. 会员选择“注销”。
6. 系统提示用户成功注销并返回网站首页。
7.管理员修改管理员个人资料和账号信息。
备选流:1.用户忘记密码,选择“找回密码”功能,进入找回密码用例。
2. 系统验证用户登录信息有错,提示用户重新登录。
3. 系统处理异常,系统给出相应的提示信息.。
4.管理员只能在后台运行。
三、特殊要求无。
四、前置条件该会员必须是本网站已注册的成员。
用例规约例子
以下是 6 条用例规约例子:
1. 咱就说,你去超市买东西,这不就是一个很常见的用例规约嘛!你知道自己要买啥,什么品牌、多少数量,这不就跟软件里的各种条件、步骤一样一样的嘛?比如说,你决定要买巧克力,然后选了某个牌子,接着看价格和重量,哎呀,这就跟程序里的各种设定和判断太像啦!
2. 你想想看,你每天早上起床后要做的一系列事情,也是个用例规约呀!刷牙、洗脸、换衣服,每一步都有先后顺序和特定的操作呢!就像软件运行时,一个步骤紧接着一个步骤,可不能乱了呀!比如你总不能先换衣服再刷牙吧,这多别扭呀!
3. 嘿,你知道煮饺子也是个好例子呢!先准备水,水开了下饺子,然后等饺子煮熟,捞出来,每一步都不能马虎呀!这在软件里不就相当于一个个明确的流程和规定嘛,水就像是输入,饺子煮熟就是输出,这过程多清晰啊!难道不是吗?
4. 你和朋友约着出去玩,这整个过程也是个用例规约呀!先商量去哪里,再确定时间,然后怎么碰面,一点都不能乱来呢!这不就跟程序里的流程规划一样嘛,一环扣一环的。
你再想想,如果商量不好,那可就玩不成啦,就像程序出错就运行不下去一样呀!真的好形象呀!
5. 哎呀,就连你写作业都是个典型的例子呀!先拿出本子和笔,再看题目,思考怎么做,然后开始写,最后检查。
这和软件中的用例规约简直如出一辙嘛!你可别小瞧这写作业的过程呢,像不像程序在一步步执行任务?
6. 你看那些运动员比赛,也是有他们的用例规约呀!比如跑步比赛,先站在起跑线,听口令,起跑,冲刺,每一步都很关键呀!这多像软件运行时的各种规定呀,每一个动作都得精确无误呀!不然怎么能赢得比赛呢,你说对吧?
我的观点结论就是:生活中到处都是用例规约的例子呀,真的太有意思啦!。
课程注册系统用例规约版本<1.0>查看成绩报告卡用例1.简要说明本用例允许学生查看他(她)刚结束学期的成绩报告卡。
本用例的Actor 是学生。
2.事件流当学生从主表格中选择“查看成绩报告卡”活动时,用例开始。
1.基本流—查看成绩报告卡1.系统检索出学生上个学期所修完的每门课程的成绩信息。
2.系统准备、排版并显示成绩信息。
3.当学生完成查看成绩信息后,选择“关闭”。
2.备选流1.没有可以查看的成绩信息如果在基本流中,系统不能找到这个学生上个学期的任何成绩信息,将会显示一个消息。
学生确认这条消息后,用例终止。
3.特殊需求没有和本用例有关的特殊需求。
4.前置条件1. 登录在本用例开始之前,学生要登录到系统。
5.后置条件没有和本用例有关的后置条件。
6.扩展点没有和本用例有关的扩展点。
课程注册用例1. 简要说明此用例允许学生登记当前学期的课程。
如果在学期开始的选/退课期间情况发生一些变化,那么学生也可以修改或删除自己所选的课程。
课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。
课程目录系统是用例中包含的一个主角。
2. 事件流当学生从主窗体中选择“维护课程表”活动时,此用例就开始使用了。
1. 基本流—创建课程表1.学生选择“创建课程表”。
2.系统会显示一张空白课程表。
3.系统从课程目录系统中检索可选课程的列表。
4.学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。
在完成选择后,学生选择“提交”。
5.在此步骤中为每一门所选课程执行“添加课程”子流程。
6.系统保存该课程表。
2. 备选流1. 修改课程表1.学生选择“修改课程表”。
2.系统检索并显示学生现在的课程表(例如,本学期的课程表)。
3.系统从课程目录系统中检索本学期所有可选课程的列表。
系统向学生显示该列表。
4.这样,学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
学籍管理系统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名用户对其的同一时刻的访问。