搜索
第四章01目录CONTENT需求定义管理过程0203分析方法Part1需求定义为什么要做需求管理？你心里想：所谓适应北极环境。北极的地面很硬。那应该做一个结实的杯子。于是你历经千辛万苦做出了：爱斯基摩人不断摇头，决定一分钱也不付给你。最后你才知道，他们需要一个拿着不冻手的杯子。他们的真实需求是这样的：一天，一家爱斯基摩人来找你帮忙做一个杯子。要求：这个杯子在使用时要能适应北极的环境。这家人承诺：杯子做好后会有高额的酬谢。客户不知道自己要什么客户：塑料杯、木头杯、还是橡胶杯，我也不知道！客户知道自己要什么，但表达不清客户提要求：使用时要能适应北极的环境。我们经常会对客户的要求产生错误的理解我们的理解：他一定要一个结实的杯子！4.1.1软件需求概念我们不能知其然，而不知其所以然。要做好需求管理。项目失败的原因分析6No.Top10Factors平均值1Inadequaterequirementsspecification不充分的需求规范4.52Changesinrequirements需求的改变4.33Shortageofsystemsengineers缺乏系统工程师4.24Shortageofsoftwaremanagers缺乏了解软件特性的经理人4.15Shortageofqualifiedprojectmanagers缺乏合格的项目经理4.16Shortageofsoftwareengineers缺乏软件工程师3.97Fixed-pricecontract固定价合同3.88Inadequatecommunicationsforsystemintegration系统集成阶段,交流与沟通不充分3.89Insufficientexperienceasteam团队缺乏经验3.610Shortageofapplicationdomainexperts缺乏应用领域专家3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute本章要点7一二三四软件需求定义软件需求管理过程需求分析方法案例分析五课程实践软件需求定义chapter__28需求是指用户对软件的功能和性能的要求。软件需求在软件项目中的作用4.1.1软件需求概念跟踪控制过程软件需求过程文档编制过程项目计划过程系统构建过程变更控制过程系统测试过程软件需求的抽象层次原始问题描述：对要解决问题的叙述，它是软件需求的基础用户需求：用自然语言和图表给出的关于系统需要提供的服务及操作的约束系统需求：用详细的术语给出系统要提供的服务及受到的约束软件设计描述：在系统需求的基础上加入更详细的内容，它是软件详细设计和实现的基础4.1.2软件需求类别原始问题描述用户需求系统需求软件设计描述原始问题空间解决方案空间软件需求各组成部分关系业务需求用户需求功能需求非功能需求、软件需求规格说明等4.1.2软件需求类别用户需求从用户角度描述系统的需求，只描述系统的外部行为，并且只通过自然语言、图表、图形等叙述。问题：描述困难，需求混乱。原则：标准的格式；使用一致的语言；使用特殊文本强调关键的需求；尽量避免专业术语。4.1.2软件需求类别功能需求从开发人员角度描述系统的需求，是系统实现的依据，通常采用结构化语言、PDL过程设计语言等描述。功能需求的描述语言4.1.2软件需求类别系统需求的分类功能需求：描述系统应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。功能需求应具有全面性和一致性。非功能需求：指那些不直接与系统的具体功能相关的一类需求。它们与系统的总体特性相关，定义了对系统提供的功能或服务的约束。领域需求：来源系统应用的领域，反应该领域的特点，可能是领域需求：功能需求或非功能需求。需要领域知识确定。4.1.2软件需求类别非功能需求的类别4.1.2软件需求类别需求工程的定义：是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程的发展趋势：4.1.4需求工程对象化OOP-OOD-OOA形式化形式化方法：具有严格数学基础的描述方法，准确、无二义性非形式化方法：未进行任何限制的自然语言，易理解和使用半形式化方法：结合上述两种特点自动化实现级-设计级-功能级-需求级需求工程目标：通过对问题及其环境的理解建立分析模型，在完全理解用户需求的基础上用SRS表达用户需求建立分析模型：它包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束编写SRS：按照软件组织定义的SRS大纲，采用某种需求描述语言来完成4.1.4需求工程需求工程的分解层次：4.1.4需求工程需求工程需求开发需求管理需求获取需求分析规格说明需求验证变更管理版本控制需求跟踪需求状态需求开发与管理的界限：4.1.4需求工程需求获取及分析需求记录需求验证基准需求规格需求变更版本控制需求状态及跟踪客户市场管理项目环境需求管理需求开发Part2需求开发需求开发又称之为需求定义，主要包括：需求获取、需求分析、需求处理（编写规格说明书）和需求验证四个阶段。4.2.1需求开发过程需求管理需求获取需求分析规格说明需求验证调研资料用例模型分析模型需求规格说明书审核通过的规格说明书活动产出物需求开发需求开发操作矩阵4.2.1需求开发过程需求获取需求分析规格说明需求验证编写前景确定需求开发过程用户群分类选择产品代表确定用例联系会议分析用户工作流程确定质量属性检查问题报告需求重用绘制关联图创建开发原型分析可行性确定需求优先级为需求建立模型编写数据字典应用质量功能调配采用软件需求规格说明模板指明需求来源为每项需求注上标号记录业务范围创建需求跟踪能力矩阵审查需求文档依据需求编写测试用例确定系统合格的验收标准需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、系统环境等，对任务进行分析、从而开发、捕获和修订用户的需求，以建立良好的沟通渠道和方式。建立系统模型——确定系统的用户需求4.2.2需求获取需求分析包括提炼、分析和仔细审查已收集到的需求，为最终用户所看到的系统建立一个概念模型以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。建立业务模型——确定系统的功能需求4.2.3需求分析需求文档的编制与作用软件需求文档包括用户需求和详细的系统需求描述，是对软件系统要求的正式陈述。软件需求必须具有综合性，谨慎变更。注意事项：语句和段落尽量简短表达时采用主动语态语句完整，语法、标点正确无误使用术语要与词汇表中保持一致陈述时采用一致的样式避免模糊的主观的术语，如“优越”避免使用比较性词汇，尽量给出定量说明。4.2.4需求文档需求文档作用4.2.4需求文档使用对象需求文档的作用软件项目客户了解软件项目能够提供的软件产品，检查软件需求是否满足需要项目管理人员根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员理解要开发的产品及具体要开发的内容软件测试人员验证软件系统是否满足了预期的要求软件维护人员使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员在需求文档的基础上编写用户文档，如用户手册软件培训人员在需求文档的基础上编写培训材料软件需求规格说明需求文档采用软件需求规格说明的形式。SRS（SoftwareRequirementSpecification)精确地阐述一个软件系统必须提供的功能和性能以及它所考虑的限制条件，是对外部行为和系统环境接口的简洁完整的描述性文档。SRS包括功能需求和非功能需求。需求分析完成的标志是提交一份完整的软件需求规格说明书（SRS）。4.2.4需求文档需求规格说明模板4.2.4需求文档需求验证分析需求规格说明的正确性和可行性，检验需求能否反映客户的意愿。需求验证关心的是需求文档完整的草稿，而需求分析关心的是不完整的需求。在构造设计开始之前，通过需求验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，能大大减少项目后期的返工现象。需求验证的步骤：①审查需求文档②以需求为依据编写测试计划与测试用例③编写用户使用手册④确定合格的系统验收标准⑤最后的签字通过需求评审4.2.5需求验证需求验证的内容：（1）有效性检查对于每项需求，首先必须证明它是正确有效的，确实能解决用户面对的问题。（2）一致性检查在需求文档中，需求不应该冲突，即对同一系统功能不应出现不同的描述或相互矛盾的约束。当两条需求不能同时满足时，则定义二者是不一致的。采用形式化的需求规格说明可以用软件工具验证需求的一致性。4.2.5需求验证（3）完备性检查需求文档应包括所有系统用户想要的功能和约束。如果所有可能的状态、状态变化、转入、产品和约束都在需求中作了描述，则说明这个需求集合是完备的。需求的完备性必须由用户来检验，可以通过原型系统来实现。（4）现实性检查指检查需求以保证能利用现有技术实现，还要考虑系统开发的预算和进度安排。分析员可以参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。（5）可检验性检查指描述的需求能够实际测试。为减少在客户和开发商之间可能的争议，描述的系统需求应该总是可以检验的。这意味着能设计出一组检查方法来验证交付的系统是否满足需求。4.2.5需求验证（6）可跟踪性检查指需求的出处被清晰的记录，每一系统功能都能被跟踪到要求它的需求集合，每一项需求都能追溯到特定用户的要求，它能为评估需求变更对系统其他部分的影响提供帮助。（7）可调节性检查指需求变更能够不对系统的其他部分带来大规模的影响。（8）可读性检查指需求说明是否能被系统购买者和最终用户读懂。4.2.5需求验证Part3需求管理需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其它需求和其它项目工件之间的可追踪性。4.3.1需求管理的必要性需求管理的必要性①需求供求双方固有的矛盾，需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。4.3.1需求管理的必要性②需求具有易变性和难以表述性，软件项目中４０％～６０％的问题都是在需求分析阶段埋下的祸根。软件需求还很难以表述，正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。③需求错误出现的高频性和修复的高昂成本4.3.1需求管理的必要性缺陷来源潜在缺陷剩余缺陷排除效率（%）需求0.20.04677设计0.250.037585编码0.350.017595建档0.120.02480修复0.080.02470合计10.14985.1CapersJones对软件缺陷的研究需求错误是软件项目开发中最常见的4.3.1需求管理的必要性需求阶段设计阶段编码阶段单元测试集成测试维护阶段0.1~0.20.512520需求管理存在以下问题：需求不总是显而易见的，而且它可来自各个方面。需求并不总是容易用文字明白无误地表达。存在不同种类的需求，其详细程度各不相同。如果不加以控制，需求的数量将难以管理。需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。需求既非同等重要，处理的难度也不同。需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。需求发生变更。需求可能对时间敏感。4.3.1需求管理的必要性需求管理的目标：在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解具体来说，需求管理的目标有二个:①使软件受控，并建立供软件工程和管理