需求工程过程优秀PPT.ppt

《需求工程过程优秀PPT.ppt》由会员分享，可在线阅读，更多相关《需求工程过程优秀PPT.ppt（42页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、迭代模型与瀑布模型的差别 需求开发过程需求开发是一个迭代的过程需求工程的举荐方法列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。知 识需求管理项目管理培训需求分析员对用户代表和管理者进行需求培训对开发者进行应用领域相关的培训创建术语表定义需求变更控制进程成立变更控制委员会分析需求变更的影响控制需求版本并为其建立基线维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性使用需求管理工具创建需求跟踪矩阵选择合适的开发周期根据需求制订项目计划重新协商权利或义务管理需求风险跟踪需求耗费的人力物力回顾以往的教训需求获取需求分析编写规格说明需求验证定义需求开发

2、过程定义项目前景和范围确定用户群选择用户代言人建立核心队伍确定用例确定系统事件和响应举行进一步需求获取的讨论观察用户如何工作检查问题报告重用需求绘制关联图创建原型分析可行性确定需求优先级为需求建模创建数据字典将需求分配至各子系统应用质量功能调度采用SRS模板确定需求来源惟一标识每项需求记录业务规范定义质量属性审查需求文档测试需求确定合格标准知 识 技 能开发者也应当了解产品应用领域中的基本概念和术语。培训需求分析员全部将要成为分析员的团队成员都应当接受需求工程方面的基本培训。娴熟的需求分析员应具备以下特点：耐性，思维条理性强，有良好的交际和沟通实力，理解产品应用领域，并且驾驭丰富的需求工程技术

3、。对用户代表和管理者进行软件需求培训参与软件开发的用户应当接受一到两天的需求工程方面的培训。对开发人员进行应用领域的相关培训为了帮助开发人员对应用领域有一个基本的理解，可以支配一个研讨课程，内容是客户的业务活动、术语和产品的目标。创建项目术语表定义应用领域专业名称的术语表可以削减误会。需求获得需求获得(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获得需求是一个确定和理解不同用户类的须要和限制的过程。需求获得可能是软件开发中最困难、最关键、最易出错及最须要沟通的方面。需求获得只有通过有效的客户开发者的合作才能成功。需求获得是在问题及其最终解决方案之间架

4、设桥梁的第一步。获得需求的一个必不行少的结果是对项目中描述的客户需求的普遍理解。需求获得第1章探讨了需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或运用实例），而全部的功能需求都应当源于用户需求。同时你也须要获得非功能需求，如质量属性。1)确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要赐予确定指导，这将有助于分析人员的工作，而且也使收集需求活动的支配和进度支配更简洁进行。2)编写项目视图和范围文档 项目视图和范围文档应

5、当包括高层的产品业务目标，全部的运用实例和功能需求都必需遵从能达到的业务需求。项目视图说明使全部项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。3)将用户群分类并归纳各自特点 为避开出现疏忽某一用户群需求的状况，要将可能运用产品的客户分成不同组别。他们可能在运用频率、运用特性、优先等级或娴熟程度等方面都有所差异。具体描述出它们的特性特点及任务状况，将有助于产品设计。4)选择每类用户的产品代表 5)建立起典型用户的核心队伍 6)让用户代表确定运用实例 从用户代表处收集他们运用软件完成所需任务的描述运用实例，探讨用户与系统间的交互方式和对话要求。在编写运用实例的文档时可接

6、受标准模版，在运用实例基础上可得到功能需求。7)召开应用程序开发联系（J A D）会议 应用程序开发联系（J A D）会议是范围广的、简便的专题探讨会（w o r k s h o p），也是分析人员与客户代表之间一种很好的合作方法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的探讨得以将客户与开发人员间的合作伙伴关系付诸于实践8)分析用户工作流程视察用户执行业务任务的过程9)确定质量属性和其它非功能需求 10)通过检查当前系统的问题报告来进一步完善需求11)跨项目重用需求。调查用户任务可能遇到的变更，或者用户须要运用系统其它可能的方式。想像你自己在学习用户的工作，你须要完成什么任务？你有什

7、么问题？从这一角度来指导需求的开发和利用。还有，探讨例外的状况：什么会阻碍用户顺当完成任务？对系统错误状况的反映，用户是如何想的？询问问题时，以“还有什么能”,”当时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。登记每一个需求的来源，这样向下跟踪直到发觉特定的客户。需求分析分析:通过对问题域的探讨,获得对该领域特性及存在于其中(须要解决)的问题特性的透彻理解并用文档说明.需求分析（requirement analysis）包括提炼、分析和细致审查已收集到的需求，以确保全部的风险担当者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否全部的需求和软件需求

8、规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样你就能作出好用的项目估算并可以进行设计、构造和测试.通常，把需求中的一部分用多种形式来描述，犹如时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法供应的。分析还包括与客户的沟通以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保全部风险担当者尽早地对项目达成共识并对将来的产品有个相同而清晰的相识。1)绘制系统关联图 这种关联图是用于定义系统与系统外部实体间的界限和接口的简洁模型。同时它也明确了通过接口的信息流和物质流。2)创建用户接口原型 当开发人员或用户不能确定需求时，开发一

9、个用户接口原型一个可能的局部实现这样使得很多概念和可能发生的事更为直观明白。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。留意要找出需求文档与原型之间全部的冲突之处。3)分析需求可行性 在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依靠和技术障碍。4)确定需求的优先级别 应用分析方法来确定运用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本支配中作出须要的变更。5)为需求建立模型 需求的图形分析模型是软件

10、需求规格说明极好的补充说明。它们能供应不同的信息与关系以有助于找到不正确的、不一样的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。6)创建数据字典 数据字典是对系统用到的全部数据项和结构的定义，以确保开发人员运用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是运用一样的定义和术语。分析和设计工具通常包括数据字典组件。7)运用质量功能调配 质量功能调配(Q F D）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术供应了一种分析方法以明确那些是客户最为关注的特性。期望需求；一般需求；兴奋需求.

11、规格说明无论你的需求从何而来，也不管你是怎样得到的，你都必需用一种统一的方式来将它们编写成可视文档。业务需求要写成项目视图和范围文档。用户需求要用一种标准运用实例模板编写成文档。而软件需求规格说明（requirement specification）则包含了软件的功能需求和非功能需求。你必需为每项需求明确建立标准的惯例，并确定在S R S中接受任何惯例，以确保S R S的统一风格，同时读者也会明白怎样说明它。1)接受S R S模板 在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息供应了统一的结构。2)指明需求的来源 为了让全部项目风险担当者明

12、白S R S中为何供应这些功能需求，要都能追溯每项需求的来源，这可能是一种运用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。3)为每项需求注上标号 制定一种惯例来为S R S中的每项需求供应一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。4)记录业务规范 业务规范是指关于产品的操作原则，比如谁能在什么状况下实行什么动作。将这些编写成S R S中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。5

13、)创建需求跟踪实力矩阵 建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪实力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最终才去补建。人机接口设计人机接口HMI面对人的或其他的系统需求验证验证是为了确保需求说明精确、完整地表达必要的质量特点。而且能够满足客户的须要。审查需求文档对需求文档进行正式审查是保证软件质量的有效手段之一。测试需求依据用户需求推导出功能测试用例，以便记录产品在特定条件下应有的行为。定义合格标准让用户描述确定产品是否满足他们的需求并适合运用的标准。1)审查需求文档2)以需求为依据编写测试用例3)编

14、写用户手册4)确定合格的标准需 求 管 理有了项目的初步需求，就必需处理好开发过程中不行避开的来自客户、管理层、营销部门、开发团队以及其他群体的变更恳求。定义需求变更限制过程建立一个用于提议、分析和解决需求变更的过程。成立变更限制委员会可授权由涉众组成的小组作为变更限制委员会(CCB)来接收需求变更的恳求。分析需求变更的影响对影响进行分析有助于CCB做出明智的业务决策。建立基线和限制需求文档的版本基线是由已经被提交到一个指定版本中的实现(implementation)的需求组成的。需 求 管 理维护需求变更的历史记录记录需求规格说明变更的日期、变更的内容、变更的实施者和缘由。跟踪每项需求的状态

15、建立一个数据库，为每一项功能需求保存一条记录。衡量需求的稳定性记录已设为基线的需求数，以及每周提议和批准的需求的变更(增加，修改，删除)数。运用需求管理工具商业需求管理工具可用于在数据库中存储各种类型的需求。创建需求跟踪矩阵建立一个表，把每项功能需求和实现它的设计和代码部分、验证它的测试部分联系起来。项 目 管 理软件项目管理方法和项目的需求过程亲密相关。应依据须要实现的需求来规划项目资源、进度和承诺。选择合适的软件开发生命周期组织应当定义多种开发生命周期，以适应不同的项目类型和不同程度的需求不确定性(McConnell 1996)。依据需求制订项目支配 当范围和具体的需求变得清晰时，应反复斟

16、酌项目的支配和进度表。项 目 管 理需求变更时重新探讨项目承诺将新的需求合并到项目中时，应估计一下你是否仍旧可以利用可用资源兑现当前的进度和质量承诺。管理与需求相关的风险以及编写风险文档确定与需求相关的风险并将它们编写成文档是项目风险管理活动的一部分。跟踪需求工程的投入记录下你的团队在需求开发和管理活动上投入的工作量。从其他项目的需求工程中积累阅历组建一个学术探讨组织特地管理项目回顾(也称为项目的批阅)以收集有价值的信息。起先新实践将本章中描述的需求工程方法，依据对大多数项目的相对影响以及实现的相对难度进行分组。影影 响响 难难 度度 高高 中中 低低 高高 l l 定义需求开发过程定义需求开

17、发过程 l l 以以 需求为基础制定需求为基础制定 计计划划 l l 重新讨论项目承诺重新讨论项目承诺 l l 确定用例确定用例 l l 指定质量属性指定质量属性 l l 确定需求优先级确定需求优先级 l l 采用采用SRSSRS模板模板 l l 定义变更控制过程定义变更控制过程 l l 建立建立CCBCCB l l 审查需求文档审查需求文档 l l 给子系统分配需求给子系统分配需求 l l 记录业务规则记录业务规则 l l 在在 应用领域培养开发者应用领域培养开发者 l l 定义项目前景和范围定义项目前景和范围 l l 用户群分类用户群分类 l l 绘制关联图绘制关联图 l l 确定需用求来

18、源确定需用求来源 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 选择适当的开发周期选择适当的

19、开发周期 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 跟踪投入需求工程中的工作量跟踪投入需求工程中的工作量

20、l l 检查问题报告检查问题报告 需求过程的改进1 需求与其他项目过程的联系需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。对需求开发方法和需求管理方法的变更会对项目的其他过程产生影响，反之亦然。图1演示了需求和其他过程之间的某些连接，下面简要介绍一下这些过程之间的接口。项目规划 需求是项目规划过程的基础。需求与其他项目过程的联系 项目跟踪和限制项目跟踪包括监视每一个需求的状态。变更限制 将一组需求集确定为基线之后，以后的全部变更都应当通过一个预先定义好的变更限制过程来完成，这一过程有助于确保：理解所提议的变更产生的影响。由合适的人选作出接受变更的正式确定。全部受变更影响的人得

21、到关于发生变更的通知。依据须要对项目资源和所做出的承诺进行调整。保持需求文档是最新版本，并且是精确的。系统测试 用户需求和功能性需求是系统测试必不行少的参考依据。构造通过跟踪需求，可以对从每条需求中衍生出来的特定的软件设计和编码元素编写文档。编写用户文档产品需求是用户文档编写过程的依据。2 需求和各涉众组图2展示了与软件开发组有联系的某些项目涉众，也展示了他们对项目需求工程活动产生的某些影响。2 需求和各涉众组当软件开发团队变更其需求过程时，与其他项目涉众进行沟通的接口也会发生变更。下面列出了可能会遇到的一些抵制状况：变更限制过程可能会被看作是开发工作的障碍而被丢弃，因此变更工作很难实施。有些

22、开发人员认为编写和评审需求文档纯粹是奢侈时间的官僚做法，阻碍他们的“真正”工作，即编写代码。假如用于客户支持的费用与开发过程没有联系，那么开发团队可能会缺少变更需求的动力。假如改进需求过程的目标之一是通过创建高质量的产品来削减技术支持费用，那么技术支持经理可能会感到很担忧。劳碌的客户有时会声称，他们没有时间去从事需求工作。3 软件过程改进的基本原则应当牢登记面4条软件过程改进的原则(Wiegers 1996a)：1.过程改进应当是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解决全部问题。2.只有人们和组织具有变更的动机时才可能实施变更下面列出了

23、一些典型的问题，或许能为需求过程的变更供应驱动力：项目超出了最终期限，缘由是需求比预期的扩展了很多，也困难了很多。开发人员频繁加班，缘由是直到开发后期才发觉了引起误会的需求和表达不明确的需求。系统测试工作前功尽弃，缘由是测试人员并没有弄清晰产品应当做什么。虽然正确的功能都实现了，但是用户不满足，这是由于性能不好、易运用性差或存在其他质量缺陷。维护费用很高，因为客户的对产品的很多增加要求没有在需求获得阶段确定下来。开发组织名誉受损，因为客户不接受交付的软件。3.过程变更要有的放矢在起先运用更好的过程之前，确定要明确变更的目标是什么(Potter and Sakry 2002)。4.将改进活动视作

24、小型项目项目的总体支配应当包括过程改进的资源和任务。与全部项目一样，改进项目也要执行支配、跟踪、测量和报告，只是规模相应地缩小了。4 过程改进周期图3是一个有效的过程改进周期。这一方法反映了您在执行下一个任务之前先清晰自己所处位置的重要性；反映了绘制过程路途图的必要性，以及以往的阅历在持续的过程改进中的重要性。4.1评估当前接受的方法全部改进活动的第1步都是评估组织当前所运用的方法，找出这些方法的优点和缺陷。评估当前过程的方法有多种。假如我们已经试过前几章末尾的“下一步”，事实上已经起先对需求方法及其结果进行了非正式评估了。设计结构化问卷表是一种更系统的方法，它能够以较低的费用对当前过程进行评

25、估。与团队成员进行面谈和探讨，可以更精确更全面地了解当前的过程。我们可以接受问卷表来审查组织当前接受的需求工程方法。这种自我评估法有助于我们确定哪些需求过程最须要改进。4.2 规划改进活动战略性支配描述了组织的总体软件过程改进，战术性的活动支配则描述须要改进的特地领域。需求管理改进支配，它包括下面这些活动条目：1.起草一个需求变更限制过程草案。2.评审并修订变更限制过程。3.在项目A中试验变更限制过程。4.依据试验的反馈信息，修订变更限制过程。5.评估问题跟踪工具，并从中选择一种工具来支持变更限制过程。6.购买并定制问题跟踪工具以支持变更限制过程。7.在组织中运用新的变更限制过程和工具。4.3

26、 建立、试验并实现新过程实现活动支配意味着开发一些过程，并信任这些过程比当前的工作方式会带来更好的结果，但不要期望新的过程第1次试用就很完备。请牢登记面这些关于指导过程试验的建议：选择试验参与者，他们将尝试新方法并供应有用的反馈信息。使改进过程的结果简洁说明。确定须要了解试验状况和试验缘由的有关涉众。考虑在不同的项目中试验新过程的不同部分，这样可以使更多的人尝试新方法，因此提高了了解程度，增加了反馈信息，更易于大家接受。询问试验参与者。4.4 评估结果过程改进周期的最终一步是评估完成的活动和取得的成果，这种评估有助于团队在将来的改进活动中做得更好。评估内容包括推断试验进行得是否顺当，在解决新过

27、程的不确定性方面是否有效，下一次指导过程试验时是否须要做些变更。同时还要考虑新过程的总体执行状况是否顺当，包括新过程或模板的可用性是否有效地传达给了每一个人，参与者是否理解并成功地应用了新过程，下次工作中是否须要有所变更等。其中关键的一步是，评估新实现的过程是否带来了期望的结果。5 需求工程过程资产高性能项目在需求工程的各个阶段(需求获得、需求分析、编写需求规格说明、需求确认和需求管理)都有有效的过程。为了更便利地执行这些过程，每个组织都必需有一个过程资产(process assets)集合(Wiegers 1998c)。过程资产包括表1中所描述的文档类型。类 型 描 述 检查清单 一张列表清

28、单，它列举了活动、可交付产品或需要引起注意或验证的其他条目。检查清单是帮助记忆的一种方法，可以确保忙碌的人们不会遗漏重要的细节 范例 一种特定工作产品类型的代表。项目团队创建工作产品时应将优秀范例积累起来 计划 概括说明如何达到目标和达到目标需要哪些准备 政策 是一种指导原则，它陈述了管理层对行为、动作和交付工件的期望。过程应该满足这些政策 步骤 一步一步描述完成某个活动的任务序列，描述要执行的任务并确定执行这些任务的 项目角色。不要包括教程信息。指导文档可以为过程或步骤提供教程信息和帮助提 示 过程描述 用文档对为达到某些目的而执行的一组活动进行定义。过程描述可能包括过程目标、关键里程碑、参

29、与者、交流步骤、输入和输出数据、与这一过程相关联的制品、以及对这一过程进行剪裁以适应不同的项目所用的方法(Caputo 1998)模板 所使用的一种模式，可用来指导产生完整的工作产品。关键项目文档的模板可以提醒我们有可能遗漏的一些问题。结构良好的模板会提供许多“栏目槽(slot)”，用于捕获和组织信息。内嵌在模板中的指导文本有助于文档作者有效地使用它 5.1 需求开发过程资产需求开发过程这一过程描述了如何确定涉众、用户类和用户代言人，还描述了如何规划需求获得活动，包括选择合适的需求获得技术、确定参与者和估算需求获得须要的工作量和工作日。需求安排步骤在安排需求之前，要先完成系统级需求的说明，并完

30、成系统体系结构的定义。这一步骤描述了如何执行这些安排，以确保将功能安排给合适的组件来实现。需求优先级设定步骤为了在固定不变的进度支配下，合理地缩小需求范围或者适应需求的增加，了解支配实现的哪些系统功能具有最低的优先级。5.1 需求开发过程资产前景和范围模板前景和范围文档简明扼要地对新产品的业务需求进行了总体描述，并为设定需求优先级和需求变更供应决策参考。用例模板用例模板供应了一个标准形式，描述了用户期望软件系统必需执行的任务。软件需求规格说明模板软件需求规格说明模板供应了一种结构化的一样的方法，将产品的功能性需求和非功能性需求组织起来。软件需求规格说明和用例缺陷检查清单需求文档的正式审查是确保

31、软件质量的一种强有力的技术。5.2 需求管理过程资产需求管理过程这一过程描述了项目团队实行哪些行动来处理变更、区分需求文档的不同版本、跟踪并报告需求状态、以及收集跟踪信息。变更限制过程好用的变更限制过程可以削减因没完没了的、难以限制的需求变更而引起的混乱。需求状态跟踪步骤需求管理包括监视和报告每一个功能性需求的状态。5.2 需求管理过程资产变更限制委员会规章变更限制委员会(change control board，CCB)是由项目涉众组成的一个团体，它负责确定批准或推翻哪些提议的需求变更，以及每个批准的变更在哪个产品版本中实现。需求变更影响分析检查清单和模板在确定是否批准提议的需求变更时，估计变更所需的费用和造成的其他影响是至关重要的一步。需求跟踪步骤需求跟踪矩阵列出了全部功能性需求、针对每一个需求的设计组件和代码模块、以及验证其正的确现的测试用例。6 需求过程改进路途图开发一个路途图，用于在组织内实现改进的需求方法。这一路途图是过程改进战略支配的一部分。因为具体状况各不相同，所以无法供应一种放之四海而皆适用的路途图。过程改进的公式化方法并不能取代细致思索和一般常识。图7演示了一个组织用于改进需求过程的路途图。需求开发和管理过程的积累材料