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网络就能够完成和城市运行中心总部（包含财务、物资、客服中心等部门）之间信息交互。