软件需求实践(一).pptVIP

需求获取技术 阅读背景资料 头脑风暴 讨论分析 文档考古 面谈（用户访谈） 联合开发 用户调查 需求剥离 现场观摩 情节串联板 用例和场景 编写规约 “正规”的开发组织都重视，但常“重视过度”? 束之高阁 ? 事后补文档 规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同 需求验证 这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的 提高需求质量的重要手段： 需求评审 需求确认 通过原型来验证需求 Review是手段，暴露尽可能多的错误是目标 需求开发与需求管理的分界 需求管理 vs. 项目管理 需求管理的主题是“需求项”，关乎优先级、尽力满足；项目管理的主题是“项目” ，关乎成本、进度 需求管理是项目管理的支撑? WBS? 优先级? 基线 需求管理管理的是项目中的价值维 需求管理是项目管理的子集 现代需求理论的关键思想 Work Down ? Value Add 基于系统结构的纵向视角 ?基于使用场景的横向视角 瀑布模型 ? 迭代、增量 RUP的核心思想：用例驱动，架构为中心，迭代、增量的开发过程 XP、FDD：迭代、增量的开发过程，用户故事/Feature驱动 需求管理的主要活动 基线：救火队?严谨团队 变更：不是避免，而是控制。通过统一渠道、统一平台（并分类）做到避免错误产生的变更、减少变化产生的变更 跟踪：高阶活动，包括用户需求?软件需求，软件需求?软件需求、软件需求?设计原则的跟踪 版本控制：历史变化的管理与跟踪 状态管理：管理过程中的动作 需求与需求工程 需求分析 所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明 分析方法：数据结构+算法=程序、结构化分析法、面向对象分析法 任何分析法，均需描述以下几个方面: 问题域的结构 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果 需求分析--内容与形式 需求分析与建模不应该是孤立的行为 ，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题 团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法 对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化 ，“直到你一定要用时，再写文档” 对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化 信息系统的基本类型 信息系统需求的本质 1 流程电子化--业务事件为中心 利用信息化系统改进、固化流程 事务处理系统尤其明显 工作流定义、流程改进、再造 工作流模型 数据信息化--Report为中心 业务术语，业务实体 需要留存哪些数据？谁需要共享？ 需要什么报表？有哪些数据分析规则？ OLTP的需求线索：业务事件 目标：流程电子化 传统问题1：过早考虑程序结构 OLTP的需求线索：业务事件 传统问题2：流程太零散? 流程是分层的：把握管理视野? 流程基本分类：生产类、管理类、支撑类 业务事件是流程的触发点 BPR 、BPD？ MIS的需求线索：Report 何时开始梳理此类需求？ 实施要点： 报表的常见分类 信息系统需求的本质 2 个人知识转换为企业知识--模型为中心 将知识工作的经验转换成模型 业务场景的分析与抽象是重点 提高速度、提高质量 信息决策化--决策模型为中心 业务场景的分析与抽象是重点 将非程序化问题分解 成多个子问题 提出所需的数据模型、经验模型 不同视角下的信息系统 需求大纲--SERU模型 Subject：主题域，将一个复杂的大系统分解成由确定接口相互连接的多个子系统—构件图 /System?（上下文关系图、事件列表、Report列表）/Subject Event：业务事件，信息系统行为主线条—（业务流程图、领域类图[E/R图]、用例图[opt]）/Event Report：查询、分析、统计等管理动作—（目的、数据、虚拟屏幕） /Report Use case：需求管理的分子！ SERU模型 需求复用—流程级 需求复用—流程内 需求与需求工程 需求分析师 需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道 典型活动：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求 必备技能：倾听、交谈和提问的技