医院信息管理系统需求分析

二、项目介绍
2.1 项目背景
本项目是针对《软件工程导论》课程的需要而建设成的 站，以加强医院与患者之间的联系以及方便公民就医为目的而建设的 站。
2.2 项目目标
本项目将所有的功能化为X个模块:职工系统管理、患者信息管理、科室信息管理、药物系统管理

三、应用环境
服务器配置如下
操作系统：Windows XP及以上
CPU：Intel i5酷睿双核及以上
内存：16G及以上
硬盘空间：100G以上
软件配置如下：
开发工具：MyEclipse
数据库：SQL Server
Web服务器：Tomcat

四、功能规格
4.1系统角色分析
角色或执行者是与系统产生交互的外部用户或者外部系统。本系统的使用角色主要分为医院职工（包括医生，护士，药房工作人员，行政人员等等），患者，管理员三种。以下是对每个角色的详细介绍。
不同角色将拥有不同权限，即使用过程中功能配置不同。其中职工部分人员可拥有多重身份。
4.1.1医院职工
此类角色无需注册，由后台管理员分配账 。
1、医生
医生可在该系统进行登陆，可用功能主要有，查看本科室工作安排表，查看本科室病患信息（包括电子病历，检查 告等），可撰写电子病历，开出取药单，并对电子病历和取药单可进行导出打印。
2、护士
护士可在该系统进行登陆，可用功能主要有，查看本科室工作安排表，查看本科室病患信息（包括电子病历，检查 告等），可撰写医嘱和护理记录。
3、药房工作人员
药房工作人员可在该系统进行登陆，可用功能主要有，查询药物信息，查看病患药物信息，对药品出库入库进行修改登记。
4、财务工作人员
财务工作人员可在该系统进行登陆，可用功能主要有，对患者缴费情况进行查询和登记。
5、行政人员
行政人员可在该系统进行登陆，可用功能主要有，查看所有医院职工信息，可上传科室工作安排表，查看医院各种统计数据等。
4.1.2 患者
此类角色在第一次使用系统时需要进行注册，并登记真实身份信息。
患者可用功能主要有查看科室信息，查看医生护士职工信息，可进行预约挂 或取消挂 ，查看本人历史病历记录，检查 告，用药记录，缴费记录等。
4.1.3 管理员
此类角色为固定账 。
管理员可在该系统进行登陆，可用功能为，管理医院职工信息，管理患者信息，管理科室信息，统计数据管理，药品信息管理，项目收费管理。
4.2主用例图

4.4.1 职工信息管理
角色：管理员
目的：对医院各类职工信息进行增加，修改，停用等。
用例描述：
1、用户处于登陆成功后的界面，点击职工信息管理模块。
2、五个可选项对五种医院职工信息进行管理。可通过选择种类，科室两种方式进行显示信息列表。
3、可直接通过职工编 或姓名进行直接查询。
4、可对医院各类职工信息进行增加，修改，密码重置以及设置停用标志（由于关系历史记录，不可对人员信息记录进行删除）。
4.4.2 患者信息管理
角色：管理员
目的：对患者信息进行增加，修改，停用等。
1、用户处于登陆成功后的界面，点击患者信息管理模块。
2、可直接通过就诊卡 或姓名或身份证 进行直接查询。
4、可对患者信息进行增加，修改，密码重置以及设置停用标志（由于关系历史记录，不可对人员信息记录进行删除）。
4.4.3 科室信息管理
角色：管理员
目的：对科室信息进行增加，修改，停用等。
1、用户处于登陆成功后的界面，点击科室信息管理模块。
2、显示所有科室模块。
4、可对科室信息进行增加，修改，设置停用标志。
4.4.4 药品信息管理
角色：管理员
目的：对药品信息进行增加，修改，停用等。
1、用户处于登陆成功后的界面，点击药品信息管理模块。
2、可通过药品编 或名字进行查询，显示药品信息和库存量，可以修改药品简介和单价。
4.4.5 项目收费管理
角色：管理员
目的：对收费项目信息进行增加，修改，停用等。
1、用户处于登陆成功后的界面，点击项目收费管理。
2、可通过收费项目编 或名字进行查询，可以修改收费项目单价。
4.4.6 统计系统管理
角色：管理员
目的：查看各项统计数据
用例描述：
1、用户处于登陆成功后的界面，点击统计系统模块。
2、选取需要查看的统计类型，选择时间区间，显示统计结果。

4.5 非功能新需求
4.5.1 界面需求
系统的界面要求如下：
1、页面内容：各类信息内容准确，术语和行文格式统一、规范、明确，栏目、菜单设置和布局合理，传递的信息准确、及时。
2、导航结构：页面具有明确的导航提示，且便于理解，方便用户使用。
3、技术环境：页面大小适当，能用各种常用浏览器以不同分辨率浏览；无错误链接和空链接。
4、艺术风格：界面、版面形象清新悦目、布局合理，字 大小适宜、字体选择合理，前后一致，美观大方；色彩和谐自然，与内容相协调。
4.5.2响应时间需求
当用户登陆，系统应该及时地进行反应，反应的时间在3秒以内。系统应能检测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现长时间等待甚至无响应。
4.5.3 可靠性需求
系统应保证7*24小时内不宕机，保证100人以上可以同时在客户端登陆，系统正常运行，正确提示相关内容。
4.5.4 可扩展性需求
系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。
4.5.5 系统安全性需求
站有严格的权限管理功能，各功能模块需有相应的权限方能进入（如职工和患者具有不同的访问权限）。系统能够防止各类误操作可能造成的数据丢失，破坏。防止用户非法获取 页以及内容。

五、需求变更
需求变更控制过程如图所示。
从上图可以得到需求变更的控制过程为：客户递交变更，形成变更请求，变更请求递交给开发小组，开发小组主要从技术实现的层面评估该变更请求是否合理，并对其进行成本和影响分析，接着将变更请求递交给产品开发小组产品开发小组从机构和战略以及经济的层面评估该变更请求是否合理，然后进行变更选择。
选择的结果有三种：一种是拒绝，也就是变更失败；一种是下个版本再修改，一种是变更通过。若变更通过，就需要修改相关需求，修改合同的相关信息，修改相应的项目计划。这样，需求变更的控制过程就结束了。