软件需求讲义-第一部分(1.2)重点解析.ppt

软件需求 从谚语开始 中国有句谚语：“好的开始就等于成功的一半” 西方的谚语是：“Garbage in, garbage out！” 沟通为什么总有障碍？ 第一章 软件需求的基础知识 需求的定义、层次 需求的开发和管理 糟糕的需求 需求的好处和特点 第一章 软件需求的基础知识 软件需求分析的重要性：40%-60%的项目缺陷都是在需求分析阶段的过失造成！ 涉众是什么，包括了那些人？ 客户，用户，需求分析员，开发人员， 测试人员，文档编写人员，项目经理， 法律人员，生产人员， 市场营销及其他人员。 需求定义 [IEEE 1997] IEEE软件工程标准词汇表定义需求为： 用户解决问题或达到目标所需的条件或能力。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 一种反映上面(1)或(2)所描述的条件或能力的文档说明。 软件开发的目标 软件开发的目标，简单而言，就是满足用户的需要 。 不要一厢情愿的以为项目的涉众对需求的理解是一致的。 需求的层次 需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。 软件需求包括不同的层次 业务需求 内容：表示组织或客户对系统、产品高层次的目标 来源：投资人、购买产品的客户、市场营销部门、产品策划部门、实际使用者的管理者 描述方式：前景（视图）和范围文档 示例：为了让南海校区的同学和老师提供订餐便利，节约排队打饭时间，同时减少食堂的浪费，需要开发“南海校区网上订餐系统”。 用户需求 内容：描述了用户要求系统、产品必须能完成的任务 来源：实际使用系统的所有潜在用户 描述方式：用例模型 示例：“订餐”、“变更订单”、“查看菜单”、“支付订单”。 术语：系统需求 内容：包含多个子系统的产品（即系统）的顶级需求。纯软件产品只包含软件子系统，否则包含既软件又包含硬件子系统 示例： 系统需求：系统能控制实验室设备给整排烧杯加入精确数量的化学药品（即把这项乏味的工作自动化） 软件的功能需求：向硬件发送“移动加药喷头”的信号；读取定位传感器；向硬件发送“开泵”的信号；向硬件发送“关泵”的信号； 功能需求 内容：规定开发人员必须在系统、产品中实现的软件功能 来源：实际使用者、开发人员 描述方式：软件需求规格说明书（SRS） 示例：“订餐”、“创建浏览修改和删除订餐”、“订餐支付”、“请求送餐”等等 需求的开发与管理 需求管理 所有的项目都有需求 未真正明白这些问题就开始编码，结果没有人对产品满意 。 在项目开发中，所有的涉众（Stakeholder）都对需求分析阶段备感兴趣。（没有理所当然的需求） 优秀的团队遇到糟糕的需求 需求是软件项目成败的关键所在 越早发现需求错误，越早改正它，其代价越小（P12 图1.4） 几种常见的需求风险：用户参与不足，用户需求扩展，有歧义的需求，镀金问题，过于抽象的需求，忽略了某类用户，不准确的计划。 软件开发中的错误观点 只要掌握了1-2门程序设计语言，进行软件开发就没有问题。 只要有最好的开发工具、最好的计算机，一定能做出优秀的软件。 软件需求分析很困难，不管三七二十一，先把软件做了再说，反正软件是灵活的，随时可以修改。 总之，错误认为：软件就是程序，开发软件就是编写程序。 项目失败与成功的原因 三种最经常使项目“遇到困难”的因素是： 缺乏用户介入：占所有项目的13% 不完整的需求和规格说明：占所有项目的12% 不断改变的需求和规格说明：占所有项目的12% 三种项目最主要的“成功因素”是： 用户介入：占所有成功项目的16% 高层管理的支持：占所有成功项目的14% 需求陈述清晰：占所有成功项目的12% 高质量的需求过程带来的好处 在开发后期和整个维护阶段的重做的工作大大减少了 。 让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响 。 将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量 。 需求缺陷造成的成本增加 重新进行需求规格说明 重新设计 重新编码 重新测试 改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版本。 纠正活动——消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。 报废——包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。 糟糕的需求和优秀的需