项目名称
需求分析用例说明书
项目组成员信息 小组名称 学号 姓名 第六组 本文档中主要承担的工作内容
版本变更历史
目 录
1. 引言 .......................................................................................................................... 1
1.1 编写目的 ........................................................................................................ 1 1.2 系统概述 ........................................................................................................ 1 1.3 术语和缩略词 ................................................................................................ 2 1.4 参考资料 ........................................................................................................ 2 1.5 文档组织 ........................................................................................................ 2 2. 业务流程分析 .......................................................................................................... 2
2.1 组织结构 ........................................................................................................ 2 2.2 业务流程概述 ................................................................................................ 3 2.3 核心业务流程分析 ........................................................................................ 3 3. 功能需求 .................................................................................................................. 3
3.1 功能需求分解 ................................................................................................ 4 3.2 参与者分析 .................................................................................................... 4 3.3 用例分析 ........................................................................................................ 5 4. 数据需求 .................................................................................................................. 7
4.1 实体关系模型 ................................................................................................ 7 4.2 实体定义 ...................................................................................................... 18 4.3 编码标准及规范 .......................................................................................... 18 5. 非功能需求 ............................................................................................................ 18 6. 运行需求 ................................................................................................................ 19
6.1 硬件环境 ...................................................................................................... 19 6.2 软件环境 ...................................................................................................... 19 6.3 用户界面需求 .............................................................................................. 19
I
系统名称 需求分析规格说明书
1. 引言
1.1 编写目的
这份说明书具体系统的描述了医院门诊系统所涉及到的各个方面，也是为了编程人员更好的理解这个系统有哪些功能，这些功能之间有哪些共同点，有哪些联系，便于编程人员更好的编写代码，实现这个系统的功能。
1.2 系统概述
医疗门诊系统是为了实现挂号，门诊等功能的网络统一化，首先病人现在前台找挂号医生挂号，挂号医生从病人处得到病人信息，然后新建挂号单，将病人的信息填入挂号单中，然后根据病人提供的病况为病人选择合适的门诊部门，并根据病人的病情为病人选择挂号类型，如果病人病情不严重则选择普通类型，病人可能会等待一会才能得到医生的诊断；如果病人病情严重，需要立即就诊的就选择加急类型，病人就会得到医生的立即治疗。然后确定挂号单。挂号医生在确认挂单之后，该挂单信息就会传入到相应的门诊医生的电脑中，病人在找到门诊医生后，向医生描述自己的病情，医生对此作出简单的判断，然后对病人提出建议做些检查，然后将需要化验的信息填入到收费项目并确定，挂号医生会获得病人需要收费的项目，核算好价格，并加入收费中，病人到收费台缴纳费用，收费医生在确定收费后，相应的化验项目会传到化验医生的电脑中，病人找到化验医生，医生根据需要对病人做出相应的化验，化验结果会通过电脑传到门诊医生的电脑中，病人回到门诊室，门诊医生会根据病人的化验单对病人作出明确的病情诊断，如果病人病情严重，医生会建议病人住院（此处不做过多介绍），如果病人病情不重，医生会根据病情轻重给病人开出电子处方单并确定，确定之后电子处方会立即传到划价医生的电脑中，划价医生根据门诊医生开的电子处方对这份处方单计算出最终的价格，并提交最后的总价，然后收费医生会受到有总价的电子处方单，然后病人在收费处缴纳费用，收费医生确认收费后，处方单会传到药房药剂师的电脑中，药剂师根据处方单上的信息为病人抓药，并会得到相应药物的使用
1
系统名称 需求分析规格说明书
方法。
特点：这个医疗门诊系统实现了各部门信息的网络化，它没有改变传统的医疗步骤，但是他将传统的手写信息改变成为电脑输入，将病人拿着各种单子到处跑变为了网络传输信息，大大缩短了看病时间。
1.3 术语和缩略词
给出本文档中所涉及的专业的业务和技术术语。并给出文档中所有的缩略词的全称。
1.4 参考资料
无
1.5 文档组织
第一章的核心为介绍这款软件的作用，特点。 第二章对业务用流程图来进行分析。
第三章是对该系统的功能进行分解并仔细分析。
2. 业务流程分析
从用户视角介绍待建系统的业务环境、用户、承载的主要业务流程等对理解系统功能需求和非功能需求有帮助的信息。
2.1 组织结构
说明与目标系统相关联的部门情况，包括部门名称、主要职责等信息（可以以表格的形式给出）。 部门名称 主要职务 与系统关系 备注 2
系统名称 需求分析规格说明书
挂号处 门诊部 收费处 化验室 药房
挂号 诊治病人 收取费用 化验 给病人拿药 2.2 业务流程概述
简要说明系统所涉及的核心业务流程，包括业务流程名称、业务流程概述、涉及的部门等内容（可以以表格的形式给出）。
2.3 核心业务流程分析
针对2.2节说描述的每个业务流程，给出流程的详细信息。利用Visio绘制跨职能流程图进行描述。
3. 功能需求
以用例图的形式给出系统功能需求的分解结构，并对用例模型中的参与者和用例进行详细的描述，可参考如下思路将本节划分为几小节（也可按照系统的实际情况进行调整）。
3
系统名称 需求分析规格说明书
3.1 功能需求分解
< 3.2 参与者分析 参与者姓名 挂号医生 门诊医生 收费医生 化验医生 划价医生 药剂师 病人 职责描述 为病人挂号，将收费项目加入收费中 为病人诊断病情，并为病人开出处方单 将收费项目核算并收费 为病人做需要的化验 将电子处方划定价格 根据电子处方给病人拿药 根据病情找医生诊断 所属组织机构 挂号处 门诊部 收费处 化验室 收费处 药房 典型用户代表 4 系统名称 需求分析规格说明书 3.3 用例分析 3.3.1 用例ID：YYGH-001 用例名：挂号 获取病人信息< 系统名称 需求分析规格说明书 单，从中找出那个病人的信息，并找到门诊医生为之开的医疗项目单来计算收费，并将收费项目所需的费用转入到收费中 前置条件 触发规则 典型事件过程 无 当病人需要挂号时，用例被触发 参与者动作 系统响应 第1步：病人提供他的身份证第1步：新建挂号单 号以及姓名，年龄等等。 第2步：挂号医生根据需要新第2步：提交挂号单 建挂号单，并填写病人信息。 第3步：挂号医生根据病人病第3步：获取门诊收费项目 因和病情为病人选择门诊部门和挂号类型。 第4步：医生根据历史信息查第4步：将收费项目所收费用加入找到病人信息，并获得门诊医收费 生开的收费项目 第5步：将收费项目纳入收费中 替代第2步：如果病人有过历史，可从历史挂号单中查找出来 当挂号信息填写完毕，确认挂号，并将收费项目加入收费时该用例结束 将收费项目划入收费中，收费医生获取信息并收取费用 病人必须提供有效信息才能挂号，并能够就诊 病人提供信息 挂号医生正确给病人选择了门诊部 替代事件过程 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 6 系统名称 需求分析规格说明书 3.3.2 用例ID：YYGH-001 用例名：门诊 用例名称 用例ID 电子处方 YYGH-001 7 用例类型 业务需求: 系统名称 需求分析规格说明书 优先级 高 来 源 主要参与者 其他参与者 其他有兴趣 的关联人员 描 述 病人，处方医生 挂号医生 无 该用例描述处方医生在登录协创医院管理系统之后，点击医生工作站中的电子处方，然后双击选中的病人门诊号信息，确定之后根据病人提供的病情选择医疗项目，然后再加入医疗项目，然后处理形成完整的处方单 挂号 当填完相关信息，处理确定时，用例被触发 参与者动作 第1步:处方医生登录协创医院管理系统，打开医生工作站中的电子处方，选择门诊号信息，选择医疗项目，处理处方单 系统响应 第2步: 系统验证所需的信息提供处方单。 第3步：系统验证所需的信息提供门诊号信息 第4步：系统验证所需的信息提供医疗项目信息 第5步：系统根据所需信息处理形成所需的处方单 替代第5步：提供的信息中的未加入医疗项目，通知处方医生，并要求修改后重新处理 当潜在用户收到注册确认时，该用例结束。 处方医生所选择或输入的信息满足时，形成处方单，并通知划价医生 病人提供门诊号信息和自身病况 要求为门诊服务提供设备及医疗系统 处方医生通过正常操作来形成处方单 需要决定病人门诊号信息的正确性以及根据病人情况及时提供检验去向。 前置条件 触发规则 典型事件过程 替代事件过程 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 用例名称 用例ID 电子处方 YYCF-001 用例类型 业务需求: 8 系统名称 需求分析规格说明书 优先级 高 来 源 主要参与者 其他参与者 其他有兴趣 的关联人员 描 述 病人，处方医生 无 无 该用例描述处方医生在登录协创医院管理系统之后，点击医生工作站中的电子处方，然后双击选中的病人门诊号信息，在已有的处方单上根据检验结果开出药品，然后再说明药品用法用量，然后处理新的的处方单 检验 当填完相关信息，处理确定时，用例被触发 参与者动作 第1步:处方医生登录协创医院管理系统，打开医生工作站中的电子处方，选择门诊号信息，选择药品，说明药品用法用量，处理处方单 系统响应 第2步: 系统验证门诊号信息提供原有处方单。 第3步：系统验证所需的信息提供药品信息 第4步：系统处理处方医生所输入药品用法用量的信息 第5步：系统根据所需信息处理形成所需的新的处方单 替代第3步：提供的信息中药品输入错误，通知处方医生，并要求修改后重新处理 当形成新的处方单时，该用例结束。 处方医生所选择或输入的信息满足时，形成处方单，并通知划价医生 要求为门诊服务提供设备及医疗系统 处方医生通过正常操作来形成处方单 需要根据病人检验结果开药 前置条件 触发规则 典型事件过程 替代事件过程 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 9 系统名称 需求分析规格说明书 3.3.3 用例ID：YYJY-001 用例名：检验 用例名称 用例ID 优先级 检验 YYJY-001 高 用例类型 业务需求: 来 源 主要参与者 其他参与者 其他有兴趣 的关联人员 描 述 病人，检验医生 门诊医生 无 该用例描述了在门诊医生给病人开了检验项目，收费医生收取相应费用之后，化验医生得到病人需要的化验项目并对病人做对应的检验，然后将病人的检验报告传回到门诊医生的电脑中。 门诊医生给病人开了需要化验的检验项目 当检验单提交时，用例被触发 10 前置条件 触发规则 0 系统名称 需求分析规格说明书 替代事件过程 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 第5步：安排病人检验事项。 第6步：一旦完成检验，打印检验报告并发送给病人。 替代第6步：如果给病人安排的检验事项不正确，则进行修改。 当病人收到检验确认时，该用例结束。 门诊医生在收到化验单后才能正确诊断病人的病 门诊医生提供化验请求单 医院设备支持化验 3.3.4 用例ID：YYGH-001 用例名：划价 用例名称 用例ID 划价 YYGH-001 11 用例类型 业务需求: 系统名称 需求分析规格说明书 优先级 高 来 源 主要参与者 其他参与者 其他有兴趣 的关联人员 描 述 前置条件 触发规则 典型事件过程 挂号 病人，划价医生 无 无 该用例描述划价医生根据挂号信息新建划价单，建好划价单之后，将划价信息转交给病人，病人再将进行门诊缴费 已经挂号 当新建划价单建好时，用例被触发 参与者动作 系统响应 第1步: 第2步: 系统验证所需的所有信息划价医生提供新建划价单，并都提供了之后做出响应。 提供给病人 第3步：系统验证新建划价单的正确性，保证划价正确，两次密码输入一致等。 第4步：一旦处理完划价，系统生成一个划价确认，并发送给病人 第1步：划价医生没有得到电子处方，提示未收到处方单 第2步：划价医生提供的划价单上的划价提示错误，划价医生需要重新划价 当病人收到划价单时，该用例结束。 病人需要已经挂号 挂号医生必须提供有效的药物名称划价医生才能划价 要求为病人提供划价单 划价医生通过划价单划价 需要决定如何保证划价信息的正确性。 替代事件过程 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 12 系统名称 需求分析规格说明书 3.3.5 用例ID：YYSF-001 用例名：收费 用例名称 用例ID 优先级 收费 YYGH-001 高 用例类型 业务需求: 来 源 主要参与者 其他参与者 其他有兴趣 的关联人员 描 述 病人 收费医生 划价医生 无 该用例描述潜在用户在完成注册，接着挂号后获取门诊号，看病医生分析病况，建立电子处方，需划价医生进行药品划价后，到收费医生处提供门诊号，收费医生依据门诊号建立收费单，若已有已交收费单需删除。潜在用户查询新建收费单，确认无误后进行缴费这一项目。 需划价医生依据电子处方划价 当收费信息提交时，用例被触发 参与者动作 系统响应 第1步: 病人提供他的门诊号第2步: 系统确认门诊号，自动生给收费医生，收费医生传送给成收费单，并发送给用户查看，确系统。 认。 第3步：。系统将收费单保存到数据库中，并发送给系统管理员，等带审核。 替代第2步：潜在用户没有提供收费所需的信息，通知潜在用户13 前置条件 触发规则 典型事件过程 替代事件过程 系统名称 需求分析规格说明书 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 并提示重新提交 替代第3步：提供的信息中的已经存在或两次输入不一致，通知潜在用户，并提示错误，要求修改后重新提交 当潜在用户收到收费确认时，该用例结束。 潜在用户所输入的信息满足本应用的各种格式要求并且在数据库中没有重名的信息号码存在，并通知了管理员，管理员登陆后，可以对收费单信息进行审核 潜在用户必须提供有效的门诊信息才能建立收费单 14 系统名称 需求分析规格说明书 3.3.6 用例ID：YYSF-001 用例名： 用药药品类型< 用例名称 用例ID 优先级 药房 YYCF-001 高 用例类型 业务需求: 来 源 主要参与者 其他参与者 其他有兴趣 病人，药剂师 门诊医生 无 15 系统名称 需求分析规格说明书 的关联人员 描 述 门诊医生根据病人的化验单准确判断病人的病因，并为病人开出合适的电子处方，病人缴纳费用后，药剂师根据电子处方上的处方为病人抓药，并告诉病人服用方法 前置条件 触发规则 典型事件过程 替代事件过程 结 论 后置条件 业务规则 实现约束 和说明 假 设 开放问题 门诊医生开出电子处方，病人缴纳费用 病人交完处方费用 参与者动作 第1步:病人到药房，药剂师根据病人信息得到病人的处方 第2步:药剂师根据处方为病人抓药，并告诉病人服用方法 系统响应 第2步: 系统验证门诊号信息提供原有处方单。 第3步：系统验证所需的信息提供药品信息 第4步：系统处理处方医生所输入药品用法用量的信息 第5步：系统根据所需信息处理形成所需的新的处方单 替代第3步：提供的信息中药品输入错误，通知处方医生，并要求修改后重新处理 当形成新的处方单时，该用例结束。 处方医生所选择或输入的信息满足时，形成处方单，并通知划价医生 要求为门诊服务提供设备及医疗系统 处方医生通过正常操作来形成处方单 需要根据病人检验结果开药 3.3.6.1 功能概述 3.3.6.1.1 输入数据项详细描述 序号 输入项名称 详细含义 数据类型 输入限制 备注 {序号：从1开始的整数 输入项名称：汉字描述，如纳税人识别号 16 系统名称 需求分析规格说明书 详细含义：该项的具体表示内容，如纳税人在系统中的唯一标识号 数据类型：分字符、整数、浮点数、货币、日期、选择项等 输入限制：长度限制或其他限制（如只能输入0－9或A-Z），如果是必填，必须注明；如果是计算字段，必须注明 备注：其它说明} 3.3.6.1.2 业务处理流程描述 {用文字描述加活动图方式描述业务处理流程。 对于较简单的情况可只用文字描述。 对于较复杂的业务流程，必须用活动图描述，较复杂的情况包括： 有分支或条件情况较多； 处理步骤在3步以上； 牵涉到的用户、模块在两个以上 活动图的绘制参见《活动图绘制规范》} 3.3.6.1.3 输出结果详细描述 序号 输出项名称 详细含义 数据类型 备注 {序号：从1开始的整数 输出项名称：汉字描述，如纳税人识别号 详细含义：该项的具体表示内容，如纳税人在系统中的唯一标识号 数据类型：分字符、整数、浮点数、货币、日期、选择项等 备注：其它说明} 17 系统名称 需求分析规格说明书 3.3.6.1.4 与其他模块的相关性 序号 关联模块（或功能项） 关系 4. 数据需求 4.1 实体关系模型 给出系统的ER图（用Power Designer绘制概念/逻辑数据模型），并对实体间的重要关系进行简要描述。 4.2 实体定义 对ER图中的实体的数据项进行简要的描述，包括属性名称、属性类型和说明信息等（可以以表格的形式表示）。 4.3 编码标准及规范 针对系统中所涉及的有关编码规则和一些标准进行说明或定义。 5. 非功能需求 给出系统的性能、可靠性、可扩展性、易用性、安全性等非功能需求。每项非功能需求可作为一小节，如果没有可以省略。 18 系统名称 需求分析规格说明书 6. 运行需求 6.1 硬件环境 描述与该系统实施相关的硬件环境的要求；包括服务器、客户端主机、网络环境等。 6.2 软件环境 描述与该系统实施相关的软件环境的要求。 6.3 用户界面需求 描述对该系统用户界面的基本要求，可以利用一些原型设计工具（如UIDesigner、AurxeRP或Dreamweaver、Photoshop等设计工具）给出用户界面原型方案。 19 因篇幅问题不能全部显示，请点此查看更多更全内容