软件需求工程简介

《软件需求工程简介》由会员分享，可在线阅读，更多相关《软件需求工程简介（44页珍藏版）》请在金锄头文库上搜索。

1、1Software Requirements Engineering 软件需求工程 郑州大学软件学院郑州大学软件学院 软件工程专业必修课程软件工程专业必修课程授课对象:本科3年级 授课教师:徐强2关于本课程关于本课程授课对象：计算机科学和软件工程专业的高 年级本科生及研究生。授课学时：每周4学时，共9-10周。课程目的：为工业界培养需求工程师，为学 术界准备从事相关研究的学者。3授课目标：通过这门课达到掌握如下的知识 和技能 了解需求工程在软件工程和系统工程中的重要地 位 了解需求工程的性质 了解和应用需求工程的概念，方法，过程和工具 理解掌握需求开发各阶段的技术 理解掌握需求管理的技术 学习

2、需求工程领域当前最新研究成果和实践关于本课程关于本课程4软件需求工程概述 软件需求过程 需求获取 需求分析 需求规格说明 需求验证 需求管理 需求开发向设计规划的转化课程提纲课程提纲软件需求工程简介了解软件需求开发中使用的一些关键名词。警惕在软件项目中可能出现的与需求相关的 一些问题。知道优秀的需求规格说明应该具有的特点。明白需求开发与需求管理之间的区别。56软件开发的目标软件开发的目标软件开发的目标，简单而言，就是满足用户 的需求。软件需求的定义软件需求的定义软件产业存在的一个问题就是缺乏统一定 义的名词术语来描述我们的工作。 客户所定义的“需求”对开发者似乎是一个 较高层次的产品概念。而开

3、发人员所说的 “需求”对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同 层次是从不同角度与不同程度反映着细节 问题。7软件需求的定义用户所需要的并能触发一个程序或系统开 发工作的说明。 从系统外部能发现系统所具有的满足于用 户的特点、功能、属性等 。 指明必须实现什么样的规格说明。它描述 了系统的行为、特性或属性，是在开发过 程中对系统的约束 。8软件需求的定义IEEE软件工程标准词汇表（1997年）中 定义需求为： 用户解决问题或达到目标所需的条件或权 能（Capability）。系统或系统部件要满足合同、标准、规范 或其它正式规定文档所需具有的条件或权 能。 一种反映上面或

4、所描述的条件或权能 的文档说明。910需求的层次需求的层次 软件需求包括三个不同的层次。 业务需求 用户需求 功能需求 （包括非功能需求 ）11需求的层次需求的层次 业务需求(business requirement) 反映了组织机构或客户对系统、产品高层次的目 标要求，它们在项目视图与范围文档中予以说明 。12需求的层次需求的层次 用户需求(user requirement) 用户需求文档描述了用户使用产品必须要完成的 任务，这在使用实例文档或方案脚本说明中予以 说明。 13需求的层次需求的层次 功能需求(functional requirement) 定义了开发人员必须实现的软件功能，使得

5、用户 能完成他们的任务，从而满足了业务需求。 14需求关系图需求关系图软件需求各组成部分之间的关系15术语的定义术语的定义 软件需求规格说明 （software requirements specification 简称“SRS”） 在软件需求规格说明中说明的功能需求充分描述 了软件系统所应具有的外部行为。 软件需求规格说明在开发、测试、质量保证、项 目管理以及相关项目功能中都起了重要的作用。 16术语的定义术语的定义 非功能需求 作为功能需求的补充，描述了系统展现给用户的 行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约；外部 界面的具体细节；性能要求；设计或实现的约束 条件及质量

6、属性。17术语的定义术语的定义 约束条件 指对开发人员在软件产品设计和构造上所具有的 选择限制。 质量属性 通过多种角度对产品的特点进行描述，从而反映 产品功能。 多角度描述产品对用户和开发人员都极为重要。 18用例用例 字处理程序为例 业务需求：“用户能有效地纠正文档中的拼写错 误” 。 用户需求：“找出文档中的拼写错误并通过一个 提供的替换项列表来供选择替换拼错的词”。 功能需求： 找到并高亮度提示错词的操作。 显示提供替换词的对话框 实现整个文档范围的替换 19什么是需求什么是需求需求的基本概念 宽泛地讲，需求来源于用户的一些“需要”，这些 “需要”被分析、确认后形成完整的文档，该文档

7、详细说明了产品“必须或应当”做什么。需求描述必须给出为什么需要这样一个系统，通 常，需求描述系统要做什么，而不是怎么做。 “为什么”和“做什么”是指系统的设计目的，是置身 系统外部，对应用领域性质的描述。 “怎么做”是指系统的内部结构和行为。20需求的重要性需求的重要性在软件工程项目中，所有的利益相关者（ stakeholder）都感兴趣的就是需求分析 阶段。 利益相关者包括客户、用户、业务或需求分析 员、开发人员、测试人员、用户文档编写者、 项目管理者和客户管理者。 需求分析奠定了软件工程和项目管理的基 础。21需求的重要性需求的重要性需求的重要性： 开发软件系统最困难的部分就是准确说明开发

8、 什么。最困难的概念性工作是编写出详细的需 求，包括所有面向用户、面向机器和其它软件 系统的接口。此工作一旦做错，将会给系统带 来极大的损害，并且以后对它修改也极为困难 。 22需求是产品的根源，需求工作的优劣对产品 影响最大。就像一条河流，如果源头被污染 了，那么整条河流也就被污染了。国内软件业的痼疾：人们并不清楚究竟该做 什么，但却一直忙碌不停地开发。需求的重要性需求的重要性23需求错误的代价需求错误的代价 在生命周期的不同阶段修复缺陷的相对成本 需求设计编码 单元测试 验收试验 保养维护 阶段阶段 0.1-0.20.51252024需求缺陷造成的成本增加需求缺陷造成的成本增加重新进行需求

9、规格说明 重新设计 重新编码 重新测试 改变订单告诉用户将以一个修正后的版本来替代有缺陷的版 本。 纠正活动消除由于不准确的特定系统的错误造成的危害，可 能涉及到赔偿客户损失。 报废包括对于已经完成的代码、设计和测试，当发现它们是 根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。25需求风险需求风险 无足够用户参与。 用户需求的不断扩展。 模棱两可的需求。 不必要的特性。 过于精简的规格说明。 忽略了用户分类。 不准确的计划 。26需求风险需求风险 无足够用户参与。 l 客户经常不

10、明白为什么收集需求和确保需求质 量需花费那么多功夫。在某些情况下，而且客 户也不太明白用户的真正需求。 l 开发人员可能也不重视用户参与。原因：一来 因为与用户合作不如编写代码有兴趣；二来因 为他们觉得已经明白用户的需求了。 l 应让具有代表性的用户在项目早期直接参与到 开发队伍中，并一同经历整个开发过程。 27需求风险需求风险 用户需求的不断扩展。 l 在开发中若不断地补充需求，项目就越变越庞大 以致超过其计划安排及预算范围 。 l 用户需求的扩展将带来过度的耗费和降低产品的 质量 。 l 要控制变更范围的不断扩展，必须一开始就对项 目视图、范围、目标、约束限制和成功标准给予 明确说明，并将

11、此说明作为评价需求变更和新特 性的参照框架 。 28需求风险需求风险 模棱两可的需求。 l 模棱两可是需求规格说明中最为可怕的问 题 。 l 它的一层含义是指诸多读者对需求说明产 生了不同的理解 。 l 另一层含义是指单个读者能用不止一个方 式来解释某个需求说明 。29需求风险需求风险 模棱两可的需求。 l 模棱两可的需求会使会使开发人员为错误 问题而浪费时间，并且使测试者与开发者 所期望的也不一致。 l 模棱两可的需求带来不可避免的后果便是 返工。 l 处理模棱两可需求的一种方法是组织好负 责从不同角度审查需求的队伍。 l 使用检测模棱两可的技术审查需求。30需求风险需求风险 不必要的特性。

12、 l 所谓“画蛇添足”，指开发人员力图增加一些“用户 欣赏”但需求规格说明中并未涉及的新功能性。但 是用户并不认为这些功能性有用，以致在其上耗 费的努力“白搭”了。 l 客户有时也可能要求一些看上去很“酷”，但缺乏 实用价值的功能，而这些只能徒耗时间和成本。 l 明白为什么要包括这些功能，以及关于这些功能 的“来龙去脉”，这样使得需求分析过程始终是注 重那些能使用户完成他们业务任务的核心功能。 31需求风险需求风险 过于精简的规格说明。 l 容易导致遗漏某些关键需求。 l 会给开发人员带来挫折，（使他们在不正确的 假设前提下和极其有限的指导下工作）。 l 也会给客户带来烦恼（他们无法得到他们所

13、设 想的产品）。 l 重视需求分析的重要性，完成尽量详细的需求 说明。 32需求风险需求风险 忽略了用户分类。 l 多数产品是由不同的人使用其不同的特性，使 用频繁程度也有所差异，使用者受教育程度和 经验水平也不尽相同 。 l 忽略某一部分用户类的需求将导致众多客户的 不满 。 l 不在项目早期就针对所有这些主要用户进行分 类的话，必然导致有的用户对产品感到失望。33需求风险需求风险 不准确的计划。 l 对需求分析缺乏理解会导致过分乐观的估计， 而当不可避免的超支发生时，会带来颇多麻烦 。 l 通常未经准备的估计是作为一种猜测而给出的 ，听者却认为是一种承诺。 l 我们要尽力给出可达到预期的期

14、望并坚持一贯 如此。34需求风险需求风险 不准确的计划。 l 需求过程中软件成本估计极不准确的原因主要 有以下五点： 频繁的需求变更； 遗漏的需求； 与用户交流不够； 质量低下的需求规格说明 不完善的需求分析 35高质量的需求过程带来的好高质量的需求过程带来的好 处处 在开发后期和整个维护阶段的重做的工作大大减少了 。 让用户积极参与需求收集过程能使产品更富有吸引力， 而且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿 沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软 硬件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响

15、。 将需求编写成清晰、无二义性的文档将会极大地有利于 系统测试，确保产品质量 。36优秀需求说明的特征优秀需求说明的特征 正确性。 完整性。 无二义性。 必要性。 可行性。 划分优先级。 可验证性。37优秀需求说明的特征优秀需求说明的特征 正确性。 l 每一项需求都必须准确地陈述其要开发出的功 能性。 l 只有用户代表才能确定用户需求的正确性，这 就是为何一定要有用户的积极参与的原因。 l 没有用户参与的需求只是是评审者凭空猜测。38优秀需求说明的特征优秀需求说明的特征 完整性。 l 不能遗漏任何必要的需求信息。遗漏需求将 很难查出。 l 每一项需求都必须将所要实现的功能描述清 楚 。l 开发

16、人员可以从需求规格说明中获得设计和 实现这些功能所需的所有必要信息。 39优秀需求说明的特征优秀需求说明的特征 无二义性。 l 对所有需求说明的读者都只能有一个明确统一 的解释。 l 尽量把每项需求用简洁明了的用户性的语言表 达出来。 l 避免二义性的有效方法包括对需求文档的正规 审查，编写测试用例，开发原型以及设计特定 的方案脚本。40优秀需求说明的特征优秀需求说明的特征 必要性。 l 每一项需求都应把客户真正所需要的和最终系 统所需遵从的标准记录下来。 l “必要性”也可以理解为每项需求都是用来授权 你编写文档的“根源” 。 l 要使每项需求都能回溯至某项客户的输入，如 使用实例或别的来源。41优秀需求说明的特征优秀需求说明的特征 可行性。 l 每