需求跟踪能力矩阵
                                
                                    作者: 来源: 文字大小:[大][中][小]
                                表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。下表展示了这种矩阵,这是一个“化学制品跟踪系统”实例的跟踪能力矩阵的一部分。这个表说明了每个功能性需求向后连接一个特定的使用实例,向前连接一个或多个设计、代码和测试元素。设计元素可以是模型中的对象,例如数据流图、关系数据模型中的表单、或对象类。代码参考可以是类中的方法,源代码文件名、过程或函数。加上更多的列项就可以拓展到与其它工作产品的关联,例如在线帮助文档。包括越多的细节就越花时间,但同时很容易得到相关联的软件元素,在做变更影响分析和维护时就可以节省时间。
	
		表1:一种需求跟踪能力矩阵 
	
		
			| 
				用例 | 
			
				功能需求量 | 
			
				设计元素 | 
			
				代码 | 
			
				测试实例 | 
		
		
			
				UC-28 
				UC-29 | 
			
				Catalog.query.sort 
				catalog.query.import | 
			
				Class 
				Catalog 
				Class 
				catalog | 
			
				Catalog.sort() 
				Catalog.import() 
				Catalog.validate() | 
			
				Search.7 
				Search.8 
				Search.8 
				Search.13 
				Search.14 | 
		
	
	  跟踪能力联系链可以定义各种系统元素类型间的一对一,一对多,多对多关系。表1中允许在一个表单元中填入几个元素来实现这些特征。这里是一些可能的分类:
	- 
		一对一一个代码模块应用一个设计元素。
 
	- 
		一对多多个测试实例验证一个功能需求。
 
	- 
		多对多每个使用实例导致多个功能性需求,而一些功能性需求常拥有几个使用实例。
 
	  手工创建需求跟踪能力矩阵是一个应该养成的习惯,即使对小项目也很有效。一旦确立使用实例基准,就准备在矩阵中添加每个使用实例演化成的功能性需求。随着软件设计、构造、测试开发的进展不断更新矩阵。例如,在实现某一功能需求后,你可以更新它在矩阵中的设计和代码单元,将需求状态设置为“已完成”。表示跟踪能力信息的另一个方法是通过矩阵的集合,矩阵定义了系统元素对间的联系链。例如:
	- 
		一类需求与另一类需求之间。
 
	- 
		同类中不同的需求之间。
 
	- 
		一类需求与测试实例之间。
 
	  可以使用这些矩阵定义需求间可能的不同联系,例如:指定/被指定、依赖于、衍生为以及限制/被限制。
	  下表2中说明了两维的跟踪能力矩阵。矩阵中绝大多数的单元是空的。每个单元指示相对应行与列之间的联系,可以使用不同的符号明确表示“追溯到”和“从.. 回溯”或其他联系。表2中使用一个箭头表示一个功能性需求是从一个使用实例追溯来的。这些矩阵相对于表16-6中的单跟踪能力表更容易被机器自动支持。
	
		表2:反映使用实例与功能需求之间联系的需求跟踪能力矩阵
	
		
			
				功能 
				需求 | 
			
				用例 | 
		
		
			| 
				U C - 1 | 
			
				U C - 2 | 
			
				U C - 3 | 
			
				U C - 4 | 
		
		
			| 
				F R - 1 | 
			
				√ | 
			
				  | 
			
				  | 
			
				  | 
		
		
			| 
				F R - 2 | 
			
				√ | 
			
				  | 
			
				  | 
			
				  | 
		
		
			| 
				F R - 3 | 
			
				  | 
			
				  | 
			
				√ | 
			
				  | 
		
		
			| 
				F R - 4 | 
			
				  | 
			
				  | 
			
				√ | 
			
				  | 
		
		
			| 
				F R - 5 | 
			
				  | 
			
				√ | 
			
				  | 
			
				√ | 
		
		
			| 
				F R - 6 | 
			
				  | 
			
				  | 
			
				√ | 
			
				  | 
		
	
	  跟踪能力联系链无论谁有合适的信息都可以定义。下表3定义了一些典型的知识源,即关于不同种类源和目标对象间的联系链。定义了可以为工程项目提供每种跟踪能力信息的角色和个人。
	
		表3:跟踪能力联系链可能的信息源
	
		
			| 
				链的源对象种类 | 
			
				链的目的对象种类 | 
			
				信息源 | 
		
		
			
				系统需求 
				用例 
				功能性需求 
				功能性需求 
				功能性需求 
				设计元素 
				功能性需求 | 
			
				软件需求 
				功能性需求 
				功能性需求 
				软件体系结构元素 
				其他设计元素 
				代码 
				测试实例 | 
			
				系统工程师 
				需求分析员 
				需求分析员 
				软件体系结构(设计)者 
				开发者 
				开发者 
				测试工程师 | 
		
	
	     需求跟踪能力工具
	  由于联系链源于开发组成员的头脑中,所以需求跟踪能力不能完全自动化。然而,一旦已确定联系链,特定工具就能帮你管理巨大的跟踪能力信息。可以使用电子数据表来维护几百个需求的矩阵,但更大的系统需要更“鲁棒”的解决办法。
	  具有强大需求跟踪能力的商业需求管理工具均使用如表16 -7的跟踪能力矩阵。可以在工具的数据库中存储需求和其他信息,定义不同对象间的联系链,甚至包括同类需求的对等联系链。有一些工具需要区分“追溯到(跟踪进)”与“从..回溯(跟踪出)”关系,自动定义相对的联系链。这就是说,如果你指出需求R追溯到测试实例T,工具会自动定义相对的联系“ T从R回溯”。还有一些工具可以在联系链某端变更后将另一端标为“可疑”。可以让你检查确保知道变更的后续效果。
	  这些工具允许定义“跨项目”或“跨子系统”的联系链。一个有20个子系统的大项目,某些高层产品需求建立在多个子系统之上。有些情况下,分配给一个子系统的需求,实际上是由另一个子系统提供的服务完成的。这样的项目采用商业需求管理工具可以成功地跟踪这些复杂的跟踪能力关系。
	     需求跟踪能力过程
	  当你应用需求跟踪能力来管理工程时,可以考虑下列步骤:
	决定定义哪几种联系链,可以参见图2来进行。
	选择使用的跟踪能力矩阵的种类,是表1还是表2。
	确定对产品哪部分维护跟踪能力信息。由关键的核心功能、高风险部分或将来维护量大的部分开始做起。
	通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链。
	制定标记性的规范,用以统一标识所有的系统元素,达到可以相互联系的目的。若必要,作文字记录,这样就可以分析系统文件,便于重建或更新跟踪能力矩阵。
	确定提供每类联系链信息的个人。
	培训项目组成员,使其接受需求跟踪能力的概念和了解重要性、这次活动的目的、跟踪能力数据存储位置、定义联系链的技术—例如,使用需求管理工具的特点。确保与会人员明白担负的责任。
	一旦有人完成某项任务就要马上更新跟踪能力数据,即要立刻通知相关人员更新需求链上的联系链。
	在开发过程中周期性地更新数据,以使跟踪信息与实际相符。要是发现跟踪能力数据没完成或不正确那就说明没有达到效果。