中国移新动需求分析培训.pptVIP

文档考古：优缺点 优：获取信息相对比较直接，获得系统所有输入、输出及内部文档（但不应假定已获得全部描述）；有助于数据模型分析。 缺：文档说明的系统与实际系统可能是不匹配的；文档考古的传统分析方式（如开发文档流图）可能导致产生现有系统的结构模型，从而带入新系统 现场观摩 现场观摩是最生动的技术 利：百闻不如一见，能够对需求与业务流程建立直观的认识。 弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。 适用性：要对于复杂流程更加深入的理解时。 要点：悄悄地进行，明确要强化理解的具体流程环节。 现场观摩 任务示范：要求用户示范如何执行特定的任务 利：可用于发现异常的、关键性的任务 弊： “示范”失真、耗时 做学徒：和用户坐在一起，通过观察、问问题、并在用户指导下完成一些工作来学习 适用性：用户无法详细解释清楚他们在做什么时 “人们正在做一件事时，最能解释他们在做什么，为什么要这么做” 需求分析员可以通过学徒关系试验他的需求和设计思想 需求分析 所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明 分析方法：结构化分析法、面向对象分析法、面向问题域分析法 任何分析法，均需描述以下几个方面: 问题域的结构 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果 需求分析的方法－结构化 vs. 面向对象 结构化分解? 符合人的心智模型? 适用于宏观层面? DFD、E/R、DD 面向对象? 符合事物客观规律? 适用于微观层面? UML(用例模型、类模型、活动图) 需求分析－何时进行 应该在“业务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后 交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研的计划、问题、素材 需求分析－何时结束 需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的 每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下： 从本质到边缘：本质、重要、次重要、一般、镶金 细化阶段是需求开发最密集的阶段  构建阶段需求开发逐渐减少 编写规约 规格说明书是对需求分析结果的文档化过程 比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新，这是一个需求崩溃的信号 规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同 定义统一的格式是一个很重要的工作 规约内容的严谨、正确、无岐义是很重要的 需求验证 这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的 提高需求质量的重要手段： 需求评审 需求确认 通过原型来验证需求 案例－ BOSS1.5资源管理 需求调研 初步沟通/问卷调查 赴地市调研 文档编写 编写并细化需求文档（编写中不断征求业务部门/地市的反馈意见） 与业务部 门反馈 汇报设计原则与模型 介绍资源管理基本流程 业务目标 制定完整的可涵盖所有资源并与实际操作流程相符的订单流程 提供准确的实时库存信息，达到稽核、盘点的管理要求 需求验证 召集各地市业务人员开会评审资源管理业务功能、业务流程 根据评审意见调整修改 业务功能需求模板 模板内容 业务描述 业务原则 2.1适用范围 2.2前提条件 2.3 业务互斥 2.4开通限制功能 。。。 3 业务管理 3.1业务流程 3.2业务受理 3.3 票据说明 3.4 相关业务 。。。 模板内容 计费处理 帐务处理 资费原则 6.1 营业资费 6.2 帐务资费 6.3 计费原则 优惠说明 7.1 营业优惠 7.2 帐务优惠 结算 报表统计 外系统接口 其它 注意事项－业务原则 业务开放的地市、 开放的用户类型、 开放的品牌、产品 业务的前提条件 业务的依赖、互斥规定 开通、限制的功能 注意事项－业务管理 业务流程：涉及功能多，涉及的角色多，涉及的交互步骤多， 画出流程图说明 业务受理： 受理的步骤、 界面要素、 功能按钮、业务校验规则、短信的通知内容、菜单位置、 开放角色权限、开放的