体检医院管理系统需求规格说明书_模板及答案.doc

文档修改记录 版本号 主要作者 修改记录 完成日期 //文档修改记录，用于记录本版本、以及以前版本的变更情况，概要性的说明版本之间的内容差异，使读者能够快速、便捷地查看本版本的焦点内容。  目录 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 1 文档概述 //文档概述，作为文档的第一部分，对整个软件需求说明书文档进行概要性的说明，帮助读者快速了解文档目的、编写约定、阅读方式以及软件产品。 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） 业务事件类型 （3） 业务事件标识：主动触发并能发生一系列后续行为，触发系统行为；不是系统事件（数据备份、更改密码） 3.2.2 业务事件 3.2.2.1 业务事件1 [包括流程分析、领域类分析、用例分析] 3.2.3 报表 3.2.3.1 Report 1 [用领域类图片段表示涉及数据，用用例标识具体的报表项] 4 具体需求 4.1 主题域1 4.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 主题域1 4.2.1 用例模型 4.2.1.1 开单（UC_B_TJ_KaiDan） 1， 概述 ? 用例名称：开单 ? 编号：UC_B_TJ_KaiDan ? 参与者：服务人员 ? 用例概述：服务人员根据体检者的选择或预约单开具体检单，并打印出来交给体检者 ? 相关stakeholder： Stakeholder 利益点 体检者 1） 办理速度要快，避免排长队 2） 无需记录无意义的预约号 收费人员 可直接调出体检单生成账单 2， 事件流 ? 前置条件：无 //* 用例启动前系统能检测到的、有意义的、参与者的状态。 1. 客户已发