TR软件需求规格说明指导书.doc

软件需求规格说明书
1. 文档概述
【本章节内容应该在整个需求规格基础写完后，再进行总修订。】
1.1 编写目标
【说明本需求规格说明书预期读者对象，和每类读者对象应该关键阅读章节。】
本需求规格说明书预期读者对象包含各类用户代表、开发团体中各类参与者，用来对项目包含业务知识和系统开发所需处理问题、满足需求达成共识。各类读者对象应该关键阅读章节以下表所表示：
用户类别
用户代表
关键章节
说明
高层用户
院长、副院长
第2小节
对系统总体目标进行确定
第3小节
经过目录对大致范围进行确定
中层用户
客服中心经理
3.1小节
对相关步骤、数据、管理控制点进行确定
4.1小节
经过目录对包含关键场景进行确定
服务中心、综合科、体检科室经理
3.2小节
对相关步骤、数据、管理控制点进行确定
4.2小节
经过目录对包含关键场景进行确定
物资供给中心经理
3.3小节
对相关步骤、数据、管理控制点进行确定

经过目录对包含关键场景进行确定
技术用户
信息中心
第2小节
对系统相关事实、假定、目标、范围进行确定
第5小节
对非功效性需求、设计约束进行确定
操作层
（略）

开发团体
（略）

1.2 背景
【说明和此次项目开发相关关键事实和关键假定。】
1.3 定义
【列出本文档中关键缩写词和专业术语，方便读者能够愈加好地阅读本文档。】
1.4 参考资料
【列出阅读本文档时需要延伸阅读参考资料，每个参考资料应该写明：名称、起源、引用目标、关键信息摘录。】
2. 任务概述
【本章节关键针对高层读者，通常在需求一阶段完成。】
2.1 项目目标
【本章节定义项目目标，也就是成功标准。对于每条目标能够使用一个小节，用《问题卡片》描述，还能够对每个问题深入分析说明。对于每张问题卡片最好编号跟踪。】
2.1.1 避免预约安排撞单现象
问题
机会
编号

描述
在手工操作下，因为信息没有有效共享，所以常常会出现预约安排撞单现象，也就是在将多个团体用户安排在同一天、同一个门店进行体检
范围和限制
团体用户

问题影响了谁
1） 团体用户
2） 客服中心
3） 体检门店
产生什么后果
1） 团体用户：排队时间变长，满意度下降
2） 客服部门：应对投诉，用户满意度下降后销售更难
3） 体检门店：出现超负荷工作量
处理方案关键点
经过共享各个体检门店最大负荷量、当初预约安排量，来避免撞单发生概率。

2.1.2 经过系统实现体检业务步骤标准化

问题
机会
编号

描述
目前步骤采取全手工状态，无法确保每个岗位全部按标准化步骤实施，现在只能靠有经验门店经理来帮助处理；而未来伴随企业扩张，使多个门店实施相同标准化步骤变得十分困难。
范围和限制
体检业务相关步骤（门店范围内），覆盖未来自营、加盟门店

问题影响了谁
1）体检门店

产生什么后果
步骤不标准，造成服务无法标准化，降低用户体验，增加了管理成本。

处理方案关键点
经过系统固化步骤，实现步骤标准化。

2.1.3 避免物资供给脱节
问题是
物资供给脱节
影响
体检科室、物资供给中心，体检用户
问题后果
因物资短缺而造成一些体检无法正常进行，或无法立即得出体检结果，造成体检用户满意度下降
成功处理方案
经过安全库存（依据物资消耗速度和采购周期确定）管理策略，确保避免物资供给脱节现象出现

2.2干系人分析
【先使用《干系人列表》整理出项目标全部干系人，再使用《干系人档案》对每个干系人进行具体描述，而且需要对干系人关键关注点进行编号跟踪。】
类别
名称
说明
相关度
影响度
出资人
院长

项目提出人
高
(中)
高
使用人
门店经理

是确保经过系统实现体检业务步骤标准化关键岗位
高
(中)
高
(低)
使用人
客服中心经理

高
中

使用人
物资中心经理

高
中
评价者
团体用户

低
中
评价者

VIP用户

低
中
评价者

散户

低
低
使用人

体检科室

低
低
使用人

财务部经理

低
中
2.2.1 客服中心经理
名称
客服中心经理
类别
使用人
相关度
高
影响度
中
代表
XXXXX（具体人姓名、职位）
联络方法
XXXXX（这个具体人名字）
职责
起源于对方岗位职责

核
心
关
注
点
编号
内 容
关键度

避免多个销售打搅同个用户。

避免预约安排出现撞单。

给销售提供足够话术支持。

立即提醒销售人员向团体用户反馈体检结果，做好服务。

备注

2.3项目约束
【对本项目标进度、预算、资源等方面约束进行描述。】
3. 业务分析
【本章节关键针对中层读者，高层读者阅读目录，中层读者选择相关业务进行阅读。本章节目录将在需求第一阶段完成，内容将在需求第二阶段完成。】
3.1概述
【本章节使用《业务子系统描述》，讲清业务子系统划分、它们之间接口，对业务进行总体说明。】

图例：

业务子系统
服务接口
提供服务
(图中为实心直线)
使用服务

专题域说明
专题域名称
类型
说明
客服管理子系统
新增
为客服中心提供预约、销售管理等日常工作支持，避免撞单出现
体检业务子系统
新增
对体检门店体检业务步骤进行标准化，以利于未来企业扩张
物资管理子系统
新增

财务子系统
提议外购

服务接口说明
服务接口名称
提供者
使用者
说明
获取预约单
客服
体检
对预约用户，依据预约单生成体检单

3.2 体检业务子系统
【每个子系统分为事件/步骤、管控点两个部分描述。】
3.2.1 业务步骤分析
【首先用《事件(步骤)列表》概述，然后分章节描述每个事件/步骤，对每个事件/步骤进行步骤分析、领域建模、用户场景分析（生成用例）】
专题域
事件名称
简明说明
优先级
用户代表
体检业务子系统
体检步骤
体检者从申请体检到获取体检结果结束全过程
关键

改单步骤
体检者在中途发觉需要修改体检内容应对处理过程
关键

补打汇报步骤

通常

投诉步骤

通常

3.2.1.1 体检步骤
（1）业务步骤分析
【使用《业务步骤描述表》来对步骤进行具体说明。】

步骤相关文档/表单
文档/表单名称
步骤步骤
说明(包含取得方法)
体检单
开单
描述用户选择体检项目（可从服务中心取得）

步骤相关规则
类型
规则描述
备注
行为
在体检科室，只对盖章体检单进行体检

改变可能/关键例外
对于团体用户，我们提议另外开设一个窗口，为用户提供批量开单工作，让团体用户派一个位代表领取全部些人体检单。

（2）业务数据分析
【使用《领域类片段》来对该步骤包含到业务数据之间关系进行说明。】

（3）业务场景分析
【使用《用例图片段》来对该步骤包含到角色、关键场景进行说明。】

图例：

用户饰演角色
系统支持业务活动
角色指向活动：能实施
活动指向角色：通知/调用
右角色能实施左角色可实施全部活动

角色—最终用户映射表
角色
最终用户
服务人员

收费人员

体检医生

综合医生

用例简述
类型
用例名称
用例简述
优先级

开单

关键

收费

关键

统计体检结果

关键

出具汇报

关键

返回汇报

有用

3.2.1.2 改单步骤
（1）业务步骤分析
【使用《业务步骤描述表》来对步骤进行具体说明。】
（2）业务数据分析
【使用《领域类片段》来对该步骤包含到业务数据之间关系进行说明。】
（3）业务场景分析
【使用《用例图片段》来对该步骤包含到角色、关键场景进行说明。】

3.2.2 管控点分析
【首先用《管控点列表》概述，然后分章节描述每个管控点，将其细化为具体报表需求，数据挖掘需求等。】
4. 具体需求
【这个部分关键针对操作层读者，在需求二阶段完成目录，需求三阶段填充内容。】
4.1 xx子系统
【这个部分也将分不一样子系统进行描述。】
4.1.1 用例模型
【这个部分先使用一个子系统用例模型来概述，该模型源于这个业务子系统各个步骤用例图片段整合（在整合时能够将报表也整合到这个用例模型中。）】

4.1.1.1 服务人员
【这个部分按不一样用户角色来分章节，用户角色源于用例图。然后将每个角色每个用例进行具体描述。】
1、 开单（UC_B_TJ_KaiDan）
1、概述
n 用例名称：开单
n 编号：UC_B_TJ_KaiDan
n 参与者：服务人员
n 用例概述：服务人员依据体检者选择或预约单开具体检单，并打印出来交给体检者。
n 相关Stakholder：
Stakeholder
利益点
体检者
1） 办理速度要快，避免排长队
2） 无需统计无意义预约号
收费人员
1）可直接调出体检单生成帐单
2、事件流
n 前置条件：无
n 后置条件：确保没有反复体检项目
n 基础事件流：
1. 参与者输入用户姓名或预约号，系统确定用户已经预约，并从预约单中获取体检套餐和体检项目显出在屏幕上；
2. 系统确定用户选择体检套餐和体检项目符合要求（参见规则UC_KD_01）；
3. 系统保留并打印体检单。
n 备选（扩展）事件流：
1a. 参与者或系统确定用户没有预约
1a1. 参与者输入用户基础信息，并依据用户选择输入体检餐套和体检项
目信息；
1b. 系统发觉有多个可能重名预约用户
1b1. 系统显示出全部可能重名预约用户，并显示区分身份关键信息；
1b2. 参与者从中选择符合预约用户，并从对应预约单中调出数据。
2a. 用户选择体检套餐不符合要求
2a1. 系统给出具体提醒信息，而且阻止参与者完成体检单
n 异常事件流：
3a. 系统保留或打印失败
3a1. 系统仍然显示信息录入界面，并提醒失败原因
3b. 用户发觉打印失败
3b1. 系统已退出信息录入界面，参与者可切换到历史体检单界面，重新
打印已保留体检单
3、相关需求
n 用户原始需求：
l 经过输入预约号或姓名可查询是否预约，假如有重名则应该全部显示；
l 体检者选择体检项目若属于已选择体检套餐，则应提醒并说明对应套餐；
l 假如发觉打印出来体检单不清楚，系统能够支持重新打印功效。
l ……
n 相关功效点：
l 体检单打印时使用Excel做为模板，模板文件可管理。
l 当体检者选择出多个体检项目时，系统能够自动给出体检套餐提议。
l ……
4、用户界面原型
n 窗口概述：
l 历史体检单页面：显示已生成历史体检单信息，在开单工作开始之前将在该页面中（该页面同时是“返回汇报”用例基础，选中历史体检单，点击打印汇报……）。
l 预约判定界面：用来输入预约信息，实现预约单选择和调取。
l 体检单生成界面：用来录入和验证体检单信息。
l 打印页面：提供打印预览窗口。
l 失败提醒页面：可能包含多个，显示错误信息，帮助用户提供操作。
n 界面流转示意图：

图x界面流转示意图
n 界面细节：

图x“预约判定界面”示意图
5、规则和约束
类型
编号
描述
行为规则
UC_KD_01
在一张体检单中，所选体检项目不能属于已选体检套餐
性能约束
UC_KD_02
查询预约用户时，必需在3秒内返回
……
……
……
4.1.1.2 收费人员

1、 收费（UC_B_TJ_KaiDan）

基础信息
任务
收费0
目标
没交钱，收钱盖章；交过钱，直接盖章。1
系统触发
已开单（前置条件）2
业务前提

频率
6个收费，一次上班2个；200笔/天；节假日、周末，+30-50%；上班1个半小时；
关键例外
一个人交多个人钱
任务和问题
处理方案
子任务

提供查询是否已交钱（姓名，电话，企业）

我们提供一个自己计算功效（材料费收费、体检费标准 ）

可配置折扣表

提醒
1、 确定没交钱
1） 太难找
2） 交费信息更新不立即
2、 计算费用
1）材料费不是反复收
3、 收钱盖章

任务变体
1a、已交钱：直接盖章
2a、折扣计算
1） 不一样VIP等级，折扣不一样
2） 不一样套餐组合，折扣也不一样
3） 折扣要求还常常改变
2b、VIP积分抵扣
1） 提醒她积分快过期
2） 算新积分

4.1.2 领域模型
【这个部分先使用一个子系统领域模型来概述，该模型源于这个业务子系统各个步骤领域类图片段整合。】
4.1.2.1 预约单（BO_YYD）
【逐一对业务数据组成进行说明。】
n 类名称：预约单
n 别名：预约信息
n 包含专题域：
1) 客服管理子系统：体检者预约事件
2) 体检业务管理子系统：体检者申请体检事件
n 数据窗口分析：

图x“预约单”数据窗口分析
n 数字组成和格式：
l 体检者ID：指向体检者实体，预约单中不保留其具体信息；其格式参见领域类“体检者”。
l 销售人员ID：指向完成该预约工作销售人员，预约单中不保留其具体信息；其格式参见领域类“销售人员”。
l 预约时间：Data格式，统计用户可能到医院体检时间（具体哪一天）。
l 预约项目：统计预约者选择体检套餐和体检项目，在此以子表形式统计体检套餐和体检项目标编号；其编号规则参见领域类“体检套餐”和“体检项目”。
……

4.X 子系统间接口需求
【这个部分对各个子系统间接口进行具体描述。】
4.X.1 查询体检情况（UC_I_TJ_QTJ）
n 使用者
名称
业务目标
时机
频率
客服管理子系统
查询特定VIP用户或企业/团体用户体检汇报生成情况
1） 用户电话问询客服人员时
2） 客服人员估计体检汇报已经成时
每个VIP用户、企业/团体用户全部可能引发数次(10次以内)查询
VIP用户、企业/团体用户体检次数大约是每个月500笔
n 内容和格式：
l 交互过程：

l 数据包说明：
数据包
内容描述
用户信息
用户信息=用户标识+体检时间
用户标识=[VIP用户编号|企业/团体编号]
体检时间=yyyy/mm/dd
体检情况概述
体检情况概述=状态+总人数+未完成数
状态=[已生成|未生成]
获取详情
指令，无格式要求
体检进度详情
体检进度详情= {每体检人体检情况}n VIP用户只有一条
每体检人体检情况=每体检人状态+{体检项情况}
每体检人状态=[体检结果未完全生成|体检汇报未生成]
体检项情况={体检项名称+体检项状态}n 每体检项一条
体检项状态=[已生成|未生成]
n 设计约束：
l 协议格式要求：无
l 性能要求：在接听用户电话时能够快速查出
l 环境限制：用户服务管理子系统和体检业务子系统之间将经过广域网联接，ADSL带宽受限

5. 补充规约
5.1 全局质量属性
【这个部分对系统中最关键质量属性进行归纳，并使用一系列《非功效场景》来进行描述。】
5.1.1 可靠性
目标
场景
决议
访问安全性
系统暴露在公网，轻易被人经过暴力破解方法来攻击用户帐户
在登录时，需要让用户提供验证码
（降低了易用性）
安全性
因为体检业务系统直接面对体检用户，当系统瓦解，会造成服务中止，使得用户无效排队时间增加，满意度下降，

可移植性
门店会接待外籍用户，未来会拓展到国外门店

5.1.3 可扩展性

5.1.4 易用性

5.1.5 安全性

5.2 设计约束
【这个部分对系统开发、布署环境，技术选型等方面设计约束进行描述。】
1)系统将以城市运行体布署，未来可能将整套系统复制到其它城市。
2)各体检门店经过ADSL网络就能够完成和城市运行中心总部（包含财务、物资、客服中心等部门）之间信息交互。