第一篇:“医院门诊查询软件”功能需求
2004年本科软件工程课候选实践项目功能需求说明
“医院门诊查询软件” 功能需求说明
医院门诊查询软件是一个信息管理软件,意图在于方便患者、医生查询门诊信息,并提供患者预约服务,可应用于各大、中、小型医院。使用本软件,不仅可以提高医院效率,还可以取代人工劳动,降低劳务开支。
1.医院门诊查询软件功能
1.1 医生可以随时编辑自己的个人资料
1.2 医生可以编辑每周内自己的坐诊时间以及每天的最大预约数量
1.3 患者可以联机注册为软件用户,指定自己的登录名及密码,随后也可以更新个人资料
1.4 提供患者按专家或普通医生、按科室、按医生名称、按坐诊时间、按可用预约数量自定
义类查询,也可以组合以上条件进行查询
1.5 患者可以基于查询结果进行预约,若指定医生当日预约量已满,则预约失败。预约结果
随即返回给患者
1.6 患者对已经进行的预约情况查看或撤销
1.7 只有管理员才可以添加或删除医生账号
1.8 医生可以查看对自己的预约情况,也可以指定起止日期分析患者在坐诊日期内(如周一
到周五)的预约数量分布情况及每天的预约率(预约数/最大预约数)、也可以分析总预约率
1.9 医生和患者均可以将查询结果打印为报表保存
1.10 支持软件用户通过网络远程访问软件
2.规则和约束
2.1操作者的权限层次要有明确的分类,进入软件时要进行身份验证,如:管理员、医生、患者
2.2 具有联机帮助文档指导用户学习使用本软件
2.3 软件运行平台为WINDOWS ME、WINDOWS 2000或WINDOWS XP
2.4 软件具有自动卸载功能,使之能可靠删除现有程序。
2.5 开发基于在下列一种或几种软件技术:VB、Office(包含Access、Excel等)、ASP、MS
SQL Server
Gumreal-team xh.sei.buaa.edu.cn Version 1 1
第二篇:手机远程服务软件功能需求说明书
附件
手机版远程服务软件功能需求说明书
本部分为手机版远程服务软件的功能需求说明,为双方根据甲方提供的项目要求共同商定的功能需求,也作为双方项目验收的依据。供应商应根据此需求提供完整的实现各功能的软件。双方在项目合同执行期间和执行后提出本规范书之外的新需求和改动要求,均需双方商定并另行拟定备忘录。技术要求
1.1 总体要求
手机版远程服务软件一款安装在桌面电脑上的软件,把安卓手机和电脑连接上后用户对手机实现对手机的管理功能,以及工程师通过接管用户电脑借助手机版客户端功能实现对手机的应用支持、咨询和维护等服务。产品的研发分三期完成,本规范描述一起项目中的功能需求。
1.手机版软件将整合至苏宁IT帮客软件中。PC端基于windows平台,支持windows XP, Windows Vista和Windows 7.2.手机版远程服务软件一期项目手机管理功能模块包括:驱动安装,应用管理,联系人管理,文件管理和图片管理。各模块具体支持项目详见详细功能章节,同时软件支持嵌入由甲方提供的应用市场客户端模块,并和应用市场提供的链接接口,下载相关应用安装。
3.一期项目仅针对于Android手机系统,支持android 2.1以上版本的手机,一期支持完全适配机型20款,详见附件一起完全适配机型列表。完全适配的定义为以上提到的手机管理功能模块均支持。
4.界面色调风格和所有弹出框风格与苏宁IT帮客4.0版本保持一致。各个界面、按钮、标签等规格以最终提交商定的UI设计为准。
详细功能
2.1 软件安装,卸载,升级
此模块为手机服务包的嵌入IT帮客的管理,由甲方提供;乙方需提供手机服务包供甲方使用。
(1)安装程序由甲方统一打包在苏宁IT帮客安装程序中,安装程序界面中增加安装手机服务包复选框
(2)未安装手机包的IT帮客中的手机服务页嵌入安装界面,点击安装:本机如有安装包直接安装;如无,调用PC下载软件下载后安装。安装好重启IT帮客客户端。
(3)安装后,开始菜单和控制面板可单独卸载手机服务模块
(4)甲方统一进行平台升级
2.2 驱动安装
(1)手机连接时,自动判断当前连接手机的驱动程序
(2)如本地有驱动程序直接安装;如无,从服务器下载,然后安装;
(3)安装完后直接连接
2.3 主页面
(1)主页面将嵌入IT帮客手机服务页面
(2)支持连接状态的显示,支持连接和断开连接操作
(3)已连接手机的图片,型号,操作系统信息显示(手机图片可从服务器获得)
(4)显示管理功能按键:应用管理,通讯录管理,文件管理和图片管理,点击启动手机服务软件并进入相应的管理页面
(5)支持甲方提供的应用市场页面的嵌入
(6)支持通过应用市场页面的应用下载链接接口下载应用
2.4 应用管理
(1)应用信息列表显示(用户软件,系统软件,可升级软件)
(2)应用安装,卸载,备份,升级(升级需与甲方应用市场接口,包括应用匹配,匹配后的最新版本信息获取和升级包的获取)(3)本地应用搜索
(4)支持甲方提供的应用市场页面的嵌入
(5)支持通过应用市场页面的应用下载链接接口下载应用
2.5 通讯录管理
(1)支持联系人列表显示(全部联系人,收藏夹)
(2)联系人添加,删除,编辑,导入/导出(一种csv格式)
2.6
文件管理
(1)支持当前文件树结构的显示
(2)支持文件结构浏览的后退,前进,向上层,排序
(3)支持文件夹的新建,文件和文件的删除,重命名,复制,粘贴,剪切(右键菜单和快捷键)
(4)支持当前目录下向紧邻下一层文件夹的文件拖拽(5)支持当前文件夹下基于文件名的文件搜索(6)支持存储容量信息的显示
2.7 图片管理
(1)支持文件缩略图的显示(所有图片,照相机图片)(2)支持图片的单选,多选,全选,全不选(3)支持选中图片的删除,导出(4)支持从PC端添加图片
(5)支持点击查看选中的单个图片(利用PC系统图片查看器查看)
第三篇:医院门诊系统需求分析报告
医院门诊系统 需求分析报告 目录
1.引言........................................................................................................................................3 1.1编写目的.........................................................................................................................3 1.2系统概况.........................................................................................................................3 2.需求概述................................................................................................................................3 2.1医院的组织机构情况.....................................................................................................3 2.2各部门关系图.................................................................................................................4 2.3门诊部的业务活动情况.................................................................................................4 3.目标及用户特点....................................................................................................................5 3.1目标.................................................................................................................................5 3.2用户特点.........................................................................................................................5 4.需求规定................................................................................................................................5 4.1病人信息.........................................................................................................................6 4.2医生信息.........................................................................................................................6 4.3各种单据的信息.............................................................................................................6 4.4各种库存信息.................................................................................................................6 5.对功能的规定........................................................................................................................7 6.对性能的规定........................................................................................................................7 6.1安全性要求.....................................................................................................................7 6.2完整性要求.....................................................................................................................8 6.3综合性能要求.................................................................................................................8 7.系统结构................................................................................................................................9 7.1第一层数据流图.............................................................................................................9 7.2第二层数据流图.............................................................................................................9 7.2.1挂号处......................................................................................................................9 7.2.2收费处....................................................................................................................10 7.2.3取药处....................................................................................................................10 7.2.4化验处....................................................................................................................10 1.引言
1.1编写目的
随着知识经济的到来,人类已经逐步进入信息化社会。信息增长的速度越来越快,人们希望利用先进的管理理论方法手段来得到并处理越来越多的信息,以提高工作效率和管理水平。由于信息资源对人们生活的重要性,不断提高信息的收集,传输,加以利用等活动,日益成为人们社会生活的重要组成部分。医院的高效运作也离不开信息系统的开发与利用。因为目前在中国,对于公民来说,看病是一个难题,而医院的系统不够完善是导致病人看病不及时或看病麻烦的一个重要原因。为了加快医院系统的信息化步伐,提高医院的业务水平,建设和完善医院信息系已变得十分必要。一般的公立医院需要有一套完整的挂号、看病、做检查、取药、住院等连贯的信息系统,才能有效的管理病人看病的过程,从而有效的管理医院。
1.2系统概况
本需求分析报告包含医院门诊管理系统的需求分析。
2.需求概述
2.1医院的组织机构情况
一所医院的主要构成部分为:门诊部和住院部,医院的所有日常工作都是围绕这两大部门进行的。门诊部门和住院部门各下设若干科室,如门诊部门下设口腔科、内科、外科、皮肤科等,住院部门下设内科、外科、骨科等,二者下设的部分科室是交叉的,各科室都有相应的医生、护士,完成所承担的医疗工作。
为了支持这两大部门的工作,医院还设置了药库、中心药房、门诊药房、制剂室、设备科、财务科、后勤仓库、门诊收费处、门诊挂号处、问讯处、住院处、检验科室、检查科室、血库、病案室、手术室,以及为医院的日常管理而设置的 行政部门等。
2.2各部门关系图
骨科 手术室 中心药房 住院处 制剂室 住院部 检验科室 检查科室 外科 内科 病案室 药库 设备科 财务科 后勤仓库 门诊部 问讯处 门诊收费处 门诊药房 口腔科 门诊挂号处
2.3门诊部的业务活动情况
首先,门诊病人需要到门诊挂号处挂号(如果病人有需要,可以设置人工咨询台对所要就诊的相应医科进行查询,可查询该医科的当班医生及其基本情况,然后再去挂号),挂号处分为初诊病人和复诊病人的挂号处,如果是初诊病人,需要在门诊挂号处登记其基本信息,如姓名、年龄、住址、联系方式等,由挂号处根据病人所提供的信息制成挂号卡,发放给病人,每个病人对应一个专有的病历号,这样方便管理病人的病历,也方便病人以后再来医院看病的时候挂号使用;复诊病人挂号只需要刷挂号卡就能排号就诊,由挂号处管理病人的病历。
其次,病人持挂号单和缴费收据到相应医科就医,经医生诊疗后,由医生开出诊断结果或者处方,检查或检验申请单,如为处方,则病人需持处方单到门诊收费处划价交费,划价交费的同时,该病人所要领取的处方药在药房的系统中自动显示,药房人员根据药方给该病人拿药,然后病人持收费证明到门诊药房取药; 如为检查或检验申请单,则病人需持申请单到门诊收费处划价交费,收费处根据交费的先后顺序,把所有做检查的病人排号,然后病人持交费收据到检查科室进行检查。
对于门诊药房来说,接到取药处方后,要进行配药和发药,所有药都在药房管理系统中进行管理,当药房库存的药品减少到一定量的时候,药房人员应到药库办理药品申领,领取所需的药品,而药房需对药品的出库、入库和库存进行管理;
当检查科室接到病人的申请后,对病人进行检查,并将检查结果存入系统中,同时也存入该病人的电子病历中,如果检查报告单需要等待一段时间才出结果,病人可以持自己的病历卡到自助查询机器上打印化验结果单。
病人可持检查或检验的结果再到原医科进行复诊,直至医生开出处方或提出医疗建议,最终病人痊愈离院。
3.目标及用户特点
3.1目标
该系统为医院提供一个集门诊划价、收费、发药、化验、住院于一体的管理信息系统,可实现信息存储、更新、查询等多项功能,为医务工作者和病人提供方便。
3.2用户特点
该系统的用户大多是医院的医务工作者、后勤工作人员、药剂师等,工作时间紧张,所以需要系统的运作使工作效率有大幅度提高,因此对系统的要求需要很完善,涉及到工作人员每一个工作细节。
4.需求规定
由于系统的使用主体是医院的管理人员,因此对系统的信息要求可分为以下 几个方面:
4.1病人信息
病人的基本信息应该包括病人的姓名、性别、出生年月、年龄、家庭住址、联系方式等。对于门诊病人,还需要就诊时间,就诊医科,就诊结果,处方记录,检查时间,检查项目,检查结果,检验时间,检验项目,检验结果等。对于住院病人,还需要入院时间,所在病区,所在医科,床位号,主治医师,用药记录,检查时间,检查项目,检查结果,检验时间,检验项目,检验结果,手术时间,手术相关记录,病人病情变化记录,相关体检记录,出院时间等。
4.2医生信息
医生的基本信息包括医生的姓名、性别、出生年月、家庭住址、联系方式、所在医科、工龄、职称、工号等。对于门诊医生,还需要挂号单价,当天工作量,出诊时间等。对于住院医生,还需要所在病区,负责病人,诊断记录及手术记录等。
4.3各种单据的信息
各种单据,证明,如医生诊断书,处方单,检验申请单,检查申请单,检验结果报告单,检查结果报告单,收款单,病人医疗记录,手术申请单,手术通知单,病人入院登记单,转科申请单,病人情况登记单,药品提领单,药品发放记录,药品出库单,药品入库单,设备使用记录,器械领用单,器械使用记录等。
4.4各种库存信息
各种库存,如药品、制剂、设备、器械以及后勤劳保用品等的信息,包括入库记录,出库记录,库存量,单价等。5.对功能的规定
系统应当完成以下的信息处理:
(1)存储病人的信息、医生信息、单据、库存信息,以供查询。
(2)对病人信息、医生信息、库存信息进行及时的更新和统计,如根据医生的出诊情况、工龄、工作量、职称等,得出医生工资中相应的应得金额,完成对医生工资的计算和统计,供发放。
(3)病人的电子病历可以存储在IC卡中,病人复诊的时候能够刷卡挂号,查询化验结果的时候能在自助查询机上刷卡进行查询,以便提高医院工作的效率。(4)各种单据、证明以及记录,根据实际需要,进行更新,统计,自动处理,等等,如对病人病情的记录的及时更新,对药品提领情况的及时统计,通过系统,自动生成一些单证,如系统将手术申请单进行相应的处理,根据所存储的信息得出相关信息,如手术可进行时间,手术室地点安排等,进而生成手术通知单。(5)对各种库存信息的及时更新和统计以及相关的自动处理,系统应根据库存量,入库量,出库量,自动得出新的即时的库存量,完成更新,当库存少到一定程度,系统应提出警告,提示管理人员库存不足,使管理人员做出相应的处理。(6)对医院所需的各种报表能根据计算机的统计,自动生成,例如统计图形、趋势图等,以便研究工作中写分析报告,也可以对科研做贡献。
(7)所有原始数据和统计数据进行相关分析,如门诊收入,住院收入,药品收支,物资情况,医疗信息,病区床位利用率,床位周转率等。
6.对性能的规定
6.1安全性要求
系统应对不同用户设置不同的权限,区分不同的用户,如区分病人(只能查询医生的出诊情况,医科设置,医生简介和本人的信息),医生(只能查询本医科诊治的病人资料,本人的信息,医院的公共信息等),管理人员(可查询医院相关的运作情况,并可根据其工作内容,录入相关的信息,修改相关的记录),系统管理员(可对系统进行日常维护,包括数据更新,权限设置等),院长(可查询医院所有运作情况(包括医院的医疗管理、经济管理、行政管理等)的数据,医生的信息,以及各种统计和分析结果等)。
6.2完整性要求
a、各种信息记录的完整性,信息记录内容不能为空; b、各种数据间相互的联系的正确性; c、相同的数据在不同记录中的一致性。
6.3综合性能要求
模快化设计,具有良好的可扩充性,以适应医院不同阶段的发展需要。方便的系统剪裁功能,各子系统间任意选择是否联网。信息共享、准确及时交流信息:发挥网络功能,减少重复操作,提高工作效率。彻底改变手工或单机管理对信息收集处理中的重复、混乱和容易出错的状况,充分利用计算机网络及关系型数据库的资源共享、数据共享等技术。一个环节录入信息,其它环节可以共享,确保数据的准确性和一致性。基本信息录入采用拼音输入方式,鼠标操作,基本不需输入汉字,大大提高工作效率。7.系统结构
7.1第一层数据流图
刷卡挂号、挂号单门诊挂号处病人基本信息病人收据药品门诊药房处结果报告单门诊病历处方单、化验申请单复诊时查询上次病历诊断完录入病历病历、检查报告单收处方据单、化验申请单门诊收费处检查申请单、收据医生诊断检查化验科
7.2第二层数据流图 7.2.1挂号处
病人基本信息初诊病人电子病历、IC卡录入病人基本信息并读入IC卡病人基本信息IC卡复诊病人挂号处理门诊病历挂号单病人 7.2.2收费处
检查申请单挂号单病人划价处理收费明细缴费开收据收费证明病人处方单门诊病历
7.2.3取药处
划价病人药品清单进入药房管理系统取药单药房配药并发药药品药品库存信息入系统病人
7.2.4化验处
化验处化验申请单、病历病人病历情况医生诊疗化验报告单、病历病人门诊病历
第四篇:医院门诊管理系统数据库需求分析
医院门诊管理系统一、引言
门诊是医院管理的重要组成部分,人流量大,手续较为繁琐。在人工的情况下,医护人员要做大量不必要的重复的工作、效率低、准确性差、不方便管理、影响工作效率。这些都会造成病人得不到合理快速的解决方案。随着社会的不断发展进步,计算机的发展亦十分迅速,在各大领域都发挥着不可忽视的作用。因此,我们选择利用计算机设计一个医院的门诊管理系统。它可以实现数据的信息管理,在一定程度上实现自动化。
二、需求分析
本系统的主要功能是对医院门诊患者信息进行有效管理,形成一个完整的体系。主要任务是用计算机来对患者进行管理,如挂号、诊断、计价、收费、取药等。系统可以详细记录病人从挂号处挂号到门诊缴费,以及经医生诊断后取药的过程中的所有信息。
三、主要要求
系统要满足以下几个方面:
(1)病人管理
在此管理模式中,维护病人的基本信息,如姓名、性别、联系方式等。同时也可以删除、修改、添加病人的信息。
(2)挂号系统管理
输入病人信息,系统会自动生成挂号费用,挂号之后会自动生成病号信息到病号信息库中。病历号必须唯一,以供全系统共享调用,整个系统通过这个唯一病历号贯通一体,大夫和病人都可以藉此查询所有的就诊历史信息,并实现划价收费、药房取药等操作。若病号库中已存在该病号,则可以直接进行挂号操作。
(3)医生管理
医生管理模块中存储医生的基本信息。此模块也实现信息化管理医生收发病例。
(4)药品管理
药品发放由药房管理人员完成操作,药房通过收款单来给病人发药。在病人缴费后,可直接到药房取药。发药的同时减少药品库存量。通过查询病号来确定药品名称及数量。
(5)处方管理
处方管理是要完成病历上病情、病史的记载,以及医嘱的开立和实施。
四、系统功能图
门诊管理系统 |
病人管理 |
查询病人信息 |
删除病人信息 |
增加病人信息 |
修改病人信息 |
门诊挂号 |
挂号管理 |
医生管理 |
查询医生信息 |
增加医生信息 |
删除医生信息 |
修改医生信息 |
药房发放药品 |
处方管理 |
处方单录入 |
处方单查询 |
修改处方单 |
查询药品 |
查询发药单 |
药品管理 |
挂号单查询 |
五、数据字典
实体 | 数据项名 | 说明 | 类型 |
病人 Patient | PatientNo | 病人编号 | char(12) |
PatientName | 姓名 | varchar(10) | |
Sex | 性别 | char(1) | |
Age | 年龄 | int | |
ID | 身份证号 | char(18) | |
TEL | 电话 | varchar(12) | |
HP | 过敏药物 | varchar(100) | |
病历 MRecord | M_No | 病历编号 | char(12) |
M_Date | 就诊日期 | Datetime | |
Symptom | 主要症状 | varchar(100) | |
员工 Employee | EmployeeNo | 员工编号 | char(13) |
EmployeeName | 员工姓名 | varchar(10) | |
Sex | 性别 | char(1) | |
Age | 年龄 | int | |
ID | 身份证号 | char(18) | |
TEL | 电话 | varchar(12) | |
Position | 职位 | varchar(10) | |
Salary | 工资 | Numeric(10,2) | |
WorkDate | 工作日期 | DateTime | |
WorkTerm | 工作年限 | int | |
科室 Department | DepartmentNo | 科室编号 | char(5) |
DepartmentName | 科室名称 | varchar(20) | |
Address | 科室位置 | varchar(50) | |
Manager | 负责人 | varchar(10) | |
TEL | 电话 | varchar(12) | |
Introduction | 科室介绍 | varchar(200) | |
挂号单 Register | RegisterNo | 挂号单编号 | char(14) |
RegisterTime | 挂号时间 | Datetime | |
RegisterFree | 挂号费 | Numeric(10,2) | |
药品 Medicine | MedicineNo | 药品编号 | char(15) |
MedicineName | 药品名称 | varchar(25) | |
MedicineClass | 药品类别 | varchar(10) | |
UnitPrice | 单价 | Numeric(10,2) | |
Elements_m | 主要成分 | varchar(200) | |
Function_M | 主要功能 | varchar(200) | |
Usage | 用法用量 | varchar(200) | |
Providcer | 供应商 | varchar(50) | |
ProduceDate | 生产日期 | Datetime | |
Usefullife | 有效日期 | Datetime | |
Matters | 注意事项 | varchar(200) | |
Amount | 库存量 | Int | |
处方 Recipe | RecipeNo | 处方编号 | char(15) |
SickDate | 就诊日期 | Datetime | |
PatientNo | 病人编号 | char(12) | |
ElementNo | 员工编号 | char(13) | |
MedicineName | 药品名称 | varchar(25) | |
Quantity | 药品数量 | Int |
六、数据约束条件
(1)一个医院中有多个诊室,一个诊室中可有多个员工,但一个员工只属于一个诊室。
(2)员工由员工号来唯一标识,存储员工的相关信息,格式为:workDatime+流水号;病人由病人编号唯一标识,存储病人的相关信息,格式为:病人第一次看病时间+流水号;药品由药品编号唯一标识,格式为:p/s+国药准字;挂号由挂号编号唯一标识,格式为:日期+流水号;处方由处方单号唯一标识,格式为:R+日期+流水号。
(3)在同一时间段,药品发放只为一位病人;在同一时间段,医生只为一位病人看病。
(4)员工工作年龄超过18岁,满足工作年龄要求。
(5)联系电话不超过11位数
七、数据流图
病人 |
病人 |
门诊管理系统 |
病人信息 挂号单
缴费 缴费凭证
诊断 处方
取药凭证 药物
病人 |
挂号收费 |
挂号请求
挂号单 挂号信息 挂号记录
缴费 收费记录 收费记录
收费 医生信息
医生记录
接诊 |
看病
处方 诊断信息 诊断记录
取药 |
取药
药物信息
药物 药物记录
八、逻辑设计
关系模式:
(1)病人(病人编号、病人姓名、性别、年龄、身份证号、电话、过敏药物)
(2)病历(病历编号、就诊日期、主要症状)
(3)员工(员工编号、姓名、性别、年龄、身份证号、电话、职位、工资、工作日期、工作年限)
(4)科室(科室编号、科室名称、科室位置、负责人、电话、科室介绍)
(5)挂号单(挂号单编号、挂号时间、挂号费);
(6)药品(药品编号、药品名称、药品类别、单价、主要成分、主要功能、用法用量、供应商、生产日期、有效日期、库存量)
(7)处方(处方编号、就诊日期、病人编号、员工编号、药品名称、药品数量)
九、E-R图
员工编号 |
医生 |
科室 |
病历 |
病历编号 |
病人 |
药品 |
药 品 编 号 |
病人编号 |
科室编号 |
处方编号 |
第五篇:软件需求说明[范文]
软件需求说明
某公司总部设在北京,在上海、广州、成都和西安有分支机构,公司员工接近700名。由于公司业务和员工团队的迅速发展,为了提升整体工作效率,公司准备开发一套员工报账系统,取代原来的人工处理方式。
报账系统将支持员工记录(或预见)日常业务活动的开销,并自动结算每个月应该返还员工的补偿金额,补偿额会直接存入员工的工资帐户中。
报账系统应具有基于先进技术的图形化界面,员工可以输入业务活动的种类和简短描述,活动开销的类别,选择不同的支付方式,并可以生成灵活的报表。
报账系统应该有能力根据员工提供的信息和要求返还补偿额,同时保存全部员工的报账信息。员工可以通过他们自己的电脑来使用报账系统。由于牵涉到财务信息,报账系统必须提供可信的安全机制。
公司现有一套基于MicroSoft SQL Server的人事管理数据库系统,记录员工共的基本信息和团队的组织结构。报账系统将和现有人事管理数据库系统协同工作,需要引用人事管理数据库系统中的部分信息,但不会更新其内容。
通过报账系统,员工能够在出差前(提前2天)按照规定的额度向公司申请借款,相关的经理人员能够通过报账系统批复或拒绝。报账系统应在相关负责人批复之后通知该员工提取现金或确认相应款项已经划入指定信用卡(根据员工的要求);员工可以通过保账系统报销合理的业务活动经费。
财务部门将指定一位报账系统管理员监督拟建系统中的信息,负责初始设置和维护特定的分类额度准则,并能够定期或随机地向部门负责人提交报账系统情况的统计报告。
报账系统在每月的25日对通过审批的报账申请自动作一次结算,并以电子邮件的方式通知应该得到补偿的员工,同时生成一份统计报告传送给财务部门的系统监管人员。
具体的局部功能需求-----“提交报销申请”的Use Case
简介:
员工通过报账系统填写报销申请,输入相关活动产生的费用,在一次或者多次填写后提交,经验证之后,以电子邮件的方式通知相应经理批复。
事件流(Flow of Events)
基本事件序列(Basic Flow)1.打开报销单
[员工]:员工选择进入“报销申请”功能。
[系统]:该员工当月报销单存在,系统将取出相应信息并展示给员工;如果该员工的当月报销单不存在,则转至A1备选事件序列。2.添加报销记录
[员工]:员工要求添加一条报销记录。[系统]:系统显示一条空白的报销记录。3.填写报销记录单
[员工]:员工开始填写报销记录,每条报销记录包括的信息有:业务活动发生的时间、为了让员工方便而准确地输入相关信息,除了客户名称、业务活动原因和金额之外,其他信息域提供相应的下拉式选择列表。并记录员工输入的信息。
(重复以上针对每一条报销记录的活动),直至所有记录填写完毕。)4.验证报销单
[员工]:员工填写完毕所有报销记录之后,要求系统验证这些记录的合理性。[系统]:报销记录的初始状态为“未验证”,每当一条报销记录被验证为合理,系统将该报销记录的状态设置为“已验证”,系统在验证所有报销记录(为“已验证”)之后提示用户可以提交本月的报销单。验证为合理的记录必须满足集中条件:第一,不同种类的费用不超过相应得限额;第二,报销费用的类型要和员工的职能匹配。对于未通过的验证的报销记录,转至A5备选事件序列 5.提交报销单
[员工]:所有报销记录经过验证之后,员工提交当月的报销单。
[系统]:系统保存这张报销单,将报销单的状态设置为“已提交”并记录提交日期,同时这张报销单被设为“只读”。系统要从人事管理数据库中获知该员工及其经理(负担该员工当月开销者)的电子邮件地址。如果此时人事管理数据库不可用,转至A6备选事件序列。
为了及时通知相关人员,系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱中。当邮件成功发送后,员工得到一个确认信息。如果此时邮件系统未能将邮件及时发送,转至备选事件序列A7。
备选事件序列组(Alternative Flows)
A1 创建当月报销单
[起始位置]:基本事件序列中,员工进入报销申请程序并准备打开当月报销单。
[触发条件]:系统没有发现和该员工对应的当月报销单。
[具体内容]:系统为员工创建一张当月报销单。
[返回位置]:基本事件序列中的“打开报销单” 步骤。
A2 删除报销记录
[起始位置]:在提交报销单之前任意时间点。
[触发条件]:员工希望删除某一条报销记录。
[具体内容]:系统删除有员工指定的某一条报销记录。[返回位置]:同“起始位置”。
A3 更新报销记录
[起始位置]:在提交报销单之前任意时间点。
[触发条件]:员工希望更新某一条报销单。
[具体内容]:系统根据员工输入的内容更新相应的一条报销记录。[返回位置]:同“起始位置”。
A4 保存当月报销单
[起始位置]:该Use Case 允许员工在事件流中的任意时间点保存当月的报销单。
[触发条件]:员工希望将已经录入的报销记录保存在报账系统中。
[具体内容]:系统保存该员工当月报销单,并给出确认信息。员工可以在保存当月报销单之后直接退出系统。
[返回位置]:同“起始位置”。
A5 报销记录不合理
[起始位置]:基本事件序列中,“验证报销单”步骤中对每一条报销记录验证结束之后。
[触发条件]:包销记录不满足某一条适用的准则。有两种情形:第一,某报销记录的金额超出了其对应类型费用的上限,已知有三种:请客户用餐人均超过300元,出差时每天住宿费超过800元,移动电话费再无特殊说明情况下超过800元;第二,报销费用的类型和员工所处部门及职能不匹配,已知的情形是业务部门的员工申请加班补助。
[具体内容]:系统告知员工不合理的报销记录编号,以及未通过验证的原因。[返回位置]:即本事件序列中的“填写报销单”步骤,目的是更正有问题的报销记录。
A6 人事管理数据库不可用
[起始位置]:即本事件序列中,提交报销单步骤结尾
[触发条件]:当报账系统向人事管理数据库索取信息而该数据库没有正常的响应。
[具体内容]:以对话框形式告知员工“人事管理数据库不可用,报账但没有提交成功”。
[返回位置]:Use Case 执行结束。
A7 邮件未即时发出
[起始位置]:基本事件序列中,“提交报销单”步骤的结尾,成功地从人事管理数据库获得相关信息后。
[触发条件]:报账系统要求发送相关邮件时,邮件系统没有及时的响应。
[具体内容]:系统将以提示信息的方式告知员工“邮件没有及时发出,但是报销单在系统内已经提交成功,待邮件系统恢复后,相关邮件会自动发出”。[返回位置]:Use Case 执行结束。
特殊需求列表(专属于该Use Case)
暂无
启动条件
员工成功登录系统,通过身份验证。被系统提示进入“报销申请”或“借款申请”功能。
结束状态(组)如果该Use Case 顺利执行,员工得报销申请记录将被建立,更新、保存或者保存并提交;否则,系统地状态应该保持和该Use Case 执行之前相同。
辅助图示(活动图)
“补充规约”要点 1.RDBMS数据库访问 2.分布式处理
词汇表 要点
员工。公司的正式雇员
经理。负责审批某员工当月开销的管理者,是较高级别的员工。
报销纪录。与业务有关的某一项具体的花费,包括业务活动发生的时间、地点、客户名称(可选)、原因以及费用金额和种类(交通、餐饮、会议、通信和杂项)。 报销单。员工在一个(自然)月内的所有报销纪录的集合。
工资户头。公司将员工用于日常业务活动开销的补偿金额返还至员工的银行账户,该帐户的基本功能是供员工接受工资。
人事管理数据库。该数据库纪录了有关人事管理的相关信息,与报帐系统有关的是公司的组织机构(“员工”和“经理”的关系)。
内部邮件系统。该邮件系统负责收发与公司业务有关的电子邮件信息。
“提交报销申请”[控制,SubmitClaim]的Use Case
简介:
员工通过报账系统填写报销申请,输入相关活动产生的费用,在一次或者多次填写后提交,经验证之后,以电子邮件的方式通知相应经理批复。
事件流(Flow of Events)
基本事件序列(Basic Flow)打开报销单
[员工]:员工[实体,关键抽象,Employee]选择进入“报销申请”[边界,SubmitClaimForm]功能。
[系统]:如果该员工当月报销单[实体,关键抽象,ClaimReport]存在,系统将取出相应信息并展示给员工;如果该员工的当月报销单不存在,则转至A1备选事件序列。添加报销记录
[员工]:员工要求添加一条报销记录。[系统]:系统显示一条空白的报销记录。填写报销记录单
[员工]:员工开始填写报销记录[实体,关键抽象,ClaimRecord],每条报销记录包括的信息有:业务活动发生的时间、地点、客户名称(可选)、原因以及费用金额和种类(交通、餐饮、会议、通信和杂项)。
[系统]:系统显示并记录员工输入的信息。为了让员工方便而准确地输入相关信息,除了客户名称、业务活动原因和金额之外,其他信息域提供相应的下拉式选择列表。
(重复以上针对每一条报销记录的活动),直至所有记录填写完毕。)验证报销单
[员工]:员工填写完毕所有报销记录之后,要求系统验证这些记录的合理性[实体,ValidRule]。
[系统]:包销记录的初始状态为“未验证”,每当一条报销记录被验证为合理,系统监该报销记录的状态设置为“已验证”,系统在验证所有报销记录(为“已验证”)之后提示用户可以提交本月的报销单。验证为合理的记录必须满足集中条件:第一,不同种类的费用不超过相应得限额;第二,报销费用的类型要和员工的职能匹配。对于未通过的验证的报销记录,转至A5备选事件序列 提交报销单
[员工]:所有报销记录经过验证之后,员工提交当月的报销单。
[系统]:系统保存这张报销单,将报销单的状态设置为“以提交”并记录提交日期,同时这张报销单被设为“只读”。系统要从人事管理数据库[边界,HRDatabase]中获知该员工及其经理(负担该员工当月开销者)的电子邮件地址。如果此时人事管理数据库不可用,转至A6备选事件序列。
为了及时通知相关人员,系统将自动生成一份以当前报销单为内容的电子邮件发送到该员工及其经理的信箱中。当邮件成功发送后,员工得到一个确认信息。如果此时邮件系统[边界,MailSystem]未能将邮件及时发送,转至备选事件序列A7。