体检医院管理系统需求规格说明书_模板.docx

文档修改记录版本号主要作者修改记录完成日期 /文档修改记录，用于记录本版本、以及以前版本的变更情况，概要性的说明版本之间的内容差异，使读者能够快速、便捷地查看本版本的焦点内容。目录1文档概述21.1目的21.2背景21.3定义21.4参考资料22任务概述22.1业务需求22.2Stakeholder利益分析（略）22.3用户特点分析22.4相关事实与假定23需求概述23.1系统概述主题域划分，用构件图表述23.2主题域 123.2.1功能需求概述23.2.2业务事件23.2.3报表24具体需求24.1主题域124.1.1用例模型24.1.2领域模型25补充规约25.1设计约束25.1.1技术选择的限制条件25.1.2运行环境25.1.3预期的使用环境25.2质量属性25.2.1安全性要求25.2.2可靠性要求25.2.3易用性要求25.2.4性能要求25.2.5可维护性要求25.2.6可移植性要求25.2.7其他质量属性要求25.3其他需求25.3.1培训需求25.3.2后勤需求25.3.3包装需求21 文档概述/文档概述，作为文档的第一部分，对整个软件需求说明书文档进行概要性的说明，帮助读者快速了解文档目的、编写约定、阅读方式以及软件产品。1.1 目的/说明文档编写目的，即软件需求说明书的作用以及主要内容。其中要明确说明待修订的软件版本号，以及即将发行的软件版本号。1.2 背景1.3 定义1.4 参考资料2 任务概述 2.1 业务需求 2.2 Stakeholder利益分析（略） 2.3 用户特点分析 2.4 相关事实与假定 3 需求概述 3.1 系统概述主题域划分，用构件图表述 3.2 主题域 1 3.2.1 功能需求概述 用上下文关系图表示该主题域的范围步骤：（1） 找出外部的Customer，这些Customer会发起什么事件；这些事件会引发内部的Worker的什么工作。这些都是人？（2） Worker主动发起什么事件（3） 业务事件分析（4） 报表类型分析不太理解？注意：（1） 这些人对系统有哪些独立的行为（2） 如果主题域较小，可以不用画上下文关系图（3） 团队建模使用，与用户代表沟通时绘制，不建议BA独自绘制关键词：（1） 独立行为（例如体检者到各科室进行体检、等待体检，这些都是申请体检后必然发生的，非有效线索）（2） 业务事件类型业务事件外部事件Customer发起、Worker发起内部事件Timer事件、Status事件（3） 业务事件标识：主动触发并能发生一系列后续行为，触发系统行为；不是系统事件（数据备份、更改密码）3.2.2 业务事件3.2.2.1 业务事件1包括流程分析、领域类分析、用例分析3.2.3 报表3.2.3.1 Report 1 用领域类图片段表示涉及数据，用用例标识具体的报表项4 具体需求4.1 主题域14.1.1 用例模型4.1.1.1 UC_B_xx（B类） P253（1）概述编号、名称、概述、相关Stakeholder （2）事件流描述前、后置条件，基本、扩展、子事件流 （3）相关需求与功能点 （4）界面原型交互过程与界面详解 （5）规约与约束 4.1.1.2 UC_R_xx（R类） （1）概述名称、用户部门与职位、业务意图、相关场景 （2）报表内容领域类图、数据项 （3）输入/输出格式 （4）其他 4.1.1.3 UC_I_xx（I类） （1）使用者名称、业务目的、时机、频率 （2）内容与格式交互过程、数据包说明 （3）设计与实现约束诸如协议格式要求、性能要求等 4.1.2 领域模型4.1.2.1 XX领域类（1）概述类名称、别名 （2）数据窗口分析涉及主题域、业务事件，各域数据 （3）数据组成与格式 （4）其他 4.2 主题域14.2.1 用例模型4.2.1.1 开单（UC_B_TJ_KaiDan）1， 概述l 用例名称：开单l 编号：UC_B_TJ_KaiDanl 参与者：服务人员l 用例概述：服务人员根据体检者的选择或预约单开具体检单，并打印出来交给体检者l 相关stakeholder：Stakeholder利益点体检者1） 办理速度要快，避免排长队2） 无需记录无意义的预约号收费人员可直接调出体检单生成账单2， 事件流l 前置条件：无 /* 用例启动前系统能检测到的、有意义的、参与者的状态。1. 客户已发出订单：不合适！系统无法检测2. 工作人员已登录系统：不合适！显然的条件，意义不大。不要有模板综合征3. 库存大于订单数：不合适！系统在用例开始前无法检测。 */l 后置条件：确保没有重复的体检项目/* 用例结束前系统能检测到的、有意义的、参与者的状态。前后置条件出现的概率并不高，需要时再写，不要画蛇添足 */l 基本事件流1. 参与者输入用户姓名或预约号，系统确认用户已经预约，并从预约单中获取体检套餐和体检项目显示在屏幕上2. 系统确认用户选择体检套餐与体检项目符合要求（参见规则UC_KD_01）3. 系统保存并打印体检单/* happy day、大部分时间遇到的、用户预期的场景；系统核心价值 */l 备选事件流1a. 参与者或系统确认用户没有预约1a1. 参与者输入用户基本信息，并根据用户选择输入体检套餐与体检项目信息1b. 系统发现有多个可能重名的预约用户1b1. 系统显示所有可能重名的预约用户，并显示区分身份的主要信息1b2. 参与这从中选择符合的预约用户，并从相应的预约单中调出数据2a. 用户选择的体检套餐不符合要求2a1. 系统给出具体的提示信息，并阻止参与者完成体检单/* 包括可选分支（用户的不同选择）、异常情况。子事件流对事件流中多次重复的部分进行概括，以便复用，通常会对其进行命名。事件流描述原则：1. 简单语法，主语明确2. 乒乓球原则3. 指出参与者的动作及系统的响应，重点在于展示意图而非动作4. 不要过多实现细节（原因：细节是动作而非意图，细节易变，易变则不易维护）5. 过于冗长6. 将分支纠结于主线索*/l 异常事件流3a. 系统保存或打印失败3a1. 系统仍然显示信息录入界面，并提示失败原因3b. 用户发现打印失败3b1. 系统已退出信息录入界面，参与者可以切换到历史体检单页面，重新打印已保存的体检单3， 相关需求l 用户原始需求1. 通过输入预约号或姓名可以查询是否预约，如果重名则都显示2. 体检者选择的体检项目如果属于某套餐，应予以提示3. 如果发现打印出的体检单不清晰，系统应支持重新打印4. l 相关功能点1. 体检单打印时使用Excel作为模板，模板文件可管理2. 体检者选出多个体检项目时，系统给出套餐建议3. 4， 用户界面原型l 窗口概述l 界面流转示意图l 界面细节5， 规则与约束类型编号描述行为规则/功能规则/业务规则UC_KD_01在一张体检单中，所选的体检项目不能属于已选的体检套餐有宏观、微观性能约束UC_KD_02查询预约用户时必须在3S内返回结构规则/数据规则一条短信不能超过70个汉字(140个英文字符)大部分微观界面规则界面中要以不同颜色区分不同等级的警告绝大多数微观5 补充规约5.1 设计约束5.1.1 技术选择的限制条件5.1.2 运行环境 建议用部署图表示5.1.3 预期的使用环境5.2 质量属性本部分建议直接分解成需要开发的技术功能点5.2.1 安全性要求5.2.1.1 访问安全性要求5.2.1.2 数据安全性要求5.2.1.3 通信安全性要求5.2.1.4 其他安全性要求5.2.2 可靠性要求5.2.2.1 容错性要求5.2.2.2 可恢复性要求5.2.2.3 其他可靠性要求5.2.3 易用性要求5.2.3.1 界面友好性要求5.2.3.2 易操作性要求5.2.3.3 其他易用性要求5.2.4 性能要求5.2.4.1 数据访问性能要求5.2.4.2 数据传输性能要求5.2.4.3 其他性能要求5.2.5 可维护性要求5.2.5.1 公共数据要求5.2.5.2 公共框架开发要求5.2.5.3 公共程序库开发要求5.2.5.4 其他可维护性要求5.2.6 可移植性要求5.2.6.1 适应性要求5.2.6.2 易安装性要求5.2.6.3 其他可移植性要求5.2.7 其他质量属性要求5.3 其他需求5.3.1 培训需求5.3.2 后勤需求5.3.3 包装需求