软件项目管理_软件项目需求管理

第２章软件项目需求管理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.1所示）2.1.1软件需求概念图2.1软件需求与其他软件过程的关系2.1.2软件需求层次原始问题描述用户需求系统需求软件设计描述软件需求的四个抽象层次软件需求的抽象层次如图2.2所示：图2.2软件需求的抽象层次2.1.2软件需求层次①原始问题：描述是对要解决问题的叙述②用户需求：是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束③系统需求：用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述．④软件设计：描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述．2.1.2软件需求层次原始问题描述和用户需求的抽象层次比较高．能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通．系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现．通常情况下，经常提到的是用户需求和系统需求．2.1.2软件需求层次用户需求用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂．它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述．2.1.2软件需求层次使用自然语言可能出现如下问题描述困难需求混乱因此写需求文档应遵守一些简单原则：标准的格式使用一致的语言使用特殊文本尽量避免专业术语2.1.2软件需求层次系统需求系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据．一个完整且一致的系统需求描述，是软件设计的起点．系统需求描述通常采用结构化语言和过程设计语言PDL.2.1.2软件需求层次系统需求的描述语言:名称说明优点缺点结构化语言是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述表现能力强、易于理解、一致性约束、控制结构、图形化显示仍然有一定程度的二义性；细致程度欠缺PDL源于像Java或Ada这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力可通过软件工具进行语法和语义检查表达系统功能的能力不足、使用的符号只有具有程序设计背景的人才能理解表2.1系统需求的描述语言2.1.2软件需求层次系统需求的分类功能需求非功能需领域需求2.1.2软件需求层次(1)功能需求功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述．系统的功能需求应该具备全面性和一致性．要做到全面和一致几乎是不可能的．原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档．2.1.2软件需求层次(2)非功能需求非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等。非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等。按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程。2.1.2软件需求层次非功能需求产品需求可用性需求效率需求性能需求空间需求可靠性需求可移植性需求机构需求交付需求实现需求标准需求外部需求互操作需求道德需求立法需求隐私需求安全性需求表2.2非功能需求的类别2.1.2软件需求层次(3)领域需求领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识。2.1.2软件需求层次2.1.3软件需求质量评价一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节.软件需求质量度量的九个元素:正确性无歧义完备性一致性根据重要性和稳定性分级可验证性可修改性可跟踪性可理解性产生人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。需求规格说明又是软件设计、实现、测试直至维护的主要基础。2.1.4需求工程发展历程发展需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合发展。（１）对象化需求工程的对象化主要是指需求模型及其构造方法的对象化，面向对象需求模型及需求定义语言是其研究的关键。2.1.4需求工程发展历程（２）形式化需求规格描述方法有三种:形式化方法、非形式化方法和半形式化方法。形式化方法：是具有严格数学基础的描述系统特征的方法，具有准确、无二义性的特点，有助于验证有效性和完整性。非形式化方法：使用未作任何限制的自然语言，易于理解和使用，但它固有二义性，且难以保证正确性、可维护性，难以用计算机系统提供自动化的支持。半形式化方法：介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些局部方面则允许使用非形式化的自然语言。2.1.4需求工程发展历程(3)自动化在自动化的层次方面，已从实现级、设计级发展到功能级，并逐渐渗透到需求级。2.1.4需求工程发展历程2.1.5需求工程研究内容需求工程的目标需求工程有两个主要任务：其一是：通过对问题及其环境的理解、分析和综合，建立分析模型;其二是：在完全弄清用户对软件系统的确切要求的基础上，用SRS把用户的需求表达出来。（１）建立需求分析模型分析模型是描述软件需求的一组模型。需求分析模型包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，是形成需求说明、进行软件设计及实现的基础。（２）编写SRSSRS的编写要以需求分析模型为基础、按照软件组织定义的SRS大纲、采用某种需求描述语言来进行。2.1.5需求工程研究内容需求工程的层次分解需求工程可分为需求开发和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。图2.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需求获取需求获取需求开发的第一步，主要活动包括确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，并编写成文档。需求获取的主要活动和展现成果：确定需求开发过程编写项目视图和范围文档用户群分类选择产品代表建立核心队伍确定使用实例召开应用程序开发联系会议分析用户工作流程确定质量属性检查问题报告需求重用2.2.2需求获取2.2.3需求分析需求分析包括提炼、分析和仔细审查已收集到的需求，以确保项目的参与者都明白其含义并找出其中的错误、遗漏或其它不足的地方。需求分析的目的：获得高质量的、具体的需求绘制关联图创建用户接口原型分析可行性确定需求优先级建立需求模型编写数据字典应用质量功能调配2.2.3需求分析编写需求文档时，以下几点是应该注意的：语句和段落尽量简短．表达时采用主动语态．语句要完整，且语法，标点等正确无误．使用的术语要与词汇表中的定义保持一致．陈述时要采用一致的样式．避免模糊的，主观的术语，如性能＂优越＂避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证．2.2.4编写需求文档使用对象需求文档的作用软件项目客户了解软件项目能够提供的软件产品，检查软件需求是否满足需要项目管理人员根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员理解要开发的产品及具体要开发的内容软件测试人员验证软件系统是否满足了预期的要求软件维护人员使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员在需求文档的基础上编写用户文档，如用户手册软件培训人员在需求文档的基础上编写培训材料需求文档的作用:2.2.4编写需求文档软件需求规格说明(1)基本含义规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统．软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档．软件项目管理者用SRS来对项目进行计划和管理。除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。2.2.4编写需求文档SRS的基本内容包括功能需求和非功能需求。功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。(2)IEEE标准830-19982.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索引2.2.4编写需求文档2.2.5需求验证需求验证过程确定合格的标准编写用户手册依据需求编写测试用例审查需求文档可读性一致性完备性现实性可检验性可跟踪性可调节性有效性验证的内容：在需求验证过程中,要对需求文档中定义的需求执行多种类型的检查2.2.5需求验证2.2.6案例：某公司“船代”项目的需求开发见课本P572.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需求管理需求供求双方固有的矛盾需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。需求具有易变性和难以表述性软件项目中４０％～６０％的问题都是在需求分析阶段埋下的祸根。软件需求还很难以表述。正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。2.3.1需求管理的必要性需求错误出现的高频性和修复的高昂成本需求错误是软件项目开发中最常见的。软件缺陷修复的高成本，如图2.5所示:2.3.1需求管理的必要性一个在需求