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

资源描述

TR软件需求规格说明书 24 2020年4月19日文档仅供参考软件需求规格说明书 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网络就能够完成和城市运营中心总部（包括财务、物资、客服中心等部门）之间的信息交互。

展开阅读全文