还剩64页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
软件需求分析报告高校医务信息管理系统学生姓名__学号专业班级院(系)计算机与通信工程学院指导教师完成时间成绩前言组员分工随着社会信息化进程的不断深入,计算机应用的普及和智能化,我们进入了信息发展的快速时代,各种传统方面的管理系统都受到了不同程度的冲击,高效方便的管理越来越受到大众的欢迎,各种各样的管理软件应运而生传统的医务管理系统也受到信息化的影响而向着高效的管理迈进,高校作为为祖国未来培养栋梁的地方,信息化的发展更显得明显为了改进传统医务管理的不方便之处,我们需要开发出具有很高应用型的软件,代替那些传统管理方面的零碎之处高校医务管理信息系统的建立涉及到医院的方方面面,从计算机的硬件到软件,从管理的模式到人员的素质,从医院领导的关心和重视到各部门相互配合,都对医院管理系统的建立产生了很大的影响随着科学技术水平的不断发展和现代化管理水平的不断提高,高校对校医院的医药管理也提出了更高的要求目前高校医院的药库、药品管理、病案管理、计费管理等在那些繁琐、复杂、低效的日常工作中浪费了大量的时间,并且还时不时的带来这样那样的事故例如药库管理经常由于管理上的不当使部分药品失效报废,给医院带来经济损失,因此,医务管理的科技信息化是时代的必须,刻不容缓为能够更好地了解药库及药房的药品情况、建立病人电子档案、规范门诊划价和费用收取核算等日常工作,对医务进行信息管理是非常必要的目 录TOC\o1-4\h\z\u一项目前景文档11业务需求
11.1业务背景
11.2业务机会
11.3业务目标和成功条件
11.4客户和市场需要
21.5业务风险22解决方案的前景
22.1前景陈述
22.2主要系统特性
32.3假设和依赖条件33项目范围和限制
33.1发布的范围
33.2限制和排除条件44业务环境
44.1涉众档案
44.2项目的优先级
44.3运行环境5二软件需求规格说明书61引言
61.1概述
61.2背景
61.3定义
71.4参考资料72任务概述
72.1目标
72.2运行环境(OperatingEnvironment,OE)
72.3假定(Assumption)和约束(Constraint)83需求规定
83.1对功能的规定
83.
1.1用户需求(描述业务用例模型)
83.
1.
1.1组织机构和角色
83.
1.
1.2业务概览
123.
1.
1.3业务场景
183.
1.2系统需求(描述系统用例模型)
253.
1.
2.1概览
253.
1.
2.2系统需求规定
253.
1.
2.3数据分析
523.2非功能性需求
603.
2.1性能需求(Performance)
603.
2.2安全性需求(Security)
603.
2.3软件质量属性
613.3外部接口需求
613.
3.1用户界面(UserInterfaces,UI)
613.
1.2硬件接口(HardwareInterfaces,HI)
623.
1.3通信接口(CommunicationsInterfaces,CI)62一项目前景文档1业务需求
1.1业务背景校医院为了适应工作发展的需要,委托项目组为其开发一套新的《高校医院医务信息管理系统》过去,高校医院在药库管理、药品管理、病案管理、计费管理等方面存在效率不高、业务流程随意、部分管理存在缺漏等问题例如药库管理经常由于管理上的不当使部分药品失效报废,给医院带来经济损失等因此,设计一套符合用户需求的医务管理信息系统,将医务管理有关的信息纳入计算机系统统一管理,以便及时获取有关信息,已成为提高医疗效果和管理效率上急需解决的问题本系统就是针对这方面的迫切需求而设计的
1.2业务机会高校医院中的药库、药房管理、门诊划价历来是医院管理中的一些繁琐、复杂、费时、费力的日常工作药库管理经常由于管理上的不当使部分药品失效报废,给医院带来一定的经济损失,因此,传统的手工统计操作已远远不能满足医务工作的实际需要本系统能够提高工作效率,同时也能够随时了解药库及药房的药品情况,方便实施信息的管理,现在市场上存在的该类系统不是很多,而且没有一个能像本系统一样能够满足用户的需求,市场前景很好本系统安装简便,移植性好适用于多种操作系统对硬件的要求不高,普通的个人电脑即可安装使用与市场上已经存在的类似产品相比,本系统更加安全,可靠,即时同时操作简便易学系统运行速度较高,全面的业务逻辑处理能力,会给用户带来更多的便捷安全快速全面的逻辑处理能力是本系统所独居的最大亮点同时独立的错误处理能力也是其它系统所无法比拟的
1.3业务目标和成功条件高校医院主要是为全校教职工、学生、家属提供包括门诊、住院等医疗服务项目本系统要求能够对高校医院进行药库管理、药品管理、病案管理、计费管理等本系统要求安全,可靠(具有出错处理能力),准确
1.4客户和市场需要随着科学技术水平的不断发展和现代化管理水平的不断提高,高校对校医院的医药管理也提出了更高的要求高校医务管理信息系统的建立涉及到医院的方方面面,从计算机的硬件到软件,从管理的模式到人员的素质,从医院领导的关心和重视到各部门相互配合,都对医院管理系统的建立产生了很大的影响同时,通过医务管理信息系统的建立,将医务管理计算机化、规范化,提高了工作效率、规范了业务管理流程、节省了大量的人力、物力、财力和时间,摆脱了过去手工方式时的数据统计、资料查询费时费力的落后局面,将在经济效益和社会效益方面创造良好的研究和利用价值本系统为医务人员规范了日常工作,简化了业务管理流程,提高了效率,增加了效益同时为患者建立个人信息档案,方便管理查询本系统能够迅速占领市场,满足市场的需求
1.5业务风险本系统推出时间较晚,价格昂贵,短期内很难占领市场的主要份额(可能性
0.5影响7)医院服务系统更新较慢,新系统很难进入应用领域(可能性
0.3影响4)本系统没有提供网上业务,影响系统的推广使用(可能性
0.5影响3)2解决方案的前景
2.1前景陈述产品名称高校医务信息管理系统产品类别软件产品目标客户各大高校校医务室需求或机会的声明本系统逻辑架构合理全面,满足了所有的用户需求新产品的主要竞争优势安全快速全面的逻辑处理能力是本系统所独居的最大亮点同时独立的错误处理能力也是其它系统所无法比拟的
2.2主要系统特性FE-1日常的学生看病、挂号,住院、计费和医生计价、门诊FE-2药品入库管理,对药品进行分类FE-3病房分配,入院病人的用药,收费FE-4注册门诊付费方式FE-5在院医生、医务人员档案建立和管理FE-6创建、浏览、修改和删除病人病历FE-7日常义务统计、整理、分析FE_8通过高校内部网络可以访问系统,或者授权的医院工作人员可以通过外部Internet访问系统
2.3假设和依赖条件如果本系统需要互联网的应用,开发人员可以完成网络应用的添加;为了能够保证系统的正常运行,学校医院已经建立好通畅的局域网环境学校财务系统预留接口,可接受高校医院管理信息系统的数据作为财务系统数据输入的组成部分3项目范围和限制
3.1发布的范围特性当前版本FE-1完全实现(管理日常事务)完全实现(依靠管理系统)FE-2完全实现完全实现FE-3完全实现完全实现FE-4完全实现完全实现FE-5完全实现完全实现FE-6完全实现完全实现FE-7完全实现(系统自动处理分析)完全实现FE-8不支持完全实现
3.2限制和排除条件本系统仅供医院内部使用(本系统需要的外部硬件配置昂贵),所以无法为外部人员提供服务本系统目前版本不支持网络服务,所以外界无法通过网络访问4业务环境
4.1涉众档案用户其他涉众患者系统开发及其维护医务管理人员
4.2项目的优先级因素约束自由度特性第一版本实现前九个特性至少实现前七个特性进度合约期内完成最晚延迟至12月14日质量必须满足95%的用户需求人员某某软件小组根据实际需要可添加成本少于计划投入资金最多超值原计划10%
4.3运行环境医院的操作将通过如下的Web浏览器来完成IE
8.0或IE
6.0,360版本6和版本7医院监护系统将运行在一个服务器中,该服务器运行当前医院批准的RedHatLinux版本和AachenHTTPServer医院监护系统采用ORACLE数据库处理录入的数据二软件需求规格说明书1引言
1.1概述本文档详细介绍了高校医院管理信息系统的需求说明,为用户和领导描述出一个具体的产品模型,为软件设计、开发及测试人员提供下步工作的依据本文档面向的读者主要是项目委托单位的管理人员希望能使本软件开发工作更具体本文档的目的在于给出“高校医务信息管理系统”以下简称本系统的功能说明1)向用户描述“高校医务信息管理系统”的功能;2)为编制后续各阶段的文档提供基本依据;3)提供给用户确认或本地化修改的基本文件;4)作为日后软件确认测试和系统验收之参考依据;5)作为日后系统维护工作基准文件本文档的内容涵盖了本系统的总体结构设计、软件运行环境设计、处理流程设计和软件功能设计等本文档的使用者包括本系统用户、需求分析人员、项目管理人员、软件设计人员、软件质量控制人员以及软件维护人员
1.2背景校医院为了适应工作发展的需要,委托项目组为其开发一套新的《高校医务信息管理系统》高校医院主要为全校教职工、学生、家属提供医疗服务,包括门诊、住院、等服务项目《高校医务信息管理系统》应将这些项目有关的信息纳入电脑系统统一管理,以便及时获取有关信息,提高医疗效果和管理效率《高校医务信息管理系统》项目组成员与校医院有关人员经过一个月的工作,就校医院现有正单独使用的门诊、住院、药品管理等电脑应用系统进行了详细的分析,并考虑到校医院各部门联网后的应用需求确定分以下子系统进行新系统的开发住院部管理子系统;门诊部管理子系统;中西药房管理子系统;病案管理子系统;业务管理子系统;人事管理子系统;系统管理子系统
1.3定义术语所指对象或含义门诊科目校医院所设的门诊类别,由校医院设置并进行编码处方由校医院根据病情提供的治疗方法病种代码表示疾病的种类,由校医院统一规范人员类别教职工、学生、家属人员等年度指自然年度费用明细各项药品和诊疗项目费用
1.4参考资料黄国兴周勇《软件需求工程》清华大学出版社2008张海潘《软件工程》 北京清华大学出版版社2003WendyBoggs《UML与RationalRose2002从入门到精通》邱仲潘等译北京-电子工业出版社2002刁成嘉,UML系统建模与分析设计,北京机械工业出版社,20072任务概述
2.1目标1决策支持:根据实际要求及时提供所需报表及文件2提高效率:利用软件进行管理避免人工管理的失误以及延迟性从而实现高效率的管理.
2.2运行环境(OperatingEnvironment,OE)1硬件方面Pentium级处理芯片;1兆显存的兼容显卡;256色1024*960的兼容显示器;标准兼容打印机
(2)软件方面:操作系统WINXP;支持环境VISUALBASIC
6.0;数据库MicrosoftSQLServer2008
(3)网络类型局域网(以太网)
(4)存贮器容量数据库服务器100G以上;客户端20G以上
2.3假定(Assumption)和约束(Constraint)为了能够保证系统的正常运行,学校医院已经建立好通畅的局域网环境学校财务系统预留接口,可接受高校医院管理信息系统的数据作为财务系统数据输入的组成部分3需求规定
3.1对功能的规定
3.
1.1用户需求
3.
1.
1.1组织机构和角色角色视图角色说明角色名称说明ba_患者学生、教职工、家属等具有缴纳资金、挂号预约等功能ba_门诊管理人员医院工作人员,医生,具有诊病、开方子、收费等工作ba_药房管理人员药房工作者,具有拿药,药品入库,药品划价等功能ba_住院管理人员住院部管理人员,具有入院管理、出院管理、病房管理、住院计费等管理功能
(1)患者参与业务说明患者可以再申请账号,查看病案,挂号预约看病,如果药品有问题可以进行退还交纳资金的多少可根据自己的意愿去决定,但若在看病住院资金不够时可当场由医务人员帮助交纳足够的资金
(2)门诊管理员参与业务说明门诊管理员通过挂号预约为患者诊治,为患者建立档案,生成处方,确定患者是否需要住院,收取费用若患者未注册自己的帐号,可由门诊管理员直接现场帮助患者注册
(3)住院管理人员参与业务说明住院管理人员为病人分配房间、登记,病人住院后的安排值班人员,并调整住院费用标准,及处理出院手续、收费、查看病人记录以及查看值班记录等
(4)药房管理人员参与业务说明药房管理人员为药品划价,进行药品入库,药品药价变更调整,查询库存药品信息,为病人发药,接受退回药品
3.
1.
1.2业务概览
(1)普通就诊业务视图普通就诊业务说明患者在自己的帐号交纳资金后挂号预约自己想要的门诊医生,通过门诊医生的诊断,开出处方,并扣除相应的费用普通就诊中的患者是不需要住院的,如需住院将会进行下一个业务——住院业务
(2)入院业务视图
(3)出院业务视图说明门诊人员诊治确定患者需要住院,确定住院信息;住院管理人员进行交接,安排患者住院及住院的管理、计费说明住院管理人员确定患者信息,办理出院手续,患者出院
(4)药品入库业务视图说明药品人员根据药房情况去厂家进药,药品入库登记,把药品放入药房;接受患者退换的药品,根据药品情况,可进行退还厂家处理
(5)药品出库业务视图说明门诊管理人员为病人诊治,生成药方,患者拿着药房去药方拿药;药房管理人员根据药方所列清单进行发药,同时药房管理人员还管理整个药品出库的信息
(6)申请帐号业务视图说明患者提出申请账号请求,填写申请资料,门诊管理人员查看患者信息,给患者颁发账号
(7)注销帐号业务视图说明患者通过查看病案信息,确定注销账号,并向门诊管理人员提出注销;门诊管理人员通过查看患者信息,确定患者注销申请,收回账号
3.
1.
1.3业务场景说明此图描述的是业务流程,应使用预定义的businessactor和businessusecase作为泳道和活动这样有助检查和发现businessactor和businessusecase
(1)第一次就诊业务场景说明此视图描述的是第一次就诊业务流程,患者首先要获得自己的帐号,然后才能进行挂号预约,在门诊部门就诊得到处方,最后在药房拿药
(2)普通就诊业务场景说明此视图描述的是普通就诊业务流程,因只是普通就诊,所以不需住院
(3)入院业务场景说明此视图描述的是入院业务流程,患者挂号预约后在门诊部门的确诊下需要住院,然后去住院部门办理住院手续
(4)出院业务场景说明此视图描述的是出院业务流程,患者在得到出院许可后由住院管理人员办理出院手续,即可出院
(5)取药业务场景说明此视图描述的是取药业务流程,门诊人员给挂号预约的患者开出处方,由患者去药房拿药,药房管理人员处理发放药品的信息
(6)退药业务场景说明此视图描述的是退药业务流程,患者需要退还药品,可先提交退药申请,成功后即可去药房退药,然后由药房来处理退回来的药品信息
(7)申请帐号业务场景说明此视图描述的是申请帐号业务流程,由患者填写信息申请在医院的帐号,经门诊管理人员审核后颁发帐号
(8)注销帐号业务场景说明此视图描述的是注销帐号业务流程,患者想注销自己的帐号,提交申请,门诊部门进行审核,查看患者病案信息,最后同意并收回帐号
(9)药房管理业务场景说明此视图描述的是药房管理业务流程,主要由药房管理人员操作,从药品发出到患者退药再到收回药品,同时也有药品的购买和销售
3.
1.2系统需求
3.
1.
2.1概览说明该系统实现挂号预约、生成处方、入院管理、出院管理、发药处理、退药处理、申请帐号、注销帐号、颁发帐号、收回帐号用例而就诊、药房管理、审核患者信息及病案信息分析等不能实现
3.
1.
2.2系统需求规定1挂号预约业务说明用例名称bu_挂号预约实现名称bur_Registrationappointment用例描述患者通过此用例向系统查询并提交挂号预约请求参与者患者前置条件患者的帐号合法有效患者帐号的资金足够后置条件创建预约凭证更新患者费用记录主事件流1用户用个人帐号登录系统,计算机显示我的医院信息档案
2.用户选择查询预约挂号,计算机显示查询界面
3.用户按门诊、日期查询,计算机显示查询结果
4.用户可一个门诊或多个,并确认计算机显示确认挂号预约清单
5.用户选择确认预约,计算机显示预约凭证及费用6用户选择提交预约凭证,计算机显示提交结果和凭证编号
7.计算机执行后置条件用例结束备选事件流
4.a用户选择继续预约
1.计算机执行2;
4.b用户选择放弃
1.计算机执行
44.c用户找不到结果
1.计算机执行
35.a用户余额不足
1.计算机显示余额和所需金额
2.用户选择续费,直接链接网上银行支付
3.用户选择放弃,计算机执行
16.a用户选择保存凭证单
1.计算机保存并执行1;
6.b用户选择放弃
1.计算机执行1;业务规则至少预约一个涉及的业务实体Be_费用记录,Be_预约凭证,Be_患者帐号非功能性需求支持多种语言显示2生成处方业务说明用例名称bu_生成处方实现名称bur_Generateprescriptions用例描述门诊管理人员通过此用例向系统查询、填写患者信息并提交诊断处方参与者门诊管理人员前置条件
1.患者的帐号合法有效
2.患者的预约凭证有效
2.患者帐号的资金足够后置条件
1.创建处方单
2.注销预约凭证
3.更新患者费用记录主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户选择查询患者信息,计算机显示查询界面
3.用户按患者帐号或姓名查询,计算机显示查询结果
4.用户查询患者预约凭证,计算机显示查询结果
5.用户选择注销预约凭证,计算机显示注销成功
6.用户填写患者诊断信息并保存
7.用户填写诊断的处方并提交,计算机显示相应费用
8.用户确定提交,计算机显示提交结果和处方单
9.计算机执行后置条件用例结束备选事件流
3.a用户查不到患者帐号
1.用户选择颁发帐号,启动bu_颁发帐号用例
2.用户选择结束,计算机执行
24.a用户查不到患者的预约凭证
1.计算机执行
37.a患者余额不足
1.计算机显示余额和所需金额
2.用户选择续费,患者直接交纳
3.用户选择放弃,计算机执行
38.a用户选择保存处方单
1.计算机保存并执行
28.b用户选择放弃,
1.计算机执行2业务规则至少有一个预约凭证,至少有一张处方单涉及的业务实体Be_费用记录,Be_处方单,Be_患者帐号Be_预约凭证非功能性需求支持多种语言显示3入院管理业务说明用例名称bu_入院管理实现名称bur_Hospitalmanagement用例描述住院管理人员通过此用例向系统查询并处理患者住院手续参与者住院管理人员前置条件
1.患者的帐号合法有效2.患者被批准住院
3.患者帐号的资金足够后置条件
1.创建住院批准单、病房号
2.更新患者费用记录主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户选择查询患者信息,计算机显示查询界面
3.用户按患者帐号或姓名查询,计算机显示查询结果
4.用户查询住院信息,计算机显示结果
5.用户进行入院登记,计算机显示结果并显示空房信息
6.用户选择分配病房,计算机显示病房号和应付费用
7.用户提交病房单,计算机显示病房单号和住院批准单号
8.计算机执行后置条件用例结束备选事件流
4.a用户查不到患者住院信息
1.计算机执行
35.a用户查不到空房信息
1.计算机执行
36.a患者余额不足
1.计算机显示余额和所需金额
2.用户选择续费,患者直接交纳
3.用户选择放弃,计算机执行
27.a用户选择保存病房单
1.计算机保存并执行
27.b用户选择放弃,
1.计算机执行2业务规则一次只有一张住院批准单,只有一张病房单涉及的业务实体Be_费用记录,Be_患者帐号,Be_住院批准单Be_病房单非功能性需求支持多种语言显示4出院管理业务说明用例名称bu_出院管理实现名称bur_hospitalmanagement用例描述住院管理人员通过此用例向系统查询并处理患者出院手续参与者住院管理人员前置条件
1.患者的帐号合法有效
2.患者被批准出院后置条件
1.创建出院批准单主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户选择查询患者信息,计算机显示查询界面
3.用户按患者帐号或姓名查询,计算机显示查询结果
4.用户查询住院信息,计算机显示结果
5.用户进行出院登记,计算显示结果6用户选择提交出院批准单,计算机显示提交结果和批准单号
7.计算机执行后置条件用例结束备选事件流
4.a用户查不到患者出院信息
1.计算机执行
36.a用户选择保存出院批准单
1.计算机保存并执行
26.b用户选择放弃,
1.计算机执行2业务规则一个患者帐号一次只有一张出院批准单涉及的业务实体Be_患者帐号,Be_出院批准单非功能性需求支持多种语言显示5发药处理业务说明用例名称bu_发药处理实现名称bur_Dispensingprocess用例描述药房管理人员通过此用例向系统查询并提交发药处理参与者药房管理人员前置条件
1.患者的帐号合法有效
2.患者有处方单且处方单有效后置条件
1.创建药品开出单主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户选择查询患者信息,计算机显示查询界面
3.用户按患者帐号或姓名查询,计算机显示查询结果
4.用户查询取药信息,计算机显示结果
5.用户选择取出药品,计算显示结果6用户选择提交药品开出单,计算机显示提交结果和药品开出单号
7.计算机执行后置条件用例结束备选事件流
4.a用户查不到患者的处方单
1.计算机执行
34.b患者的处方单无效过期
2.计算机执行
36.a用户选择保存药品开出单
1.计算机保存并执行
26.b用户选择放弃,
1.计算机执行2业务规则一个患者帐号至少有一张处方单,但一次只有一张药品开出单涉及的业务实体Be_患者帐号,Be_处方单,Be_药品开出单非功能性需求支持多种语言显示6退药处理业务说明用例名称bu_退药处理实现名称bur_Drugwithdrawaltreatment用例描述药房管理人员通过此用例向系统查询并提交退药处理参与者药品管理人员前置条件
1.患者的帐号合法有效
2.患者已申请退还药品后置条件创建退还药品单更新患者费用记录主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户选择查询患者信息,计算机显示查询界面
3.用户按患者帐号或姓名查询,计算机显示查询结果
4.用户查询退药信息,计算机显示结果
5.用户选择收回药品,计算显示结果6用户选择提交退还药品单,计算机显示提交结果和退还药品单号
7.计算机执行后置条件用例结束备选事件流
4.a用户查不到患者的退还药品凭证
1.计算机执行
34.b患者的退还药品凭证无效过期
2.计算机执行
36.a用户选择保存退还药品单
1.计算机保存并执行
26.b用户选择放弃,
1.计算机执行2业务规则一个患者帐号至少有一个退还药品凭证,一次只有一张退还药品单涉及的业务实体Be_患者帐号,Be_退还药品凭证,Be_退还药品单非功能性需求支持多种语言显示7申请帐号业务说明用例名称bu_申请帐号实现名称bur_Applyforanaccount用例描述患者通过此用例向系统提交帐号申请参与者患者前置条件
1.患者填写的信息正确合法后置条件
1.创建帐号信息记录主事件流1用户登录系统申请帐号界面
2.用户填写相应信息,计算机提示
3.用户提交申请,计算机显示结果
4.计算机执行后置条件用例结束备选事件流
3.a用户申请不成功
1.计算机执行
23.a用户选择退出
1.计算机执行1业务规则一个患者只有一个帐号,至少有一个帐号信息记录涉及的业务实体Be_患者帐号,Be_帐号信息记录非功能性需求支持多种语言显示8注销帐号业务说明用例名称bu_注销帐号实现名称bur_Cancellationaccount用例描述患者通过此用例向系统查询并提交注销帐号参与者患者前置条件
1.患者帐号合法有效后置条件更新帐号信息记录注销病案信息主事件流1用户用个人帐号登录系统,计算机显示我的医院信息界面
2.用户选择查询病案信息,计算机显示查询界面
3.用户选择注销帐号,计算机显示结果
4.用户提交申请,计算机显示结果
5.计算机执行后置条件用例结束备选事件流
3.a用户注销失败
1.计算机执行
33.b用户选择放弃
1.计算机执行
34.a用户选择退出
1.计算机执行1业务规则一个患者帐号至少有一条病案信息,至少有一个帐号信息记录涉及的业务实体Be_患者帐号,Be_病案信息,Be_帐号信息记录非功能性需求支持多种语言显示9颁发帐号业务说明用例名称bu_颁发帐号实现名称bur_Accountissued用例描述门诊管理人员通过此用例向系统查询并提交颁发帐号参与者门诊管理人员前置条件
1.患者填写的信息合法正确后置条件
1.更新帐号信息记录主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户查询帐号管理,计算机显示帐号管理界面
3.用户选择查看帐号申请,计算机显示结果
4.用户选择颁发帐号,计算机显示结果
5.用户选择提交确定,计算机显示结果
6.计算机执行后置条件用例结束备选事件流
4.a用户选择放弃
1.计算机执行
35.a用户选择退出
1.计算机保存并执行
25.b用户选择放弃
1.计算机执行2业务规则一个患者帐号至少有一个帐号信息记录涉及的业务实体Be_患者帐号,Be_帐号信息记录非功能性需求支持多种语言显示10收回帐号业务说明用例名称bu_收回帐号实现名称bur_Recoveraccount用例描述门诊管理人员通过此用例向系统查询并提交收回帐号参与者门诊管理人员前置条件
1.患者的帐号合法有效
2.患者提交过注销帐号后置条件
1.更新帐号信息记录
2.注销病案信息主事件流1用户用个人帐号登录系统,计算机显示医务人员管理界面
2.用户查询帐号管理,计算机显示帐号管理界面
3.用户选择查看帐号申请,计算机显示结果
4.用户选择收回帐号,计算机显示结果
5.用户选择提交确定,计算机显示结果
6.用户选择退还资金,计算显示结果7用户选择提交确定,计算机显示结果和注销病案信息
8.计算机执行后置条件用例结束备选事件流
6.a用户退还不成功
1.计算机执行
48.a用户选择退出
1.计算机保存并执行2业务规则一个患者帐号至少有一条病案信息,至少有一个帐号信息记录涉及的业务实体Be_患者帐号,Be_病案信息,Be_帐号信息记录非功能性需求支持多种语言显示业务场景分析
(1)挂号预约用例场景说明患者登录自己的帐号后选择挂号预约,系统处理信息,提示患者是成功,如不成功则预约失败若成功,患者可选择是否继续,可以选择放弃预约,也可继续,然后确定
(2)生成处方用例场景说明门诊人员在查询患者帐号信息后确定患者有过预约,注销预约凭证后为患者诊断并填写病案信息,开出处方,扣除相应费用
(3)入院管路用例场景说明住院管理人员查询患者帐号信息,在确定患者需要住院后为患者进行登记住院并分配病房,扣除费用成功后即结束
(4)出院管理用例场景说明住院管理人员查询患者帐号信息,在确定患者可以出院后,为患者办理出院手续
(5)发药处理用例场景说明药房管理人员查询患者帐号信息,在确定患者的处方单有效后,为患者发放相应药品,并处理药房的药品信息
(6)退药处理用例场景说明药房管理人员查询患者帐号信息,在确定患者申请退药有效后,收回患者退还的药品并退还给患者费用,然后处理药房的药品信息
(7)申请帐号用例场景说明患者登录申请帐号界面,填写正确信息,提交申请,等待相应人员处理
(8)注销帐号用例场景说明患者登录个人帐号后,可以申请注销自己的帐号,提交成功后等待相应人员处理
(9)颁发帐号用例场景说明门诊管理人员在查看患者申请注册的信息后,选择颁发帐号
(10)收回帐号用例场景说明门诊管理人员查询患者帐号信息,在确定患者提交注销帐号后,提交注销,并退还患者帐号剩余资金业务实体分析
(1)挂号预约业务实体视图说明患者通过自己的帐号获得预约凭证,并更新费用记录
(2)生成处方业务实体视图说明门诊管理人员通过患者帐号内的预约凭证,为患者诊治并开出处方单,更新费用记录
(3)入院管理业务实体视图说明住院管理人员通过患者帐号的信息,开出住院批准单和病房号,更新费用记录
(4)出院管理业务实体视图说明住院管理人员通过患者帐号信息为患者开出出院批准单
(5)发药处理业务实体视图说明药房管理人员通过患者帐号中的处方单,为患者取出药品并开出药品开出单
(6)退药处理业务实体视图说明药房管理人员通过患者帐号的退还药品凭证,为患者进行退药处理,并开出退还药品单
(7)申请帐号业务实体图说明患者通过登录系统申请自己的帐号,系统更新帐号信息记录
(8)注销帐号业务实体图说明患者通过自己的帐号,可以查看病案信息,并注销帐号,系统更新帐号信息记录
(9)颁发帐号业务实体图说明门诊管理人员通过患者的申请,为患者颁发帐号,系统更新帐号信息记录
(10)收回帐号业务实体图说明门诊管理人员通过患者帐号的注销申请,查看病案信息,退还余额,更新费用记录,并收回帐号,系统清除帐号信息记录
3.
1.
2.3数据分析1概览说明一个患者帐号获得预约凭证,门诊人员给患者帐号开出处方单,并给出费用记录患者凭借处方单,药房管理人员为患者帐号开出药品开出单患者通过自己的帐号获得退还药品凭证,药房管理人员为患者帐号开出退还药品单患者需要住院,住院管理人员为患者开出住院批准单和病房号,并更新患者帐号的费用记录患者需要出院,住院管理人员为患者帐号开出住院批准单在患者就诊、住院过程中,相关人员为患者帐号更新患者的病案信息在患者申请、注销帐号过程中,系统为患者帐号更新帐号信息记录患者帐号实体名称Be_患者帐号实体描述每个患者帐号都经由申请、颁发、登录、注销、收回几个状态,详细请参看图书状态图属性名称类型精度说明属性的业务含义及业务规则帐号字符18帐号为自己的身份证号帐号分类字符3帐号的分类密码字符6-12帐号的密码由数字和字母组成状态字符2帐号登录的状态帐号信息记录实体名称Be_帐号信息记录实体描述帐号信息记录在帐号的申请、颁发、登录、注销中更新,在收回帐号后清除属性名称类型精度说明属性的业务含义及业务规则帐号字符18帐号为患者自己的身份证号帐号分类字符3帐号的分类日期日期帐号申请、颁发、登录、注销的时间状态字符2帐号登录的状态处方单实体名称Be_处方单实体描述每个处方单需要注明患者帐号、姓名,以及主治医生的工号、姓名属性名称类型精度说明属性的业务含义及业务规则处方单号字符处方单流水号分类字符3处方单的分类患者帐号字符18患者的作者患者姓名字符20患者的姓名药品名称字符100所需药品的名称医嘱字符1000注明主治医生对患者的医嘱主治医生字符20主治医生的姓名工号字符10主治医生的工号日期日期处方单开出的日期预约凭证实体名称Be_预约凭证实体描述患者需要看病挂号,先申请预约,有了预约凭证方可在指定时间地点看病属性名称类型精度说明属性的业务含义及业务规则编号字符预约凭证流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名主治医生字符20主治医生的姓名工号字符10主治医生的工号地点字符100预约的地点日期日期预约的日期费用记录实体名称Be_费用记录实体描述每本图书都经有上架,预定,借出,返回待查和下架几个状态,详细请参看图书状态图属性名称类型精度说明属性的业务含义及业务规则帐号字符18患者帐号姓名字符20患者姓名分类字符3支付的类型金额字符10此次所需交纳的费用收费人字符20收取费用的人员工号字符10收费人的工号欠费状态字符3当时欠费的状态药品开出单实体名称Be_药品开出单实体描述药品开出单依赖于患者的处方单,并证明药品已发出属性名称类型精度说明属性的业务含义及业务规则编号字符药品开出单的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者姓名状态字符3药品发放状态,是否已发放发放人字符20药品发放人员工号字符10药品发放人员的工号日期日期药品发放的日期退还药品凭证实体名称Be_退还药品凭证实体描述退还药品凭证依赖于药品开出单,证明患者提出退药并被同意属性名称类型精度说明属性的业务含义及业务规则编号字符退还药品凭证的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名药品名称字符100需要退还药品的名称退还理由字符1000退还某类药品的理由状态字符3此次退还是否有效退还药品单实体名称Be_退还药品单实体描述退还药品单依赖于退还药品凭证,并证明已完成退药处理属性名称类型精度说明属性的业务含义及业务规则编号字符退还药品单的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名药品名称字符100退还药品的名称状态字符3是否已完成退还处理接收人字符20接收退还药品的人员工号字符10接收人的工号日期日期此次退还成功的日期住院批准单实体名称Be_住院批准单实体描述住院批准单依赖于主治医生的诊断,确定患者住院信息属性名称类型精度说明属性的业务含义及业务规则编号字符住院批准单的流水号分类字符3门诊的分类帐号字符18患者帐号姓名字符20书籍的作者住院原因字符1000患者住院的原因住院医嘱字符1000患者住院所需的药品以及注意事项登记人字符20帮助患者办理住院手续的人员工号字符100登记人的工号日期日期此次住院批准的日期病房号实体名称Be_病房号实体描述病房号是患者住院后被分配病房的凭证属性名称类型精度说明属性的业务含义及业务规则编号字符病房号的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名病房号字符3患者住院的房间号分配人字符20为患者分配病房的人员工号字符10分配人的工号日期日期此次分配病房陈功的日期出院批准单实体名称Be_出院批准单实体描述出院批准单依赖于主治医生的批准,确定患者可以出院属性名称类型精度说明属性的业务含义及业务规则编号字符出院批准单的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名出院原因字符1000患者获得出院批准的原因出院医嘱字符1000主治医生对出院后的患者的医嘱办理人字符20为患者办理出院手续的人员工号字符10办理人的工号日期日期此次出院批准的日期病案信息实体名称Be_病案信息实体描述病案信息患者在诊治、住院过程中的病案分析属性名称类型精度说明属性的业务含义及业务规则编号字符病案信息的流水号分类字符3门诊的分类类型字符10病案的类型帐号字符18患者的帐号姓名字符20患者的姓名病案分析字符10000诊断人对患者病案的详细分析和医治方法诊断人字符20为患者诊断的人员工号字符10诊断人的工号日期日期此次诊断的日期
3.2非功能性需求
3.
2.1性能需求(Performance)应用系统过程中的数据库响应时间不超过10秒;系统生成页面速率为1Mps;用户向系统录入信息、提交信息、查询信息等操作在5秒内完成
3.
2.2安全性需求(Security)系统用户必须要登录到“高校医务信息管理系统”才能完成后续的操作,不登陆不能查询到任何信息,不能做任何操作所有涉及到系统功能和个人信息的内容,必须使用加密措施进行加密
3.
2.3软件质量属性可靠性如果“高校医务信息管理系统”在使用过程中出现故障,可以通过手动在五分钟内恢复系统;系统非正常中断,用户可以在通过“高校医务信息管理系统”可以部分恢复中断前的数据和进行的工作可用性“高校医务信息管理系统”不需要特定的浏览器,目前的浏览器都可以使用该系统“高校医务信息管理系统”将对本校局域网用户可用,用户在当地时间早晨5点到晚上12点
99.9%的时间可用,当地时间晚上12点到早晨5点不可用“高校医务信息管理系统”简单易于操作,使用者仅需要简单的培训就可以使用可维护性系统在运行一段时间后,系统管理员可以根据当前需要进行升级可移植性如果学校给校医院投入新的资金进行服务器升级,管理人员通过“高校医务信息管理系统”系统的配置更改可以完成系统的移植约束与已有系统的兼容性新的应用可以在新旧两种版本上运行应用标准按“RUP”开发模型进行开发
3.3外部接口需求
3.
3.1用户界面(UserInterfaces,UI)描述需要的用户界面的逻辑特征1)用户界面简洁,以图表为主,重点体显示的是数据,如药品明细等,色调为灰色2)屏幕分为左右两侧,左侧占屏幕的25%,右侧75%,右侧上半部分为图表信息,下半部分为操作按钮3)按钮为标准的矩形按钮,有确定和取消4)设置快捷键5)错误信息显示以弹出对话框的形式
3.
1.2硬件接口(HardwareInterfaces,HI)硬件接口名称硬件名称厂商接口描述RS232串行通讯口IC卡读写器XXXX符合ISO7816-3同步传输协议
3.
1.3通信接口(CommunicationsInterfaces,CI)通信接口名称协议或方式安全要求传输速率要求Web浏览器HTTP/
1.0中10MPAGE。