需求工程过程

需求工程过程第1页，课件共43页，创作于2023年2月迭代模型与瀑布模型的差别第2页，课件共43页，创作于2023年2月需求开发过程需求开发是一个迭代的过程第3页，课件共43页，创作于2023年2月需求工程的推荐方法列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。第4页，课件共43页，创作于2023年2月知识需求管理项目管理培训需求分析员对用户代表和管理者进行需求培训对开发者进行应用领域相关的培训创建术语表定义需求变更控制进程成立变更控制委员会分析需求变更的影响控制需求版本并为其建立基线维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性使用需求管理工具创建需求跟踪矩阵选择合适的开发周期根据需求制订项目计划重新协商权利或义务管理需求风险跟踪需求耗费的人力物力回顾以往的教训需求获取需求分析编写规格说明需求验证定义需求开发过程定义项目前景和范围确定用户群选择用户代言人建立核心队伍确定用例确定系统事件和响应举行进一步需求获取的讨论观察用户如何工作检查问题报告重用需求绘制关联图创建原型分析可行性确定需求优先级为需求建模创建数据字典将需求分配至各子系统应用质量功能调度采用SRS模板确定需求来源惟一标识每项需求记录业务规范定义质量属性审查需求文档测试需求确定合格标准第5页，课件共43页，创作于2023年2月知识技能开发者也应该了解产品应用领域中的基本概念和术语。培训需求分析员所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。对用户代表和管理者进行软件需求培训参与软件开发的用户应该接受一到两天的需求工程方面的培训。对开发人员进行应用领域的相关培训为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。创建项目术语表定义应用领域专业名称的术语表可以减少误解。第6页，课件共43页，创作于2023年2月需求获取需求获取(requirementelicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。第7页，课件共43页，创作于2023年2月需求获取第1章讨论了需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。同时你也需要获取非功能需求，如质量属性。1)确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。2)编写项目视图和范围文档

项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。3)将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。第8页，课件共43页，创作于2023年2月4)选择每类用户的产品代表

5)建立起典型用户的核心队伍

6)让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述—使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。7)召开应用程序开发联系（JAD）会议应用程序开发联系（JAD）会议是范围广的、简便的专题讨论会（workshop），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践第9页，课件共43页，创作于2023年2月8)分析用户工作流程观察用户执行业务任务的过程9)确定质量属性和其它非功能需求10)通过检查当前系统的问题报告来进一步完善需求11)跨项目重用需求。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能⋯⋯”,”当⋯⋯时，将会发生什么”“你有没有曾经想过⋯⋯”,“有没有人曾经⋯⋯”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。第10页，课件共43页，创作于2023年2月需求分析分析:通过对问题域的研究,获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并用文档说明.需求分析（requirementanalysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样你就能作出实用的项目估算并可以进行设计、构造和测试.通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。第11页，课件共43页，创作于2023年2月1)绘制系统关联图这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。2)创建用户接口原型当开发人员或用户不能确定需求时，开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。3)分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。4)确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。第12页，课件共43页，创作于2023年2月5)为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。6)创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。7)使用质量功能调配质量功能调配(QFD）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。期望需求；普通需求；兴奋需求.第13页，课件共43页，创作于2023年2月规格说明无论你的需求从何而来，也不管你是怎样得到的，你都必须用一种统一的方式来将它们编写成可视文档。业务需求要写成项目视图和范围文档。用户需求要用一种标准使用实例模板编写成文档。而软件需求规格说明（requirementspecification）则包含了软件的功能需求和非功能需求。你必须为每项需求明确建立标准的惯例，并确定在SRS中采用任何惯例，以确保SRS的统一风格，同时读者也会明白怎样解释它。第14页，课件共43页，创作于2023年2月1)采用SRS模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。2)指明需求的来源为了让所有项目风险承担者明白SRS中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。3)为每项需求注上标号制定一种惯例来为SRS中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。4)记录业务规范业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成SRS中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。5)创建需求跟踪能力矩阵建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。第15页，课件共43页，创作于2023年2月人机接口设计人机接口HMI面向人的或其他的系统第16页，课件共43页，创作于2023年2月需求验证验证是为了确保需求说明准确、完整地表达必要的质量特点。而且能够满足客户的需要。审查需求文档对需求文档进行正式审查是保证软件质量的有效手段之一。测试需求根据用户需求推导出功能测试用例，以便记录产品在特定条件下应有的行为。定义合格标准让用户描述决定产品是否满足他们的需求并适合使用的标准。第17页，课件共43页，创作于2023年2月1)审查需求文档2)以需求为依据编写测试用例3)编写用户手册4)确定合格的标准第18页，课件共43页，创作于2023年2月需求管理有了项目的初步需求，就必须处理好开发过程中不可避免的来自客户、管理层、营销部门、开发团队以及其他群体的变更请求。定义需求变更控制过程建立一个用于提议、分析和解决需求变更的过程。成立变更控制委员会可授权由涉众组成的小组作为变更控制委员会(CCB)来接收需求变更的请求。分析需求变更的影响对影响进行分析有助于CCB做出明智的业务决策。建立基线和控制需求文档的版本基线是由已经被提交到一个指定版本中的实现(implementation)的需求组成的。第19页，课件共43页，创作于2023年2月需求管理维护需求变更的历史记录记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。跟踪每项需求的状态建立一个数据库，为每一项功能需求保存一条记录。衡量需求的稳定性记录已设为基线的需求数，以及每周提议和批准的需求的变更(增加，修改，删除)数。使用需求管理工具商业需求管理工具可用于在数据库中存储各种类型的需求。创建需求跟踪矩阵建立一个表，把每项功能需求和实现它的设计和代码部分、验证它的测试部分联系起来。第20页，课件共43页，创作于2023年2月项目管理软件项目管理方法和项目的需求过程密切相关。应根据需要实现的需求来规划项目资源、进度和承诺。选择合适的软件开发生命周期组织应该定义多种开发生命周期，以适应不同的项目类型和不同程度的需求不确定性(McConnell1996)。根据需求制订项目计划当范围和详细的需求变得清楚时，应反复斟酌项目的计划和进度表。第21页，课件共43页，创作于2023年2月项目管理需求变更时重新讨论项目承诺将新的需求合并到项目中时，应估计一下你是否仍然可以利用可用资源兑现当前的进度和质量承诺。管理与需求相关的风险以及编写风险文档确定与需求相关的风险并将它们编写成文档是项目风险管理活动的一部分。跟踪需求工程的投入记录下你的团队在需求开发和管理活动上投入的工作量。从其他项目的需求工程中积累经验组建一个学术研究组织专门管理项目回顾(也称为项目的审阅)以收集有价值的信息。第22页，课件共43页，创作于2023年2月开始新实践将本章中描述的需求工程方法，按照对大多数项目的相对影响以及实现的相对难度进行分组。

第23页，课件共43页，创作于2023年2月影响难度高中低高

l

定义需求开发过程

l

以

需求为基础制定计划

l

重新讨论项目承诺

l

确定用例

l

指定质量属性

l

确定需求优先级

l

采用SRS模板

l

定义变更控制过程

l

建立CCB

l

审查需求文档

l

给子系统分配需求

l

记录业务规则

l

在

应用领域培养开发者

l

定义项目前景和范围

l

用户群分类

l

绘制关联图

l

确定需用求来源

l

建立需求基线和控制版本

l

对用户群和管理者进行需求培训

l

为需求建立模型

l

管理需求风险

l

使用需求管理工具

l

创

建需求跟踪能力矩阵

l

召开需求获取讨论会

l

培训需求分析员

l

选择用户代言人

l

建立核心队伍

l

创建原型

l

定义合格标准

l

进行变更影响分析

l

选择适当的开发周期

l

分析可行性

l

创建术语表

l

编写数据字典

l

观察用户执行工作的过程

l

确定系统事件及响应

l

为每项需求注上惟一的标号

l

测试需求

l

跟踪需求状态

l

回顾过去的经验教训

低

l

重用需求

l

应用质量功能调配

l

衡量需求稳定性

l

维

护需求变更的历史记录

l

跟踪投入需求工程中的工作量

l

检查问题报告

第24页，课件共43页，创作于2023年2月需求过程的改进第25页，课件共43页，创作于2023年2月1需求与其他项目过程的联系需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。对需求开发方法和需求管理方法的变更会对项目的其他过程产生影响，反之亦然。图1演示了需求和其他过程之间的某些连接，下面简要介绍一下这些过程之间的接口。项目规划

需求是项目规划过程的基

础。第26页，课件共43页，创作于2023年2月需求与其他项目过程的联系

项目跟踪和控制项目跟踪包括监视每一个需求的状态。变更控制将一组需求集确定为基线之后，以后的所有变更都应该通过一个预先定义好的变更控制过程来完成，这一过程有助于确保：理解所提议的变更产生的影响。由合适的人选作出接受变更的正式决定。所有受变更影响的人得到关于发生变更的通知。根据需要对项目资源和所做出的承诺进行调整。保持需求文档是最新版本，并且是准确的。系统测试用户需求和功能性需求是系统测试必不可少的参考依据。构造通过跟踪需求，可以对从每条需求中衍生出来的特定的软件设计和编码元素编写文档。编写用户文档产品需求是用户文档编写过程的依据。第27页，课件共43页，创作于2023年2月2需求和各涉众组图2展示了与软件开发组有联系的某些项目涉众，也展示了他们对项目需求工程活动产生的某些影响。第28页，课件共43页，创作于2023年2月2需求和各涉众组当软件开发团队变更其需求过程时，与其他项目涉众进行沟通的接口也会发生变化。下面列出了可能会遇到的一些抵制情况：变更控制过程可能会被看作是开发工作的障碍而被丢弃，因此变更工作很难实施。有些开发人员认为编写和评审需求文档纯粹是浪费时间的官僚做法，妨碍他们的“真正”工作，即编写代码。如果用于客户支持的费用与开发过程没有联系，那么开发团队可能会缺少变更需求的动力。如果改进需求过程的目标之一是通过创建高质量的产品来减少技术支持费用，那么技术支持经理可能会感到很不安。忙碌的客户有时会声称，他们没有时间去从事需求工作。第29页，课件共43页，创作于2023年2月3软件过程改进的基本原则应该牢记下面4条软件过程改进的原则(Wiegers1996a)：1.过程改进应该是不断演化的、连续的、周期性的不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解决所有问题。2.只有人们和组织具有变更的动机时才可能实施变更下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力：项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。开发组织名誉受损，因为客户不接受交付的软件。第30页，课件共43页，创作于2023年2月3.过程变更要有的放矢在开始运用更好的过程之前，一定要明确变更的目标是什么(PotterandSakry2002)。4.将改进活动视作小型项目项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。第31页，课件共43页，创作于2023年2月4过程改进周期图3是一个有效的过程改进周期。这一方法反映了您在执行下一个任务之前先清楚自己所处位置的重要性；反映了绘制过程路线图的必要性，以及以往的经验在持续的过程改进中的重要性。第32页，课件共43页，创作于2023年2月4.1评估当前采用的方法所有改进活动的第1步都是评估组织当前所使用的方法，找出这些方法的优点和缺陷。评估当前过程的方法有多种。如果我们已经试过前几章末尾的“下一步”，实际上已经开始对需求方法及其结果进行了非正式评估了。设计结构化问卷表是一种更系统的方法，它能够以较低的费用对当前过程进行评估。与团队成员进行面谈和讨论，可以更准确更全面地了解当前的过程。我们可以采用问卷表来审查组织当前采用的需求工程方法。这种自我评估法有助于我们确定哪些需求过程最需要改进。第33页，课件共43页，创作于2023年2月4.2规划改进活动战略性计划描述了组织的总体软件过程改进，战术性的活动计划则描述需要改进的专门领域。需求管理改进计划，它包括下面这些活动条目：1.起草一个需求变更控制过程草案。2.评审并修订变更控制过程。3.在项目A中试验变更控制过程。4.根据试验的反馈信息，修订变更控制过程。5.评估问题跟踪工具，并从中选择一种工具来支持变更控制过程。6.购买并定制问题跟踪工具以支持变更控制过程。7.在组织中使用新的变更控制过程和工具。第34页，课件共43页，创作于2023年2月4.3建立、实验并实现新过程实现活动计划意味着开发一些过程，并相信这些过程比当前的工作方式会带来更好的结果，但不要期望新的过程第1次试用就很完美。请牢记下面这些关于指导过程实验的建议：选择实验参与者，他们将尝试新方法并提供有用的反馈信息。使改进过程的结果容易解释。确定需要了解实验情况和实验原因的有关涉众。考虑在不同的项目中实验新过程的不同部分，这样可以使更多的人尝试新方法，因此提高了了解程度，增加了反馈信息，更易于大家接受。询问实验参与者。第35页，课件共43页，创作于2023年2月4.4评估结果过程改进周期的最后一步是评估完成的活动和取得的成果，这种评估有助于团队在未来的改进活动中做得更好。评估内容包括判断实验进行得是否顺利，在解决新过程的不确定性方面是否有效，下一次指导过程实验时是否需要做些变更。同时还要考虑新过程的总体执行情况是否顺利，包括新过程或模板的可用性是否有效地传达给了每一个人，参与者是否理解并成功地应用了新过程，下次工作中是否需要有所变更等。其中关键的一步是，评估新实现的过程是否带来了期望的结果。第36页，课件共43页，创作于2023年2月5需求工程过程资产高性能项目在需求工程的各个阶段(需求获取、需求分析、编写需求规格说明、需求确认和需求管理)都有有效的过程。为了更方便地执行这些过程，每个组织都必须有一个过程资产(processassets)集合(Wiegers1998c)。过程资产包括表1中所描述的文档类型。类型描述检查清单

一张列表清单，它列举了活动、可交付产品或需要引起注意或验证的其他条目。检查清单是帮助记忆的一种方法，可以确保忙碌的人们不会遗漏重要的细节

范例

一种特定工作产品类型的代表。项目团队创建工作产品时应将优秀范例积累起来

计划

概括说明如何达到目标和达到目标需要哪些准备

政策

是一种指导原则，它陈述了管理层对行为、动作和交付工件的期望。过程应该满足这些政策

步骤

一步一步描述完成某个活动的任务序列，描述要执行的任务并确定执行这些任务的

项目角色。不要包括教程信息。指导文档可以为过程或步骤提供教程信息和帮助提

示

过程描述

用文档对为达到某些目的而执行的一组活动进行定义。过程描述可能包括过程目标、关键里程碑、参与者、交流步骤、输入和输出数据、与这一过程相关联的制品、以及对这一过程进行剪裁以适应不同的项目所用的方法(Caputo1998)

模板

所使用的一种模式，可用来指导产生完整的工作产品。关键项目文档的模板可以提醒我们有可能遗漏的一些问题。结构良好的模板会提供许多“栏目槽(slot)”，用于捕获和组织信息。内嵌在模板中的指导文本有助于文档作者有效地使用它

第37页，课件共43页，创作于2023年2月5.1需求开发过程资产需求开发过程这一过程描述了如何确定涉众、