需求工程(第二讲)需求工程过程.ppt

第二讲：需求工程过程,目的：介绍为软件加强型系统中的复杂软件设计的需求工程过程，涉及抽取需求分析需求验证需求管理需求主要关注点：需求工程中要做些什么,软件需求工程的内容,软件需求工程,需求开发,需求管理,需求建模,需求获取,需求规格说明,需求验证,建立基线,变更控制,需求跟踪,2.1需求分析员,需求分析员的职责 需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。(是一个角色，而非职务，重要的是具备必要的能力和知识)需求分析员是客户与开发人员交流的中间人，负责将客户对产品的初步想法转化为明确的需求说明，用来指导开发工作。需求分析员必须先充分理解用户对新系统的目标，然后再定义功能和质量需求。由此项目经理才能对项目进行估算，开发人员才能进行设计开发，测试人员才能对产品进行验证。,2.1.2 需求分析员必备的技能,出色的交流、引导和人际交往能力 技术和业务领域的丰富知识 适合这项工作的相应的个性倾听的技巧 有效的倾听要求不能分神，保持专注的姿态和目光接触，以及重复要点以证实你的理解。要抓住对方说的每一句话，从中找出他们因犹豫而没说出的内容。要熟悉合作者的表达习惯，避免用个人的理解方式来过滤客户所说的话。,交谈和提问的技巧,大部分需求是通过讨论得到的，因此必须能够与不同的个人或小组就需求展开讨论。与高级经理或某些固执己见、盛气凌人的人打交道，必须学会通过提出适当的问题，让重要的需求信息显现出来。例如：用户很自然地把注意力集中在系统正常和预期的行为上，然而，很多代码却是为了处理异常而编写的。需求分析员必须研究和了解可能出错的情形，并决定系统如何响应。,分析能力,能够以不同的方式思考问题：有时必须将高层的信息不断细化；另一些情况下需要将某个用户提出的一项特定的需求推广为一组需求，以满足众多的同类用户。要严格评估各种来源的信息，以便消除需求中的矛盾，区分出“需要”与真正的需求。,协调能力,由于所处位置（立场）的不同，各角色人员（如业务人员与IT人员）之间不时会出现紧张关系。一位具有良好的提问、观察、协调能力的中间协调人能够帮助团队建立信任。观察能力 敏锐的观察力能够从不经意的闲谈中发现重要信息。通过观看用户工作，如何使用现有程序，可以察觉用户不曾提及的细微之处。,写作能力,需求开发提交的主要结果是书面的需求规格说明，用于在客户、操作人员、管理人员和技术人员之间传递信息。语言驾驭能力极其重要。组织能力 在处理获取和分析过程中收集到的大量杂乱的信息时，只有具备良好的组织能力和从混乱、含糊的信息中找出真正意义的耐心和韧性，才能妥善处理快速变化的信息，并将其组织成一致的整体。,建模能力,掌握从传统的流程图到结构化分析模型，直至当今的统一建模语言(UML)等多种分析工具。这些工具中有些用于与客户交流，而另一些则用于与开发人员交流。人际交往能力 具备让彼此利益竞争的人们进行合作的能力。能够轻松的与组织中各级别的人打交道。与分布在各地的虚拟团队一起工作。与拥有不同文化背景或母语的人交流。,创造力,需求分析员不能像抄录员那样只记下客户说过的每句话。一流的需求分析员能够创造需求，构思新颖的产品功能，推测新的市场和商业机会，并且思考让客户惊喜的方法。能够帮助用户发现隐含的需求，并且找到新方法来满足这些需求。,2.1.3 需求分析员必备的知识,除了前面提到的专门技能和性格特点，还需具备从实践中积累的广博的知识。掌握和熟练运用不同软件开发模型中的需求管理技术充分理解项目管理、风险管理和质量工程，有助于避免因需求问题导致项目失败。对商业软件：掌握产品管理理念，了解如何定位和开发企业软件产品。掌握应用领域的知识是减少与客户间误解和避免需求失败一个重要的因素。,2.1.4 如何培养需求分析员,优秀的需求分析员是培养出来的，而不是训练出来的。这项工作包括很多面向人而不是技术的“软性技能”。不同背景的人能力水平有着不同的展现：实践经验、工程技术、项目管理、技术和工具、质量以及个性。如下是不同背景的人转而成为需求分析员的优劣势：,从用户转为需求分析员,很多企业的IT部门中都有由用户转行而来的业务分析员。优势：这些用户对所从事工作领域的业务和工作环境有着深刻的理解，了解现有系统和业务流程，熟悉专业语言，容易获得原来同行的信任。劣势：容易自认为比用户更了解需求，而不尊重实际使用者的意见。局限于现有工作模式，跟不上业务的最新发展。,从开发人员转为需求分析员,优势：熟悉技术和开发流程，了解实现的难易，易于引导用户少走弯路，善于创造需求，技术专家的背景容易获得用户的尊重。劣势：需求开发工作对人员技能和个性的要求与软件开发工作不同，不少开发人员对用户缺乏耐心。容易陷入具体技术和软件本身，而不是用户的需求。开发人员要想成为需求分析员，需多掌握业务领域知识，提高“倾听、协商、引导”等软性技能水平。,主题专家,有些软件组织雇用某些有高职位背景的专家级用户担任需求分析员或用户代表，这些人精通产品，并且在应用领域内有着丰富的经验。问题：容易根据自己的偏好定义系统的需求。往往希望实现高端、全能的系统，而忽略了实际现状。主题专家更适合作为用户代表来配合需求分析员的工作。,2.2软件生命周期与软件需求工程过程,软件生命周期 最经典也是最早提出的软件生命周期模型是瀑布模型，它给出了一个系统的 严格顺序的软件幵发方法，每个阶段之间具体比较严格的划分，也有固定的制品 作为阶段幵始和结束的标志。其他软件生命周期模型包括，增量式模型，演化式 模型等，基本上都是在瀑布模型的基础上演化出来的。从瀑布模型上演化出来后 面的这些模型，是因为在实际的项目中很少能严格遵循这些活动之间的顺序。比 如，增量式模型是以迭代的方法运用瀑布模型，以解决不能一次性完成所有软件 需求，而必须以一种增量的方式不断丰富和完善软件产品。而演化式模型则用来 应对初始的软件需求没有明确的定义，需要不断与软件需求提供方沟通，逐步使 软件需求明确化和完整化，或者刻画软件系统随时间的推移而演化的过程。,软件生命周期,随着软件技术的进步和软件加强型系统应用深入和普及，瀑布模型本身也在 不断发展，如下图所示，早期的版本一般按分析、设计、编码、部署划分的生 命周期。而在(Pressman,2005)中的一个比较新的版本是按沟通、策划、建 模、构建和部署等五个阶段划分软件生命周期。从中不难看到，由于软件设 计和编码技术的发展和成熟，软件幵发的核心任务或活动已经转向与软件需求相 关的活动，在早期瀑布模型中，第一个活动“分析”与软件需求相关，而在后来 的瀑布模型中，有三个活动“沟通”、“策划”和“建模”都与软件需求相关。这 样的认识上的变化，一方面说明了软件需求工程的必要性已经得到普遍的汄可，另一方面也说明了软件需求工程的方法和技术将在软件幵发过程中起到越来越重 要的作用。,早期瀑布模型 更强调前期活动的瀑布模型,需求工程的过程,综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：（1）需求获取：深入实际，确定待开发的软件系统的用户类，通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；（2）需求分析及建模：主要对收集到的需求进行提炼、分析和认真审查，确保所有参加人员取得一致共识。找出错误、遗漏和不足，为最终用户所看到的系统建立模型，根据软件需求信息建立软件系统的逻辑模型或需求模型。需求模型作为对需求的抽象描述，尽可能多的捕获现实世界的语义，并确定非功能性需求和约束条件和限制。（3）形成需求规格：根据收集的需求信息和逻辑模型生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约编写需求规格说明及其文档。（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。当需求发生变更时，对需求规格说明及需求变更实施进行管理。需求工程也是一个项目工程，因此也包括了项目的管理。,2.3 需求获取,需求获取是需求工程的主体内容之一。获取需求是一个确定和理解不同涉众的需要和约束的过程。涉众团体(所有能够影响软件系统的实现,或者被实现后的软件系统所影响的个人和团体)之间的相互沟通，识别需要的过程。涉众团体通过这个过程提取、定义需求。需求获取既涉及技术问题，也涉及社会交往问题。难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确的；存在默认的知识,如难以描述的常识问题；存在多个知识源,且多知识源之间可能有冲突；客户可能的偏见，如不能提供或不想告知你所需要了解的事情。,案例,3个月前，甲新加入一家公司。很快他进入到一个项目里，这个项目是为某公司提供一个信息管理系统，主要是管理供应商的情况。当时项目刚处于初期，主要是获取需求，做DEMO，然后去为客户作演示。其中主要是甲做开发。甲以前主要一直做系统的开发和设计工作，加入这个项目后，公司希望他作为项目的PM，来推动这个项目往前走。然而,甲对这个客户行业（某工程行业）非常不了解，因此对获取需求毫无办法，虽然他也希望能参考一些类似的系统，但一直没有找到。所以基本上就是公司有客户关系的人零零碎碎的发过一些需求，然后他去照着做。最近，客户终于认为甲做的系统并不适合他们。所以这个项目可以说是失败了，于是，公司认为甲没有达到要求，解除了合同。,需求获取的过程：,确定需求开发计划,建立项目前景与范围,确定调查对象,实地收集用户需求信息,确定非功能需求和约束条件,2.3.1 确定需求开发计划,确定需求开发计划的基本任务是确定需求开发的实施步骤，给出收集需求活动的人员、具体安排和进度。需要重点注意的是：针对不同层次的调查对象，安排的调查人员在阅历和经验上的对等原则。调查人员的沟通和业务理解能力必须适当。用户的时间延误、文档确认的时间要在计划进度中预留。,确定产品前景与项目范围,本阶段的任务是帮助投资管理人、产品经理弄清楚“为什么要作这个项目？”，组织的业务目标以及系统最终版本具备哪些功能的长远规划。产品前景（product vision）描述了产品用来干什么，它最终会是什么样子。项目范围（project scope）确定当前的项目要解决产品长远规划中的哪一部分。项目范围的细节体现于项目定义的需求基线。产生文档：前景与范围文档。,前景与范围的关系,前景关系到整个产品。当产品的战略定位或业务目标随时间发生改变时，前景也会变化。范围则只与一个特定项目，或实现产品功能下一增量的某次迭代相关。产品前景包括了每一个计划产品版本的范围,通过业务需求定义前景,回顾：业务需求（business requirement）表示组织或客户高层次的目标。来源：项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。内容：描述了组织为什么要开发一个系统，即组织希望达到的目标。记述位置：使用前景和范围（vision and scope）文档来记录业务需求。如描述客户或开发组织通过产品可获得的商业利益。我们可以说 市场份额提高X%，每年可获利润X，减少成本X,前景和范围文档的模板,1.业务需求1.1 背景1.2 业务机遇1.3 业务目标与成功标准1.4 客户和市场需要1.5 业务风险2.解决方案的前景2.1 前景陈述2.2 主要的系统特征2.3 假设和依赖条件,3.项目范围与限制 3.1 第一个版本的范围 3.2 各后续版本的范围 3.3 限制和排除条件4.业务背景 4.1 涉众档案 4.2 项目优先级 4.3 运行环境,2.3.3 确定调查对象,本阶段的基本任务是明确地确定来自不同层次的需求来源和用户，并将其分类。(前景与范围文档可以帮助区分用户分类)由于软件需求分为三个层次，业务需求、用户需求、功能需求，故应根据需求的层次来区分不同的用户。用户分类：可分为三种不同类别 用户方的领导者、项目规划者、项目出资人(目标)软件的直接使用、操作人员（功能,易用性）未来软件系统的技术管理、运行维护人员（性能,安装,维护）,2.3.4 实地收集用户需求信息,实地收集需求信息面临的困难1）能提出软件需求的用户没有时间2）有时用户希望通过简单的说明和问答3）用户和开发人员只考虑自己的利益4）用户本身不能提出明确的需求5）开发人员缺乏用户的业务知识，而用户缺乏计算机方面的知识，引起交流困难。,实地调查的步骤,1）向掌握“全局”的负责人调查：概貌,规划,目标,范围2）向部门负责人调查：业务和业务流程,部门间相互关系。功能需求和非功能需求,与其他部门间的接口。3）向业务人员调查：自身工作处理细节、具体数据或表格的作用来源和去向、类型、精度、处理要求和输入/输出格式。具体的功能和性能需求。,2023/9/16,30,实地收集需求信息的方式,需求获取可能是软件开发中最需要交流的一项工作。获取涉众的需求是需求工作的重要环节。需求获取只有通过客户与开发者的有效合作才能成功。分析者必须为客户建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的产品有关。另外要让用户明确了解，对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，消除不必要的需求，以避免项目范围无意义地膨胀。目前主要有以下的需求获取方法。,面谈法 重要而直接，简单的需求获取技术。面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；2）面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。提问题：a.你所在部门的业务流程是怎样的？b.你所在部门与其它部门的关系是怎样的？c.本部门产生哪些表格及其输入/输出形式？d.在业务中使用什么计算方法？关于如何解决问题的提问：a.当某问题发生时，应该如何解决？b.你现在工作中存在什么问题？如何解决？c.除了正常情况，还会发生什么异常情况？该如何应对？,实地收集需求信息的方式,面谈法,优点能采集到丰富的信息缺点不同的回答难以比较交谈的技巧很难掌握注意三种问题需要避免：固执己见的问题、带偏见的问题、强加的问题经验性知识不好谈出来交谈者的态度会影响交谈的结果,直接表达了自己的关于这个问题的观点：“我们必须”,同上，但观点明显有偏见：“我们不做，对吗？”,假设了问题的答案：“你是用这种方式做，对吗？”,交谈形式举例,正向模拟：选择典型业务情景（初始情况），请用户说明工作过程；陈述过程中不断提炼并提问新情况案例分析：请用户选择有代表性的业务情景（初始情况），并说明工作过程；陈述过程中不断提炼并提问新情况局外评论：存在现有系统，请用户对正在进行的过程进行评论知识反教：在获取一些信息后，按照自己的理解表述给用户，请用户判断正确与否,问卷法调查法 是对面谈法的补充。是从多个用户中收集需求信息的有效方式，一般问卷设 计形式：1）多项选择问题；2）评分问题；3）排序问题。,实地收集需求信息的方式,需求专题讨论会 最有力的需求获取技术。有利于培养高效团队。由开发方和用户方共同召开,操作步骤：开发方根据双方制定的需求调研计划召开相关需求主题沟通会；会后开发方整理出需求调研记录提交给用户方确认；如果此主题还有未明确的问题则再次沟通,否则开始下一主题；所有需求都沟通清楚后，开发方根据历次需求调研记录整理出用户需求说明书，提交给用户方确认签字。会前发议题，控制参会人员规模、时间、讨论范围，会中有记录，会后整理。掌握方向不跑题。,实地收集需求信息的方式,需求信息的分类,如图列出9种需求类别：,业务规则（领域需求）,当客户说只有特定的人在特定的条件下才能执行某一动作时，他也许是在描述一条业务规则。业务规则举例：产品必须符合某项国际（或国家）标准。必须根据（某个公式）计算。如果（满足某一条件），则（进行某事）。功能性需求 功能性需求描述了系统在特定条件下表现的可观察的行为，以及系统允许用户执行的操作。如：所有的用户界面操作都属于功能性需求。功能性需求占据了软件需求规格说明的大部分篇幅。,质量属性,产品的易用性、可靠性、运行速度、出错频率、异常处理能力等等特性合称为质量属性，它是系统非功能性需求的一部分。非功能需求是衡量软件能否良好运行的定性指标。举例：可靠性：规定条件下系统完成所要求功能的概率。定量指标如平均无故障时间和平均修复时间。可扩充性：系统能方便和容易地增加新功能，可用增加新功能所需工作量大小来衡量。安全性：如防止非法访问,防止数据丢失，防止病毒入侵等。例如：身份验证、用户权限、访问控制等。,互操作性：指系统与其他系统交换数据和服务的难易程度。健壮性：指系统或组成部分遇到非法输入数据以及在异常情况和非法操作下能继续运行的程度。易用性：指用户学习和使用软件系统功能的简易程度,也包括对系统输出结果的易于理解的程度。可维护性：指系统中发现并纠正一个故障或进行一次更改的简易程度。可移植性：指把一个软件系统从一种运行环境移植到另一个运行环境所花费的工作量的度量。可重用性：指组成软件系统中的某个部件还可以在其他应用系统中使用的程度。,可维护性：指系统中发现并纠正一个故障或进行一次更改的简易程度。可移植性：指把一个软件系统从一种运行环境移植到另一个运行环境所花费的工作量的度量。可重用性：指组成软件系统中的某个部件还可以在其他应用系统中使用的程度。,外部接口需求描述了系统与外部世界的联系。软件需求规格说明中专门有一章描述系统与用户、硬件、其它软件系统之间接口的说明。,约束,对设计和实现的约束合理地限制了开发人员可用的选择。如：通过电子邮件传送的文件大小不能超过10MB。进行安全交易时，必须使用128位的加密算法。产品数据库必须支持Oracle 11g,其他约束,性能需求：声明各种系统操作特定的性能需求。例如：如果对数据库响应时间要求很严格，会指定:每秒钟支持处理的交易量 响应时间 运算精度 和实施系统的定时关系还应指定:内存和磁盘空间需求 并发的用户负载 或者数据库表中所能存储的最大行数,尽可能具体量化性能需求,例如:在一台单用户使用的运行Windows XP操作系统、主频2.4GHz的Pentium PC上，当系统至少有60%空闲资源时，要求95%的目录数据库查询必须在3秒内完成”。,因此系统应该具备以下功能：基本数据维护功能 基本业务功能 数据库管理功能 信息查询功能,例：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。,1.功能需求基本数据维护功能：提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。基本业务功能：读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，如果书籍已经借出，可以进行预留操作，书籍的编目、入库、更新等操作。,数据库管理功能：对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。信息查询功能：提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息，预留信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。,2.非功能需求 系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。对系统查询速度的需求：要求系统在20S之内响应查询服务请求。对系统可靠性的需求：要求系统失败发生率小于1%。,3.业务规则（领域需求）例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：图书编目要求按照中国图书馆分类法进行；由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。,作业：假设让你开发一个搜索引擎网站，选择任意3种需求类别进行描述。,2.4 需求分析,需求分析和需求获取是密切相关的两个过程。需求分析的任务就是分析和综合通过需求获取阶段收集到的需求信息，提炼出真正的需求，确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立系统完整的逻辑模型。需求分析是一种提炼与整合活动：需将用户的原始需求合并到业务活动中去。需求分析是一种规格化活动：要找到冲突、矛盾，并通过访谈手段解决问题。,划分需求优先级的用处：可帮助判断系统的核心需求，可用于风险分析。优先级之间的关联可以帮助决定软件体系结构、解决设计冲突。帮助权衡项目范围、进度安排、预算、人力资源及质量目标要求。使用方法：接受一个高优先级的需求时，删除低优先级的需求，或将其推迟到下一版去实现。,2.5 需求建模,目的：需求建模的工作就是导出目标系统的逻辑模型，以明确目标系统“做什么”的问题。定义：所谓模型就是为了理解事务而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。组成：通常模型可由图形符号或数字符号以及组织这些符号的规则组成。注意：建立需求模型的目的是为了增强对用自然语言描述的需求规格说明的理解，而不是替换它。,软件工程中常用模型分类开发过程模型：瀑布、增量、螺旋模型等(规约性)信息流模型：DFD、SADT等(描述性)设计模型：类图、功能层次图等交互作用模型：实例图、交互作用图、时序图等状态迁移模型：状态图、Statecharts、Petri网等用于构造细节的原理模型：设计模式、实体关联图等,建立数据词典,所谓数据词典是定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、格式和度量单位、精度及允许取值范围的共享数据仓库。数据词典的作用是使用统一的数据定义，提高可跟踪性。为避免冗余和不一致性，每个项目建立一个数据词典。,2.6 需求文档,需求规格说明书的作用在于：提供一个用户和开发者对开发软件的共同的理解；相当于用户和开发单位之间的一份技术合同；是今后各阶段设计的基本依据，起到控制系统演进的作用；是今后验收测试阶段对软件进行确认和验收的基准。,2.6 需求文档,需求规格说明书主要内容：概述。从系统的角度描述软件的目标和任务。数据描述 数据流图 数据字典 系统接口说明 内部接口说明 功能描述 功能 处理 设计的限制,2.6 需求文档,性能描述 性能指标 测试种类 预期的软件响应性能 其它 参考文献目录 附录,(一)需求验证的重要性 由于需求是软件开发的第一阶段，直接影响后面各阶段的开发。,做什么,怎么做,2.7 需求的有效性验证,(二)需求验证的内容1.有效性检查指功能需求是否符合用户所提出的需求2.一致性检查系统功能描述及约束是否一致。3.完备性检查是否包含所有系统用户的需求和约束。4.可检验性检查是否能设计出一组验证方法，确定了检验的标准。,2.7 需求的有效性验证,2.8需求管理,需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI 1995)。这种契约都包含在编写的需求规格说明与模型中，需求管理贯穿需求分析全过程 通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）。所谓的基线是配置演化过程中的状态标识，是配置在某一时刻的快照，反映了它所描述的系统或者其组成部分在某一时刻的状态；可以将配置的基线理解为配置的版本，是配置演化的里程碑，即软件生命周期内的阶段里程碑。,2.8 需求管理,评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。1)随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。2)市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。使当前的项目计划与需求一致。,估计变更需求所产生影响并在此基础上协商新的承诺(约定)。让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。需求跟踪的目的是建立与维护“需求设计编程测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式:正向跟踪：检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。在整个项目过程中跟踪需求状态及其变更情况。,2.8 需求管理,案例王先生刚出任项目经理，并承接了一个中型软件项目。上任时公司高层再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。王先生动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向王先生申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快王先生就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误,公司高层对项目的质量也疑虑重重。随后发生的事情让王先生更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，王先生只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问王先生：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”王先生委屈极了，疑惑自己到底错在哪里了。,小结,需求工程过程是一组活动的结构化序列，它产生用来说明待开发系统的需求文档。需求工程过程涉及需求抽取、需求分析和协商、和需求验证等活动。需求工程过程模型是从某个特定的角度出发构建的简化过程描述。需求抽取涉及对包含应用领域、要解决的问题、组织的需要和约束、以及系统相关者需要的辅助功能等在内的所有问题的理解。可以采用的技术包括面谈法、问卷法、情景法、软系统方法、原型法等。当出现需求重叠和冲突时需要进行需求协商。需求抽取、分析和协商是相互交织在一起的过程，在需求被所有需求相关者接受前，可能需要多次的重复。需求验证关注于检查需求文档的最终草案以发现其中的错误。最常用的需求验证方式是需求审查，检查表在组织需求验证过程中是一种有用的方式。原型法是需求验证的另一种有效的方法。需求变化是不可避免的，因而要求有有效的需求管理机制来管理这些变化。可追踪性信息记录了需求与需求的来源之间，需求之间，需求和系统设计之间等的依赖关系，这些依赖关系对变化影响分析至关重要。,