软件项目需求管理课程

《软件项目需求管理课程》由会员分享，可在线阅读，更多相关《软件项目需求管理课程（72页珍藏版）》请在金锄头文库上搜索。

1、第章 软件项目需求管理,2.3需求管理,2.1需求工程,2.4案例故事解析,2.2需求开发,2.5总结,2.1需求工程,2.1.1 软件需求概念 2.1.2 软件需求层次 2.1.3 软件需求质量评价 2.1.4 需求工程发展历程 2.1.5 需求工程研究内容,简单地说，软件需求就是确定系统需要做什么 严格意义上，软件需求是系统或软件必须达到的目标与能力,2.1.1软件需求概念,定义：,需求管理,制定项目计划,系统测试过程,项目跟踪和 控制过程,变更控制过程,系统构建,用户编制 文档过程,基础,基础,产品可 追溯到,作为 参考,验证实现 的正确性,作为 基线,进行 变更,跟踪 状态,作为 输入

2、,基线确定前缩小范围,请求范围 缩减,软件需求在软件项目的作用（如图2.1所示）,2.1.1软件需求概念,图2.1 软件需求与其他软件过程的关系,2.1.2软件需求层次,原始问题描述 用户需求 系统需求 软件设计描述,软件需求的四个抽象层次,软件需求的抽象层次如图2.2所示：,图2.2 软件需求的抽象层次,2.1.2软件需求层次,原始问题：描述是对要解决问题的叙述 用户需求：是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束 系统需求：用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述 软件设计：描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详

3、细设计和实现的基础，是对软件设计活动的概要描述,2.1.2软件需求层次,原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通 系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现 通常情况下，经常提到的是用户需求和系统需求,2.1.2软件需求层次,用户需求 用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述,2.1.2软件需求层次,使用自然语言可能出现如下问题 描述困难

4、需求混乱 因此写需求文档应遵守一些简单原则： 标准的格式 使用一致的语言 使用特殊文本 尽量避免专业术语,2.1.2软件需求层次,系统需求,系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点 系统需求描述通常采用结构化语言和过程设计语言PDL.,2.1.2软件需求层次,系统需求的描述语言:,表2.1系统需求的描述语言,2.1.2软件需求层次,系统需求的分类,功能需求 非功能需 领域需求,2.1.2软件需求层次,(1) 功能需求 功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述 系统的

5、功能需求应该具备全面性和一致性要做到全面和一致几乎是不可能的原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾 为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档,2.1.2软件需求层次,(2) 非功能需求 非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等。 非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等。 按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；产品需求对产品的

6、行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程。,2.1.2软件需求层次,表2.2 非功能需求的类别,2.1.2软件需求层次,(3) 领域需求 领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。 领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识。,2.1.2软件需求层次,2.1.3 软件需求质量评价,一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节. 软件需求质量度量的九个元素: 正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性

7、可跟踪性 可理解性,产生 人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。 需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。 需求规格说明又是软件设计、实现、测试直至维护的主要基础。,2.1.4 需求工程发展历程,发展 需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合发展。 （）对象化 需求工程的对象化主要是指需求模型及其构造方法的对象化，面向对象需求模型及需求定义语言是其研究的关键。,2.1.4 需求工程发展历程,（）形式化 需求规格描述方法有三种: 形式化

8、方法、非形式化方法和半形式化方法。 形式化方法：是具有严格数学基础的描述系统特征的方法，具有准确、无二义性的特点，有助于验证有效性和完整性。 非形式化方法：使用未作任何限制的自然语言，易于理解和使用，但它固有二义性，且难以保证正确性、可维护性，难以用计算机系统提供自动化的支持。 半形式化方法：介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些局部方面则允许使用非形式化的自然语言。,2.1.4 需求工程发展历程,(3) 自动化 在自动化的层次方面，已从实现级、设计级发展到功能级，并逐渐渗透到需求级。,2.1.4 需求工程发展历程,2.1.5需求工程研究内容,需求工程的目标 需求工程有

9、两个主要任务： 其一是：通过对问题及其环境的理解、分析和综合，建立分析模型; 其二是：在完全弄清用户对软件系统的确切要求的基础上，用SRS把用户的需求表达出来。,（）建立需求分析模型 分析模型是描述软件需求的一组模型。 需求分析模型包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，是形成需求说明、进行软件设计及实现的基础。 （）编写SRS SRS的编写要以需求分析模型为基础、按照软件组织定义的SRS大纲、采用某种需求描述语言来进行。,2.1.5需求工程研究内容,需求工程的层次分解 需求工程可分为需求开发和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。,图2

10、.3 需求工程的研究内容,2.1.5需求工程研究内容,需求开发和需求管理是有界限的如图2.4所示：,图2.4 需求开发和管理的界限,2.1.5需求工程研究内容,2.2 需求开发,2.2.1 需求开发活动 2.2.2 需求获取 2.2.3 需求分析 2.2.4 编写需求文档 2.2.5 需求验证 2.2.6 案例:某公司“船代”项目的需求开发,2.2.1 需求开发活动,需求矩阵（表2.5）：,表2.5 需求开发矩阵,2.2.2 需求获取,需求获取需求开发的第一步，主要活动包括确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，并编写成文档。 需求获取的主要活动和展现成果：,确定需求

11、开发过程 编写项目视图和范围文档 用户群分类 选择产品代表 建立核心队伍 确定使用实例 召开应用程序开发联系会议 分析用户工作流程 确定质量属性 检查问题报告 需求重用,2.2.2 需求获取,2.2.3 需求分析,需求分析包括提炼、分析和仔细审查已收集到的需求，以确保项目的参与者都明白其含义并找出其中的错误、遗漏或其它不足的地方。 需求分析的目的：获得高质量的、具体的需求,绘制关联图 创建用户接口原型 分析可行性 确定需求优先级 建立需求模型 编写数据字典 应用质量功能调配,2.2.3 需求分析,编写需求文档时，以下几点是应该注意的： 语句和段落尽量简短 表达时采用主动语态 语句要完整，且语法

12、，标点等正确无误 使用的术语要与词汇表中的定义保持一致 陈述时要采用一致的样式 避免模糊的，主观的术语，如性能优越 避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证,2.2.4编写需求文档,使用对象 需求文档的作用 软件项目客户 了解软件项目能够提供的软件产品，检查软件需求是 否 满 足需要 项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步 预测资 源的使用 软件开发人员 理解要开发的产品及具体要开发的内容 软件测试人员 验证软件系统是否满足了预期的要求 软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系 软件发布人员 在需求文档的基础上编写用户文

13、档，如用户手册 软件培训人员 在需求文档的基础上编写培训材料,需求文档的作用:,2.2.4编写需求文档,软件需求规格说明,(1)基本含义 规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统 软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档 软件项目管理者用SRS来对项目进行计划和管理。 除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。,2.2.4编写需求文档,SRS

14、的基本内容包括功能需求和非功能需求。 功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。 非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。 (2)IEEE标准830-1998,2.2.4编写需求文档,a 引言 a.1需求规格的目的 a.2软件产品范围 a.3定义、首字母缩写词语缩略语 a.4参考文献 a.5文档概要 b一般描述 b.1产品透视 b.2产品功能 b.3用户特征 b.4一般约束 b.5假设和依赖性 c专门需求 包括功能需求、非功能需求和接口需求 d附录 e

15、索引,2.2.4编写需求文档,2.2.5需求验证,需求验证过程,验证的内容：在需求验证过程中,要对需求文档中定义的需 求执行多种类型的检查,2.2.5 需求验证,2.2.6 案例：某公司“船代”项目的需求开发,见课本P57,2.3.1 需求管理的必要性 2.3.2 需求管理的困难性 2.3.3 需求管理的目标和原则 2.3.4 需求管理活动 2.3.5 需求变更管理 2.3.6 需求状态 2.3.7 需求文档版本控制 2.3.8 需求跟踪 2.3.8 案例：需求变更的代价,2.3需求管理,需求供求双方固有的矛盾 需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当

16、大的出入等情况。 需求具有易变性和难以表述性 软件项目中的问题都是在需求分析阶段埋下的祸根。 软件需求还很难以表述。 正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。,2.3.1 需求管理的必要性,需求错误出现的高频性和修复的高昂成本 需求错误是软件项目开发中最常见的。 软件缺陷修复的高成本，如图2.5所示:,2.3.1 需求管理的必要性,一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的倍。 对于软件缺陷，修复的发现和修复的越早，则成本越低。 做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。,图2.5 软件缺陷修复的成本,2.3.2需求管理的困难性,需求不总是显而易见的，它可来自各个方面； 需求并总是能容易用文字明白无误的表达； 存在不同种类的需求，其详细程度各不相同； 如果不加以控制，需求本身的数量都将难以管理； 需求之间相互关联，而且需求也和软件工程流程中的其它可交付工作相关； 需求的唯一的特