ibmrequirementsmanagement管理需求

RequirementsManagementUsingIBMRationalRequisitePro(使用使用使用使用IBMRationalRequisitePro管理需求管理需求管理需求管理需求)作者：PeterZielczynski译者：周甫前言前言前言前言本书译自IBMPress的RequirementsManagementUsingIBMRationalRequisitePro(中文：使用IBMRationalRequisitePro管理需求)作者：PeterZielczynski译者：周甫E-mail:[e-mail]全书共4部分15章节，共359页。版权声明：版权归原作者所有虽然书名是使用RequisitePro，但重点在需求管理上,特别是书中所述的金字塔式需求管理特别有助于项目开发。感于国内这种实战书籍太少，因此尝试翻译，以方便大家学习和阅读。本人英语水平有限，第一次翻译书籍，难免错漏百出，见谅！最新章节概述1需求管理2RequisitePro概述Chapter1需求管理需求管理需求管理需求管理本章首先定义需求和涉众(stakeholders)的概念，我们将了解哪些类型的需求可以列举在项目中，这些需求的关系看来就像一个金字塔。同时还会介绍需求跟踪的概念(需求是从如何逐步分解的)、如何呈现好的需求的特征、如何甄别有问题的需求等。本章还描述了在项目生命周期中需求管理的步骤，这些步骤涵盖了需求金字塔自顶而下的全过程。1.1定义需求和涉众定义需求和涉众定义需求和涉众定义需求和涉众需求的定义是：系统必须提供的能力或者环境,它有如下含义：•为了解决客户（用户）的问题或者达到客户的目标所需要的能力•系统通过合同，标准，规范，规则或者其他正式文档来实现这个能力•约束由涉众设定涉众的概念在本书中多次出现,所以先来定义它。通常的涉众定义为谁受这即将要开发的系统所影响，涉众有用户和客户二种类型.用户是使用系统的人，客户是对系统发出要求并从中获得理想答案的人.一般来说,客户支付系统的研发费用.这对于辨别涉众的二种类型是至关重要,因为来自这二种涉众的需求有时会互为矛盾,在大多数这类矛盾中，客户的要求略占上风。在本书所用的在线旅行社（译注：类似携程，E龙之类）网站(OnlineTravelAgency)示例中,客户就是这个在线旅行社的所有者，用户泛指那些通过互联网络使用本网站的人。除了客户和用户这二类涉众，其他类型的涉众也不能忽视。本书约定,凡是与系统有关的(不论系统研发或者开发完毕之后)能对系统提出需求的我们都称之为涉众.这里有一些被确定为涉众的人:•任何参与系统研发的人(业务分析员，设计员，编程和测试人员，项目经理，开发经理，用例设计师，图形界面开发人员)。•任何一个为系统研发提供知识的人(领域专家，可以启发需求的文档的作者，利益相关网站的所有人)。•执行者(作为客户代表的公司总裁，公司IT部门的主管等设计并研发系统的人).•与系统维护和支持有关的人(主机托管公司，帮助台)•规章制度的制定者(符合搜索引擎规则，政府制度，税收政策)。1.2需求金字塔需求金字塔需求金字塔需求金字塔立足于格式，目标源，通常的特性，需求可以分解为不同的类型，这里有一些项目中常用的类型：•涉众需要：来自涉众的需求•功能：系统提供的服务，通常由业务分析员制订；涉众的需要体现在功能上。•用例：描述系统性能的一系列行为。•补充规格：不能被用例捕捉的其他需求（非功能性需求）。•测试用例：测试输入，执行条件和输出结果的一组规范。•场景：一组特定的行为序列，描述一个用例的行为步骤。这些需求可以以一个金字塔的形状来呈现，如图1.1所示.图图图图1.1需求金字塔在金字塔顶端的是涉众需要，以此往下分别是功能，用例和补充规格。不同级别的需求，所捕捉的细节也不同。低级的需求会描述的更详细一些；比如某个需要为“数据要持久保存”，其功能性需求则为“系统需要一个关系型数据库”。在补充规格中，这个需求就是“系统需要一个Oracle9i数据库”;更深层的级别中，需求也会描述的更详细一些。需求管理的最佳实践是二个不同级别的需求级别高的那个比较而言要抽象一些；比如，愿景包含在高级别的需求(功能)中，在低级的需求中会把愿景逐条展开加以描述。高级涉众（比如副总裁）没有时间去阅读200页的详细需求文档但是可以读12页的愿景文档。无论如何,业务分析员都要对各个层次的需求粒度作出合理的安排.在涉众需要这层，来自涉众的需求描述是不能有任何错误和遗漏的。需要和功能最大的不同在于二者的需求来源不同，需要来源于涉众，功能则由业务分析员来阐述。测试用例的角色是用来检验用例和补充规格是否正确实现，场景帮助从用例中分析出测试用例，同时使得用例的行为步骤的实现和设计变得容易。在RequisitePro中，我们可以定义其他类型的需求，比如术语表和执行者，虽然它们都不是百分百的需求并且和在本章中所定义的需求定义略有出入，但是当我们在RequisitePro中把它们作为需求来看待，用如同需要、功能、用例等一样的机制作为需求类型，在跟踪主要需求的属性和可塑性时将增加我们的灵活度。1.3需求间的可追踪性需求间的可追踪性需求间的可追踪性需求间的可追踪性可追踪性是在系统中维护不同层次需求关系的重要技巧，这个技巧可以帮助你追溯出任何需求的起点。在图1.1中阐明了如何自顶而下的跟踪用例，每个需要可以映射到若干个功能，通常地，它们是多对多的关系，因为多个功能可以上溯到同一个需要，同时一个功能可能也是从多个需要中得来，一个需要映射为一个功能也是常有的事。功能映射到用例和补充规格都是多对多的关系。每个用例映射到一个或者多个场景，所以用例和场景之间是一对多的关系，场景和测试用例间的关系同样如此。可追踪性扮演着重要的角色：•检验所有的需求是否完整实现：与客户要求相关的任何事情都必须执行和实现。•检验系统没有超出客户的需求范围：不要做客户没有要求做的事。（译注：严禁需求突破）•影响分析：当我们考虑增加新的需求或者改变一个已存在需求的时候哪些元素会被影响到？•帮助变更管理：当发生需求变更，我们要知道哪些测试用例需要重做，并测试这些变化。一个可追踪项是一个项目元素可以被另一个项目元素跟踪，在RequisitePro的术语中，这就是一个需求类型的实例所要阐述的的任何事情。在RequisitePro中的需求类型的例子诸如涉众需要，功能，用例，执行者和术语表等。在RequisitePro的一个视图中可以非常方便的跟踪它们.1.4好需求的特征好需求的特征好需求的特征好需求的特征一个需要必须符合一些必要的条件才能称之为“好需求”[HUL05][LEF03][LUD05][YOU01].好需求有以下特征：•无歧义•可测试(可验证)•清晰(简洁，扼要，简单，精确)•正确•易懂•切实可行(真实，不空洞)•独立•原子性(即不可分)•必需的•自由实现(抽象)除了这些专用的需求准则之外，还有3个标准也适用于需求，它们是：•一致性•非冗余•完整性本书要用到的一个示例是一个在线旅行社网站，如图1.2所示。你也许对这个应用非常熟悉，因为在互联网上这种类型的网站比比皆是。这个项目综合具备了用例类型之间可能有的各种的关系，不同担心，它们非常易懂。本章和其他章节中的许多例子都和这个项目有关。图图图图1.2在线旅行社的主页下面我们将逐个讨论一个好需求的条件，同时也会接触一些例子。无歧义无歧义无歧义无歧义只能用一个方式来解释需求.某些时候不确定的缩写会使需求含糊不清：REQ1这个系统必需用ASP来实现。ASP到底是ActiveServerPages还是ApplicationServiceProvider?解决它的方法是：我们用完整的名词同时将缩写放在括号中：REQ1这个系统必需用ActiveServerPages(ASP)来实现。这里还有另外一个例子:REQ1这个系统可以接受的密码不得超过15个字符长度.系统准备做些什么这个需求并没有说清楚：•这个系统不让用户输入超过15个字符？•这个系统将截取用的输入，只保留15个字符？•当用户输入超过15个字符，这个系统将显示一个错误？修正后的需求则澄清了这些疑虑：REQ1这个系统可以接受的密码不得超过15个字符长度，如果用户输入的密码超过15个字符，将出现一个错误信息以提示用户纠正它。含糊不清的地方还会体现在一些词语语序中：REQ1在“保存航程”界面，用户只能浏览一条记录。这是否以为着只能浏览而不能做删除更新等操作？或者其含义是用户只能看到一条记录而不是二条或者三条？解决问题的方法就是从系统观点来重写这条需求：REQ1在“保存航程”界面，系统将仅显示一个航程。可测试可测试可测试可测试(可验证可验证可验证可验证)测试人员能够验证需求是否正确的实现，测试结果不是成功就是失败。需求必需是清晰，精确和无歧义才具备可测试的能力。下面是一些有关需求不可测试的话：•一些形容词：鲁棒，安全，准确，有效，效率，可扩展，灵活，可维护，可靠，友好，适当的•一些副词和副词短语：很快地，安全地，适时地•非特定单词的缩写：etc.,and/or,TBD一些需求看起来可能是这样：REQ1搜索功能：允许用户基于名字，日期等等来搜索找到一个预订。在这个需求中，所有的搜索规则都明确的列举出来，这样一来，设计员和开发员就不需要猜测“等等”是用户的什么意图。其他的问题是不要引入有歧义的单词或者语法：•修改措辞：是适当的，是必需的，如果必需的，将会被考虑的•含糊不清的单词：管理，处理•被动式：句子的主题由有详细细节的操作来完成胜过只是简单的执行它。REQ1机场代码由用户输入REQ2输入机场代码第一个例子展示了典型的被动式语句。在主动态语句中将会理解为：“用户将输入机场代码”。在第二个例子中，省略了被动句中动词的履行者部分，那么谁来输入这个代码-系统还是用户?•不定式：少量，一些，大量，有些，有几个，任意，任意人，任意事，任一个等等。REQ1系统能够承受多用户并发访问。“多”是多少？10个？100个？还是1000个？清晰清晰清晰清晰(简洁简洁简洁简洁，，，，扼要扼要扼要扼要，，，，简单简单简单简单，，，，精确精确精确精确)需求中不要包含不必要的空话套话，它们一定是清晰简洁地：REQ1一般情况下用户输入机场代码，系统能够理解机场代码的含义；但在某些情况下，用户会用机场附近的城市来代替机场代码，这时候，用户并不需要知道机场代码是什么，只要系统知道就可以了。这个句子完全可以简单的叙述：REQ1系统将基于机场编码或者城市名字来确定一个机场。正确正确正确正确如果需求包含税务,那么这些税率必需是真实的:REQ1汽车租赁的价格将包含所有的必缴税(包括6%的地方税).每个地方的地方税率是不同的，所以这个6%的数字可能是不正确的。易懂易懂易懂易懂需求必需用规范一致的文法来书写，尽量使用通常的惯例或者习惯用法。“将会”就比”将来“，”必需“，”可能“好。切实可行切实可行切实可行切实可行(真实真实真实真实，，，，不空洞不空洞不空洞不空洞)需求必需切实可行，而不会需要夸张的诸如时间，资金等资源：REQ1系统将会有一个由易于理解的语言诸如英语所构建的自然语言的界面这个需求是不可行的，它将消耗大量的研发时间。独立独立独立独立理解当前这个需求而不需要还要了解其他需求：REQ1可用航班列表包括每个支线航班在内的航班编号，起飞时间，抵达时间。REQ2它以价格排序。后一个需求中的“它”依赖于前一个需求。但是，如果需求的顺序发生了变化，第二个需求就难以理解了。原子性原子性原子性原子性(即不可分即不可分即不可分即不可分)需求包含一个单一的可追踪元素：REQ1系统将具备预订航班，订购机票，预订房间，预订租车等等具有吸引力的信息这个需求包含了5个原子需求，这会造成跟踪困难。在审核的时候发现语句中包含“和”或者“但是“，那么就可以细分这个需求。必需的必需的必需的必需的如果一个需求是不必要的，意味着：•没有哪个涉众需要这个需求或•移除