软件项目需求管理课程

第章第章 软件项目需求管理软件项目需求管理2.3需求管理2.1需求工程2.4案例故事解析2.2需求开发2.5总结2.1需求工程o2.1.1 软件需求概念o2.1.2 软件需求层次o2.1.3 软件需求质量评价o2.1.4 需求工程发展历程o2.1.5 需求工程研究内容o简单地说，软件需求就是确定系统需要做什么o严格意义上，软件需求是系统或软件必须达到的目标与能力2.1.1软件需求概念定义：定义：需求管理需求管理制定项目计划制定项目计划系统测试过程系统测试过程项目跟踪和项目跟踪和控制过程控制过程变更控制过程变更控制过程系统构建系统构建用户编制用户编制文档过程文档过程基础基础基础基础产品可产品可追溯到追溯到作为作为参考参考验证实现验证实现的正确性的正确性作为作为基线基线进行进行变更变更跟踪跟踪状态状态作为作为输入输入基线确定基线确定前前缩小范围缩小范围请求范围请求范围缩减缩减软件需求在软件项目的作用软件需求在软件项目的作用（如图2.1所示）2.1.1软件需求概念图2.1 软件需求与其他软件过程的关系2.1.2软件需求层次l原始问题描述l用户需求l系统需求l软件设计描述软件需求的四个抽象层次软件需求的四个抽象层次软件需求的抽象层次如图2.2所示：图2.2 软件需求的抽象层次2.1.2软件需求层次原始问题：描述是对要解决问题的叙述用户需求：是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束系统需求：用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述软件设计：描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述2.1.2软件需求层次o原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通o系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现o通常情况下，经常提到的是用户需求和系统需求2.1.2软件需求层次用户需求用户需求 用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述2.1.2软件需求层次使用自然语言可能出现如下问题n描述困难n需求混乱 因此写需求文档应遵守一些简单原则：n标准的格式n使用一致的语言n使用特殊文本n尽量避免专业术语2.1.2软件需求层次系统需求系统需求o系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点o系统需求描述通常采用结构化语言和过程设计语言PDL.2.1.2软件需求层次 系统需求的描述语言:名称说明 优点 缺点 结构化语言是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述表现能力强、易于理解、一致性约束、控制结构、图形化显示仍然有一定程度的二义性；细致程度欠缺PDL 源于像Java或Ada这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力 可通过软件工具进行语法和语义检查表达系统功能的能力不足、使用的符号只有具有程序设计背景的人才能理解 表2.1系统需求的描述语言2.1.2软件需求层次系统需求的分类系统需求的分类l功能需求l非功能需l领域需求2.1.2软件需求层次(1)功能需求l功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述l系统的功能需求应该具备全面性和一致性要做到全面和一致几乎是不可能的原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾l为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档2.1.2软件需求层次(2)非功能需求l非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等。l非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等。l按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程。2.1.2软件需求层次非功能需求产品需求 可用性需求 效率需求 性能需求 空间需求 可靠性需求 可移植性需求 机构需求 交付需求 实现需求 标准需求 外部需求 互操作需求 道德需求 立法需求 隐私需求安全性需求表2.2 非功能需求的类别2.1.2软件需求层次(3)领域需求l领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。l领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识。2.1.2软件需求层次2.1.3 软件需求质量评价o一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节.o软件需求质量度量的九个元素:n正确性n无歧义n完备性n一致性n根据重要性和稳定性分级n可验证性n可修改性n可跟踪性n可理解性产生产生 人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。需求规格说明又是软件设计、实现、测试直至维护的主要基础。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 需求开发o2.2.1 需求开发活动o2.2.2 需求获取o2.2.3 需求分析o2.2.4 编写需求文档o2.2.5 需求验证o2.2.6 案例:某公司“船代”项目的需求开发2.2.1 需求开发活动需求矩阵（表需求矩阵（表2.52.5）：）：需求获取需求分析规格说明需求验证编写前景绘制关联图采用软件需求规格说明模板审查需求文档确定用户需求开发过程创建开发原型指明需求来源依据需求编写测试用例用户群分类分析可行性为每项需求注上标号确定系统合格的验收标准选择产品代表确定需求优先级记录业务范围确定用例为需求建立模型创建需求跟踪矩阵联系会议编写数据字典分析用户工作流程应用质量功能调配确定质量属性检查问题报告需求重用表2.5 需求开发矩阵2.2.2 需求获取o需求获取需求开发的第一步，主要活动包括确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，并编写成文档。o需求获取的主要活动和展现成果：o确定需求开发过程o编写项目视图和范围文档o用户群分类o选择产品代表o建立核心队伍o确定使用实例o召开应用程序开发联系会议o分析用户工作流程o确定质量属性o检查问题报告o需求重用2.2.2 需求获取2.2.3 需求分析o需求分析包括提炼、分析和仔细审查已收集到的需求，以确保项目的参与者都明白其含义并找出其中的错误、遗漏或其它不足的地方。o需求分析的目的：获得高质量的、具体的需求o绘制关联图o创建用户接口原型o分析可行性o确定需求优先级o建立需求模型o编写数据字典o应用质量功能调配2.2.3 需求分析编写需求文档时，以下几点是应该注意的：o语句和段落尽量简短o表达时采用主动语态o语句要完整，且语法，标点等正确无误o使用的术语要与词汇表中的定义保持一致o陈述时要采用一致的样式o避免模糊的，主观的术语，如性能优越o避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证2.2.4编写需求文档使用对象 需求文档的作用 软件项目客户 了解软件项目能够提供的软件产品，检查软件需求是否 满足需要项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员 理解要开发的产品及具体要开发的内容软件测试人员 验证软件系统是否满足了预期的要求软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员 在需求文档的基础上编写用户文档，如用户手册软件培训人员 在需求文档的基础上编写培训材料 需求文档的作用需求文档的作用:2.2.4编写需求文档软件需求规格说明软件需求规格说明(1)基本含义n规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统n软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档n软件项目管理者用SRS来对项目进行计划和管理。n除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。2.2.4编写需求文档nSRS的基本内容包括功能需求和非功能需求。n功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。n非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。(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需求管理需求供求双方固有的矛盾 需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。需求具有易变性和难以表述性l软件项目中的问题都是在需求分析阶段埋下的祸根。l软件需求还很难以表述。l正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。2.3.1 需求管理的必要性需求错误出现的高频性和修复的高昂成本需求错误出现的高频性和修复的高昂成本需求错误是软件项目开发中最常见的。软件缺陷修复的高成本，如图2.5所示:2.3.1 需求管理的必要性l 一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的倍。l对于软件缺陷，修复的发现和修复的越早，则成本越低。l做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。图2.5 软件缺陷修复的成本2.3.2需求管理的困难性o需求不总是显而易见的，它可来自各个方面；o需求并总是能容易用文字明白无误的表达；o存在不同种类的需求，其详细程度各不相同；o如果不加以控制，需求本身的数量都将难以管理；o需求之间相互关联，而且需求也和软件工程流程中的其它可交付工作相关；o需求的唯一的特征或特征值。例如，它们的重要性和容易满足的程度的各不相同；o需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理；o需求会有变更；o需求可能对时间敏感。2.3.3 需求管理的目标和原则目标 需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。具体来说,需求管理的目标有二个:(1)使软件需求受控,并建立供软件工程和管理使用的需求基线。(2)使软件计划、产品和活动与软件需求保持一致。原则为进行有效的需求管理，通常要遵循如下五条原则：（）需求一定要分类管理（）需求必须分优先级（）需求必须文档化（）需求一旦变化，就必须对需求变更的影响进行评估（）需求管理必须与需求工程的其他活动紧密整合需求管理策略l需求一定要与投入有必然的联系l需求的变更要经过出资者的认可l小的需求变更也要经过正规的需求管理流程l精确地需求与范围定义并不会阻止需求的变更2.3.4需求管理的目标和原则2.3.4 需求管理活动o需求管理规划内容包括：n需求识别n变更管理过程n需求跟踪n自动化工具o需求管理是一个对系统需求变更了解和控制的过程。需求管理的过程是与其他需求工程过程相互关联的。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。o需求管理活动的具体内容如表2.3所示：需求管理活动 活动的任务变更控制 建议需求变更并分析其影响，做出是否变更的决策版本控制 确定单个需求和SRS的版本需求跟踪 定义对于其他需求及系统元素的联系链需求状态 定义并跟踪需求的状态表2.3 需求管理活动2.3.4 需求管理活动2.3.5 需求变更管理需求变更的原因需求变更的原因l软件项目的需求总是在变化着,一般原因有二:(1)在项目的早期所有的问题不可能被完全定义,软件需求是不完全的,注定了需求需要变更。(2)随着软件项目的进行,软件开发人员对问题的理解会发生变化,这些变化也要反馈到需求中去。l大型软件系统还可能存在如下导致需求变更的原因:(1)不同类型的用户的需求可能是冲突的或是矛盾的,最后的系统需求是它们之间的一个妥协.这种妥协的程度在项目进行过程中有可能发生改变,从而导致系统需求的改变。(2)系统购买者或系统最终用户很少是同一人,有的系统客户对系统提出的一些需求可能和最终用户需求不一致。变更管理过程变更管理过程 变更管理过程为三个阶段（如图 2.7所示）：2.3.5 需求变更管理图2.7 修正后的需求(1)变更描述 变更描述阶段要对需求问题或变更提议进行分析以检查它的有效性，进而产生一个更明确的需求变更提议。(2)变更分析 变更分析阶段对被提议的变更产生的影响进行评估。一旦分析完成，就有了对此变更是否执行的决策意见。(3)变更实现 实现变更时，需求文档及系统设计和实现都要做修改。一个容易出现的错误，一定要注意：先对系统做变更然后再回头修改需求文档的想法，这几乎不可避免地导致需求描述和系统实现不同步。需求文档应该有一个很好的形式，使得变更不会带来大量文字的修改。对于程序文档的可变性则通过最小化外部引用和尽量使之模块化来实现。2.3.5 需求变更管理变更影响分析变更影响分析n进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其他需求的影响,同时明确与变更相关的任务并评估完成这些任务需要的工作量。变更影响分析有助于做出信息量充分的变更决策,确定对变更是修改还是抛弃,或者创建新系统以及评估每个任务的工作量.n如果一个处于关键路径的任务因变更而延期,则项目肯定赶不上预定进度,但如果能避免变更影响关键任务,则变更不会影响项目的进度表n影响分析报告的模板,用来报告进行需求变更的影响分析,变更控制委员会仅需要影响分析的总结.2.3.5 需求变更管理需求变更影响分析模板如图2.8所示：2.3.5 需求变更管理图2.8 需求变更影响分析模板变更控制流程变更控制流程 需求变更控制的流程如图2.9所示:2.3.5 需求变更管理图2.9 需求变更控制流程2.3.5 需求变更管理需求变更控制的流程如图需求变更控制的流程如图2.122.12所示所示:2.3.6 需求状态需求的属性需求的属性 需求还有一些相关的属性,这些属性的定义及更新是需求管理的重要内容.需求的属性为需求提供了背景资料和上下文关系。需求主要考虑的属性如下：(1)需求的创建时间(2)需求的版本(3)需求的创建者(4)需求的批准者(5)需求的状态(6)需求的原因或根据(7)需求涉及的子系统(8)需求涉及的产品版本(9)需求的验证方法或测试标准(10)需求的优先级(11)需求的稳定性需求状态需求状态 需求状态是需求的一项重要属性,跟踪需求的状态是需求管理的一个重要方面。状态是一种事物或实体在某一个时间点或某一阶段的情况的反映。需求状态是指某时间点需求的一种情况反映。建立需求状态是为了表示需求的各种不同情况：2.3.6 需求状态o客户的需求可分为四种情况:客户可以明确且清楚地提出的需求。客户知道需要做些什么,但却不能确定的需求。需求可以由客户得出,但需求的业务不明确,还需要等待外部信息。客户本身也说不清楚的需求。2.3.6 需求状态o需要与客户沟通或确认的需求有两种情况:其一：是确认双方达成共识 其二：是还需要再进一步的沟通o可把需求状态分为如下8种 已建议 已批准 已拒绝 已设计 已实现 已验证 已交付 已删除2.3.6 需求状态2.3.7 需求文档版本o如果没有很好的需求文档版本管理,就容易造成资源浪费.o需求文档版本控制是需求管理的一个必要方面.o做好需求文档版本控制,必须保证如下几点:统一确定需求文档的每一个版本,保证每个成员都能得到当前的需求版本;清楚地将变更写成文档,并及时通知项目开发所涉及的人员;为尽量减少困惑、冲突、误传，应只允许指定的人来更新需求文档。o版本控制的最简单方法是在每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已作变更的内容、变更日期、变更人的姓名以及变更的原因，并根据标准约定手工标记软件需求规格说明的每一次修改。2.3.8 需求跟踪需求跟踪的必要性需求跟踪的必要性l进行需求跟踪的目的是建立和维护从用户需求开始到测试之间的一致性与完整性,确保所有的实现都以用户需求为基础,而实现的需求也全部覆盖了预期的需求,同时确保所有的输出与用户需求的符合性.l跟踪能力信息使得变更影响分析十分便利,有利于确认和评估实现某个建议的需求变更所必须的工作.可追溯性信息 进行需求跟踪,就要对需求和需求之间以及需求和系统设计之间的许多关系进行追溯。当需求变更发生的时候,必须追踪这些变题对其他需求和系统设计的影响。可追溯性是需求描述的一个总体特性,反映了反映相关需求的能力。n需要维护的可追溯性信息有三类:(1)源可追溯性信息,指连接需求到提出需求 的项目相关人员和产生需求的原因。(2)需求可追溯性信息,指连接需求文档中彼此依赖的需求。(3)设计可追溯性信息,指连接需求到其实现的设计模块。2.3.8 需求跟踪需求跟踪的实现需求跟踪有两种方式,正向跟踪和逆向跟踪：(1)正向跟踪:以用户需求为切入点,检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。(2)逆向跟踪:检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。需求跟踪的双向模式可以通过需求链进行表示。需求链需求链：指的是需求能够上传下达，从客户传达到需求过程，并从需 求过程传达到需求过程的后继开发链，且可以逆向转达。如图2.10所示：2.3.8 需求跟踪图2.10 需求链 过程元素之间的关系有如下三种l一对一，如一个代码模块应用一个设计元素。l一对多，如多个测试实例验证一个功能需求。l多对多，如一个测试实例导致多个功能性需求，而其中一些功能性需求又拥有多个使用实例。2.3.8 需求跟踪(3)(3)需求跟踪矩阵需求跟踪矩阵需求代号规格说明需求实例设计实例编码实例测试实例测试记录R001标题或标识符标题或标识符标题或标识符标题或标识符标题或标识符标题或标识符R0022.3.8 需求跟踪表2.4 需求跟踪矩阵需求跟踪矩阵的作用l可防止遗漏l为评审提供方便l便于进行变更影响追踪、分析和检查2.3.8 需求跟踪 表2.5 跟踪矩阵实例 1 12 23 34 45 56 67 78 8需求需求号号需求需求描述描述概要设概要设计文档计文档索引号索引号对应的对应的设计设计(功能功能,结构结构,数据库数据库)实现实现(程序程序,类类,继继承类承类)单元测单元测试用例试用例集成集成/系统测系统测试用例试用例验收验收测试测试用例用例1.1.1.1.2 2利用收利用收集的数集的数据实现据实现亮点的亮点的实时集实时集成成5.3.25.3.2数据采数据采集与亮集与亮度控制度控制器接口器接口PB405PB405数据采数据采集集#12#12#46#46#11#11CICS20CICS203 3亮点亮点控制器控制器启动启动#1#1#47#47#11#112.3.8 需求跟踪需求跟踪的作用在需求验证中的作用有助于需求变更影响分析便于需求的维护便于测试时找出问题所在便于项目跟踪减小项目的风险简化了系统的再设计易于软件重用2.3.8 需求跟踪l方式 评审有两类方式:一类是正式技术评审,另一类是非正式技术评审。l注意事项严格控制每一次评审的文档规模及持续时间评审工作要分段进行对讨论的问题进行控制避免无谓的争吵需求评审2.3.8 需求跟踪2.3.9 案例：需求变更的代价见课本P742.4 案例故事解析需求开发的注意事项l项目前景认识一致l需求完整和正确l需求分析过程中要注意划分需求的优先级l需求规格得到双方的一致理解和认可需求管理的注意事项l需求变更l需求变更过程l未实现的需求l扩充项目范围2.5 总结 一个项目只有一个项目只有“一个一个”需求需求