2009年3月9日,星期一05:56

真正重用需求

由道格·阿克斯(Doug Akers)撰写

竞争激烈的市场中的一家电信公司需要以尽可能低的成本快速向其客户交付下一代手机。该公司希望为下一代项目采用一套基本要求,但必须进行必要的修改才能在竞争中脱颖而出。

汽车供应商必须为其OEM客户一致且可靠地生产嵌入式软件组件。为此,供应商的开发过程必须考虑每个制造商所要求的细微差异。

需求重用为组织提供了像上面方案中所示的组织一样的独特能力,可以跨项目共享需求,而又不会吸收存储库中不必要的工件重复。这是一项关键功能,可以加快产品上市时间并降低开发成本。共享需求既可以跟踪作者正在进行的更改,也可以根据项目的需求保持不变。此外,任何人都可以更改共享需求,并且系统会适当地处理该需求的分支和演变。

重用的概念是软件开发领域中的一个熟悉概念,但是在需求管理领域中考虑时很少见。在实施解决方案以解决需求重用时,必须考虑各种定义和用例。

本白皮书讨论了构成需求的要素,并对需求如何演变,如何保留演变以及组织如何重用需求以加快业务创新,降低复杂性和控制成本建立了共识。

剖析需求

要了解需求重用的概念,我们必须首先查看需求的各个部分:数据,元数据和关系。

数据
描述对象,并​​且与对象本身有关。数据的示例可以是需求的摘要或描述。

元数据
这是有关数据的数据,有助于组织或使用流程中的对象。它通常描述对象的当前状态,并且具有与数据本身相同的作用域。例如,元数据可以描述需求工作流内的状态/阶段(即,已批准,已拒绝,已满足和已测试)。

人际关系
需求的这种特征使您可以建模: 

  • 结构(即包含,包含); 
  • 历史记录(即,修订,来源); 
  • 概念上的联系或痕迹(即满足); 
  • 引用(即,“定义者”,“分解为”); 
  • 安全性(即授权者,启用)。

任何给定的需求都可以在每个数据,元数据和关系类别中具有信息。当需求被重用时,任何或所有信息也可以被重用。

组织选择的需求管理工具需要具有基础架构和用户功能,以支持组织需求所决定的战略重用级别。通过利用需求的数据,元数据和关系元素,可以在许多不同的级别上进行重用,因此灵活性对于解决重用挑战也至关重要。

历史,版本和基准

在实施复杂的重用场景时,甚至在需求在发布后仍持续发布的系统中,人们必须能够识别该需求演变中的重要方面。在开发世界中,这些重要点称为“版本”。这个术语对不同的人可能意味着不同的事情,因此我们将首先对术语“版本”进行定义,因为它适用于需求重用,并显示了它如何与类似的术语(例如历史,基线和里程碑)相关联。

考虑一个系统,在该系统中,需求被捕获在需求文档中,但作为单个项目存储在资源库中。

历史 是用于描述单个项目或需求的审核跟踪的术语。对项目所做的所有更改,无论是对数据,元数据还是其关系,都将记录在其历史记录中。历史会回答有关该项目更改的人员,时间和问题。

代表单个商品历史中的一个有意义的点。并非对项目的所有更改都是重要的,因此需要该项目的新版本。例如,从Nigel到Julia的需求重新分配将不需要特定的版本标识符。所做的更改会记录到项目的历史记录中,但不会创建新版本。

基准线 是与版本非常相似的概念,但范围却大不相同。单个项目通常组织成组或集合。在需求管理领域中,这些集合称为文档,而基线是文档历史中有意义的一点。一些组织使用稍微不同的基准定义。基线不是在给定文档的时间快照,而是在需求重用的上下文中定义的基线。为了便于讨论,我们将面向目标的基准称为 里程碑 为了区分两者。

需求管理声明允许对单个需求进行版本控制。许多工具通过以下方式支持版本控制 克隆 要么 复制中 整个需求。将副本与原始需求相关联的解决方案甚至更少。

虽然相关,但版本控制和重用并不相同。版本控制的概念经常与重用概念混淆。在下一节中,我们将探索各种重用场景,以说明版本控制和重用的区别(以及好处)。

重用还是不重用? –需求重用的多种风味

需求重用而不重用– 分享

在项目,文档或其他工作之间共享项目的能力可以被视为重用的一种形式。在此定义下,共享项目的所有项目都可以看到甚至可能有助于项目的发展。项目上的元数据与所有关系和数据一样共享。

这不是真正的重用。我怀疑是否要全部调用此重用,但出于完整性考虑,此处将其包括在内。

无需遗产即可重复使用– 复制

如前所述,将对象从一个地方复制到另一个地方也可以视为一种重用形式。实际上,这是Microsoft Word(或任何其他非需求管理工具)支持的重用形式。当分析师打开一个文档,选择一些内容并在另一个文档中执行复制/粘贴手势时,他们将这些内容用于新的用途。这种重用形式不了解遗产或“我来自哪里”,当然一个文档中的更改不会影响另一个文档中的更改。实际上,更改是完全独立的,一个文档不知道另一文档中发生了更改,更不用说更改可能是什么了。

这也不是真正的重用。任何重用形式都必须至少包含一个指向原始内容来源的指针。

需求重用 遗产

在上述情况下,让我们假设您可以回答“我来自哪里”的问题。使用指针将其返回原点来增强副本,为重复使用提供了多种选择。利用此链接的方式将区分以下每个重用模型。当今,大多数可用的RM工具都具有一些链接或关系的概念–如果不是在单个需求级别,则在文档级别。文档级链接总比没有好,但它们的功能不是很强大。从长远来看,他们并没有真正详细地回答可追溯性问题,就没有意义。

链接到项目的原点是真正重用的开始,尽管这当然不是结束。

需求重用 变更通知

在这种情况下,需求和所有相关信息(数据,元数据和关系)将全部重复使用。项目状态决定了重用时需求的状态,在重用场景中对需求的任何更改都会引起连锁反应,将与这些需求相关的所有工件标记为可疑。

需求重用 换控制模式

与变更控制一起使用与变更通知一起使用的相似之处在于,数据,元数据和关系会整体上被重新使用。这似乎与实际上与上面讨论的“共享”主题相同,但是有一个显着的不同。共享相同需求的两个项目仅在一个项目需要更改它的时间点之前共享它。当信息更改时,将创建一个新版本/分支,并且仅引用该新版本的项目被声明为可疑。所有其他项目或文档均不受影响。

带注释的需求重用

在以上两个重用范例中,需求和相关信息(数据,元数据和关系)全部被重用。在带注释的重用中,只有属于需求的某些信息被标识为共享和重用的候选对象。其余信息特定于项目或文档。共享信息保存在资源库中,而其他信息则属于项目或文档参考。重用的需求的每个实例都有其自己的元数据和关系。项目或文档的状态独立于或可以独立于其中包含的需求的状态。更改存储库中的共享信息时,会自动创建需求的新版本。触发新修订的这些更改可能会由于更改的连锁反应而怀疑其他参考以及系统中的其他项目。例如,对需求的更改可能会影响下游的测试用例或功能规格。

一旦在元数据方面具有项目或文档独立性,就可以同时对动态(共享)和静态(重复使用)形式的重复使用进行建模。项目经理或分析师决定他们是否希望以动态的方式与不断发展的需求保持一致,或者是否希望锁定需求以使变更的影响不会影响其项目。

需求重用 注释和变更管理

在单个集成且可追溯的解决方案中将变更和配置管理范例应用于需求管理学科可以将重用的能力提升到一个新的水平。通过在重用之上合并一个流程并控制如何以及何时可以修改和重用需求,使您能够获得这些好处,而不必对对象进行分支和版本控制,除非得到了授权并适当地这样做。变更请求(RFC)进入,过滤并由各种审核委员会指导。其中一些RFC已获得批准并分配给用户,以影响所请求的更改。理想情况下,此变更管理过程可以定义可以进行哪些类型的变更;无论是修改,分支,应用基线还是其他手势。只有当批准的RFC与需求相关联时,分析人员才能修改需求,使系统进行相应的版本控制和分支,并适当地通知相关组成部分。

显然,这里没有描述其他的重用模型-组件级重用,文档重用以及这些的各种组合以及注释和变更管理。本文仅提供一个样本。集团,业务部门或整个企业内的业务需求和战略目标将有助于确定哪种模型对项目或组织最有效。

需求重用适合您的组织吗?

需求重用并不适合所有人。当今市场上,在需求管理工具方面有广泛的需求,组织首先需要知道需求成熟度曲线上的位置。

realreuse1.png

1 需求成熟度曲线实际上根本不是一条曲线,而是对需求管理中组织内部当前使用的过程和/或所需工具的度量。随着组织不断发展,在他们的需求管理框架内需要更多功能,例如变更管理,流程和工作流,可追溯性,重用性等。 

许多公司仍处于需求管理的初期。他们尚未采用需求管理工具,目前正在使用诸如Microsoft Word或Microsoft Excel之类的业务生产力应用程序来捕获和跟踪需求。他们可能会寻求简化文档导入,富文本支持和下游可追溯性等功能,以简化业务采用。这些组织还没有达到需要再利用支持的复杂要求,或者也许但还没有找到满足其需求的工具。

但是,如果组织已经在需求管理方面的成熟度曲线上取得了进步,并且正在并行管理多个项目和数千个需求,并试图降低复杂性,降低开发成本和缩短创新周期,那么需求重用就成为一个概念。应该进行调查。

面对现实吧,无论组织处于何处,以其最基本的形式进行重用都会提高生产力。无需重写需求,而是根据每个项目的需要复制和修改需求-您将节省击键,并利用过去根据这些需求管理的结构和组织。毕竟,实际上可以指定多少种不同的登录方式要求?好的,可能很多,但是在任何一个组织中,都存在标准化和简化应用程序访问的需求,并且利用从一个应用程序到另一个应用程序的需求来提供这种类似类型的功能只能是 好东西™(玛莎·斯图尔特)。

无论如何,在进入“需求重用对我合适吗?”这个问题之前,请先专注于问题领域。组织在需求管理方面面临哪些挑战?这是组织可以询问的示例问题列表,以确定重用是否是可以利用的概念,如果可以,则哪种重用形式最适合需要。 


道格·艾克斯(Doug Akers) 是MKS Inc.(www.mks.com)全球应用程序生命周期管理(ALM)技术的领导者,使软件工程和IT组织可以无缝地管理其全球软件开发活动。通过单个企业应用程序,可以实现更好的全球协作和更高的生产率。 MKS在北美,欧洲和亚洲设有办事处,为全球客户提供支持。道格·艾克斯(Doug Akers)可以通过以下途径到达 [email protected]

©BA Times.com 2020

麦格雷戈徽标白色网站