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

文档修改记录 版本号 主要作者 修改记录 完成日期 //文档修改记录，用于记录本版本、以及以前版本的变更情况，概要性的说明版本之间的内容差异，使读者能够快速、便捷地查看本版本的焦点内容。  目录 1 文档概述 2 1.1 目的 2 1.2 背景 2 1.3 定义 2 1.4 参考资料 2 2 任务概述 2 2.1 业务需求 2 2.2 Stakeholder利益分析（略） 2 2.3 用户特点分析 2 2.4 相关事实与假定 2 3 需求概述 2 3.1 系统概述[主题域划分，用构件图表述] 2 3.2 主题域 1 2 3.2.1 功能需求概述 2 3.2.2 业务事件 2 3.2.3 报表 2 4 具体需求 2 4.1 主题域1 2 4.1.1 用例模型 2 4.1.2 领域模型 2 5 补充规约 2 5.1 设计约束 2 5.1.1 技术选择的限制条件 2 5.1.2 运行环境 2 5.1.3 预期的使用环境 2 5.2 质量属性 2 5.2.1 安全性要求 2 5.2.2 可靠性要求 2 5.2.3 易用性要求 2 5.2.4 性能要求 2 5.2.5 可维护性要求 2 5.2.6 可移植性要求 2 5.2.7 其他质量属性要求 2 5.3 其他需求 2 5.3.1 培训需求 2 5.3.2 后勤需求 2 5.3.3 包装需求 2 文档概述概述 目的 //说明文档编写目的，即软件需求说明书的作用以及主要内容。其中要明确说明待修订的软件版本号，以及即将发行的软件版本号。 背景 定义 参考资料 概述业务需求 Stakeholder利益分析（略） 用户特点分析 相关事实与假定 需求概述 系统概述[主题域划分，用构件图表述] 主题域 1 概述 [用上下文关系图表示该主题域的范围] ：外部的这些Customer会发起什么事件这些事件会引发内部的什么工作。都是人 Worker主动发起什么事件 事件分析 类型分析不太理解 这些人对系统有哪些独立的行为 主题较小，可以不用画上下文关系图 建模使用，用户代表沟通时绘制不建议绘制： 独立行为（体检者到各科室进行体检、体检，这些都是申请体检后必然发生的，非有效线索） 事件类型 业务事件标识：主动并能发生一系列后续行为，触发系统行为不是系统事件（备份、更改密码） 业务事件业务事件1 [包括流程分析、领域类分析、用例分析]Report 1 [用领域类图片段表示涉及数据，用用例标识具体的报表项]需求 用例模型UC_B_xx（B类） （1）概述[编号、名称、概述、相关Stakeholder] （2）事件流描述[前、后置条件，基本、扩展、子事件流] （3）相关需求与功能点 （4）界面原型[交互过程与界面详解] （5）规约与约束 UC_R_xx（R类） （1）概述[名称、用户部门与职位、业务意图、相关场景] （2）报表内容[领域类图、数据项] （3）输入/输出格式 （4）其他 UC_I_xx（类） （1）使用者[名称、业务目的、时机、频率] （2）内容与格式[交互过程、数据包说明] （3）设计与实现约束[诸如协议格式要求、性能要求等] 模型XX领域类 （1）概述[类名称、别名] （2）数据窗口分析[涉及主题域、业务事件，各域数据] （3）数据组成与格式 （4）其他 用例模型KaiDan） 概述 名称开单 ：UC_B_TJ_KaiDan ：服务人员 概述：根据的选择或开具体检单并打印出来交给体检者 stakeholder： Stakeholder 利益点 体检者 办理速度要快，排长队 记录的预约号人员直接调出体检单生成账单 前置条件：无 //* 启动前能检测到、有意义的、的状态 客户已发出订单：不合适！系统无法检测 工作人员已登录系统：不合适！显然的条件，意义不大。不要有模板综合征 库存大于订单数：不合适！系统在用例开始前无法检测。 *// 后置条件：确保没有重复的体检项目 前能检测到、有意义的、的状态 前后置条件出现的概率并不高，再写，不要事件流 输入姓名预约号系统确认用户预约，预约单中获取体检套餐和体检项目显示在屏幕上 确认用户选择体检与体检项目符合要求（UC_KD_01）保存并打印体检单 //* happy day大部分时间遇到的用户预期的场景系统核心价值事件流 a. 参与者或系统确认用户没有预约 1输入用户基本信息，根据用户选择输入套餐与体检项目信息 1发现多个可能重名的预约用户 1显示所有重名的预约用户，显示身份的主要信息 1这选择符合预约用户，从相应的预约单中调出数据 2a选择的套餐不符合要求 给出具体的提示信息，并阻止参与者完成体检单 分支（的不同选择） 子事件流——对事件流中多次重