软件需求实践(一)知识讲稿.pptVIP

需求获取技术 阅读背景资料 头脑风暴 讨论分析 文档考古 面谈（用户访谈） 联合开发 用户调查 需求剥离 现场观摩 情节串联板 用例和场景 编写规约 “正规”的开发组织都重视，但常“重视过度”? 束之高阁 ? 事后补文档 规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同 需求验证 这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的 提高需求质量的重要手段： 需求评审 需求确认 通过原型来验证需求 Review是手段，暴露尽可能多的错误是目标 需求开发与需求管理的分界 需求管理 vs. 项目管理 需求管理的主题是“需求项”，关乎优先级、尽力满足；项目管理的主题是“项目” ，关乎成本、进度 需求管理是项目管理的支撑? WBS? 优先级? 基线 需求管理管理的是项目中的价值维 需求管理是项目管理的子集 现代需求理论的关键思想 Work Down ? Value Add 基于系统结构的纵向视角 ?基于使用场景的横向视角 瀑布模型 ? 迭代、增量 RUP的核心思想：用例驱动，架构为中心，迭代、增量的开发过程 XP、FDD：迭代、增量的开发过程，用户故事/Feature驱动 需求管理的主要活动 基线：救火队?严谨团队 变更：不是避免，而是控制。通过统一渠道、统一平台（并分类）做到避免错误产生的变更、减少变化产生的变更 跟踪：高阶活动，包括用户需求?软件需求，软件需求?软件需求、软件需求?设计原则的跟踪 版本控制：历史变化的管理与跟踪 状态管理：管理过程中的动作 需求与需求工程 需求分析 所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明 分析方法：数据结构+算法=程序、结构化分析法、面向对象分析法 任何分析法，均需描述以下几个方面: 问题域的结构 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果 需求分析--内容与形式 需求分析与建模不应该是孤立的行为 ，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题 团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法 对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化 ，“直到你一定要用时，再写文档” 对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化 信息系统的基本类型 信息系统需求的本质 1 流程电子化--业务事件为中心 利用信息化系统改进、固化流程 事务处理系统尤其明显 工作流定义、流程改进、再造 工作流模型 数据信息化--Report为中心 业务术语，业务实体 需要留存哪些数据？谁需要共享？ 需要什么报表？有哪些数据分析规则？ OLTP的需求线索：业务事件 目标：流程电子化 传统问题1：过早考虑程序结构 OLTP的需求线索：业务事件 传统问题2：流程太零散? 流程是分层的：把握管理视野? 流程基本分类：生产类、管理类、支撑类 业务事件是流程的触发点 BPR 、BPD？ MIS的需求线索：Report 何时开始梳理此类需求？ 实施要点： 类别 要点 说明 Why 目的 从管理场景出发，借助对管理控制点的理解来理解报表的目的 使用部门/职位 了解报表的使用者，以便有针对性地调研 相关场景 诸如用户数量、查询频率等非功能性场景描述 What 关联实体 以类图或E-R图表示，说明数据的来源 关键指标及计算规则 细化推导出关联的字段，以及派生属性的计算方法，指导报表数据视图的实现 How 展现形式 以虚拟窗口等形式说明最终的呈现方式 输入输出需要 说明是否打印，以什么格式提供等其他信息 报表的常见分类 志成培训 需求分析师培训 第一课 需求与需求工程 需求是什么? 业务需求就是系统目标 业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求 。 现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。 目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（教堂与小屋） 目标通常就是业务需求！ 用户需求 用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。 用户有不同类型： 管理型、事务型