3收集需求【荐】.pptVIP

* 面向对象分析与设计 需求收集 * 项目分析过程 * 收集需求 软件开发的第一步是收集用户的需求 不知道做什么，就不可能成功构建一个系统 用例建模 用户界面原型建模 补充规格说明 * 需求的重要性 有关软件错误的一些事实 在软件生命周期中，一个错误发现得越晚，修复的费用也越高 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 在需求阶段，代表性的错误为疏忽，不一致和二义行 需求错误是可以被检查出来的 * The Cost of Change * 软件开发失败的原因 来源：Standish Group 1995 （Standish公司对350家公司的8000个软件项目作过一次调查。31%的项目的结局是被取消。 其中，与产品需求有关的（1,2,4,和6项）占了44.1%，突出地显示了软件产品需求在软件开发中的重要性。 ） * UP的初始阶段 初始阶段是 建立项目共同愿景和基本范围的比较简短的起始步骤 创建的制品 愿景：高阶目标与约束 业务案例 。。。。。。P38 主要以文字方式表达 UP提倡演化式需求捕获 寻找、沟通和记录什么是真正需要的 * 瀑布式定义的需求实际使用情况P42 试图完全定义和固化需求 * 讨论： 什么是需求？ 需求就是系统必须提供的功能和必须遵从的条件 * 下列哪些是项目需/求? 要设计一台新式的ATM（自动柜员机）系统，收集到下列信息： ATM系统应该验证插入的ATM卡的有效性 ATM系统应该验证客户输入的个人身份号（PIN）的有效性 ATM系统应该对于任何ATM卡在任意24小时时间内取款不超过3000 ATM系统应该采用C++编写 ATM系统与银行通信应该采用256位加密 ATM系统应该在3秒钟内验证ATM卡 当ATM机器空闲时，显示屏显示一条问候语 * 需求的类型和种类 FURPS+模型 功能性Functional 可用性Usability 可靠性Reliability 性能Performance 可支持性Supportability “+”指一些辅助性的和次要的因素 实现：资源限制、语言和工具、硬件等 接口： etc. * 需求工作的主要任务 对需求按功能性和非功能性划分 找出功能性需求（F） 找出非功能性需求（URPS+） 对需求进行排序，确定优先完成的需求 * 需求组织模式 用例模型： 一组使用系统的典型场景。（功能需求） 补充规格说明： 用例之外的所有内容。主要用于非功能需求 词汇表： 最简单的形式定义重要的术语。同时也包含了数据字典 愿景： 概括了高阶需求 业务规则： 凌驾于项目的需求或政策。如税收法规 * 系统愿景（Vision） 是总览性的简短文档，项目最高等级文档。 描述对项目的共同愿景。（老大的愿望） 涉众的关键高阶目标： 提示了重要的非功能和质量目标 系统功能特性概要 对功能性进行概括 描述功能特性的准则 特性层次不超过两级 特性最好少于10个 P82 * 词汇表（Glossary） 重要术语及期定义的列表 统一不同涉众的对同一事物的术语 以数据字典方式记录词汇 别名 描述 格式（类型、长度、单位） 与其他元素的关系 值域 验证规则 P87 * 需求组织不但需要图还需要文档 * 需求获取的困难 业务知识的缺乏 误解 交流障碍 缺乏共同语言 完整性问题 需求永远不会稳定 用户意见不统一 错误的需求 认识混淆 * 如何进行：基本需求收集技术 核心：与用户一同收集需求 召集相关人员，组建需求建模团队 涉及人员： 需求者： 直接用户和客户/出资者 受系统运行影响的人 系统分析员：分析阶段活动的主体 开发者：包括设计，编程和项目管理者组成 收集策略 会谈 集体讨论 * 讨论的可能主题： 系统为谁设计 他们将用系统做什么工作 这一系统支持什么业务 业务会如何变化 我们从何开始，如何开始 系统将怎样影响人们的工作？为别人提供那些帮助 如何做的更快 …… * * 这些数据突出地显示了软件产品需求在软件开发中的重要性。 * 这些数据突出地显示了软件产品需求在软件开发中的重要性。