RequisitePro中需求管理的12个步骤

需求管理是对变动的需求进行确定、组织和制作文档的过程。本文将介绍Rational Unified Process (RUP)中的有关于需求管理的基本概念，并展示如何使用RequisitePro来实行需求管理。

RequisitePro是很特别的产品，它集成了一个大家都很熟悉的环境：Microsoft Word，以及一个数据库来提供强有力的十分容易使用的框架，你可以用它来对产品需求进行管理。你要在需求文档中逐条标记你的需求，然后通过数据库对它们进行管理。以此为基础，你的团队可以对同一个项目进行合作与联系，并进行不断的更新。 

理解需求管理的第一步是建立一个通用的词汇表。Rational把需求定义为：一种在建系统必须遵循的条件或功能。需求管理应该是：可以对系统的需求进行引入、组织和文档化的一种系统化的方法与步骤，以及建立和维护开发团队和客户之间关于系统需求变更的确认的过程。

要注意的是目前的需求管理没有最通用的办法。以下的各步骤是作为一种起点来提供的。在你的开发环境中，由于你不断经历着你的软件的反复叠代并为此不断工作，你需要不断地重新定义你的过程，并且要找出最适合你开发需要的工作程序。 由于这是反复迭代的过程，所以你要在项目中经常经历以下的12个步骤。

Step 1: 分析问题并收集stakeholder needs

系统分析对总体任务负有责任。所有的团队成员，包括核心的stakeholder，都要帮助系统分析员从客户那里收集stakeholder needs。可以使用以下方法：

面谈交流
问题调查表
集体讨论与灵感收集
讨论板
原型

这些和客户交互的结果可以很方便地记录到RequisitePro文档中去。 

　 

Step 2: 为RequisitePro工程创建一个概要说明

一旦你的团队已经分析了问题，并且收集了足够的stakeholder needs，下一步是在RequisitePro中对你的项目组织安排进行规划。你可以使用Requirements Management Plan outline (rup_rmpln.dot)来创建一个需求管理计划文档。如果你使用的是RequisitePro Project Template 4.5，那么你还可以选择需求管理计划文档的类型。你可以在需求管理计划文档中记载以下信息：

你可能在项目中要用到的Requirements artifacts (RequisitePro文档)，例如Stakeholder需求文档、 Vision（确定性不高的）文档、软件需求文档、测试计划书，还有需求类型，例如用于stakeholder NEED,特性 FEAT, 软件需求SR(software requirement),另外还有需求属性，跟踪要点等。 

Step 3: 在一个可见的文本中的文档特性

系统分析员可以在推荐的软件产品的高层次的需求（或功能特性）上获得客户的认可。这些关键性的用户需要一个在RequisitePro中的可见的文档。系统分析员可以为功能特性Feature创建需求类型 (使用FEAT)以及Stakeholder需求(使用NEED) 作为文档中缺省的需求类型。 
每一个经过肯定的特性都被标记为FEAT需求，而每一个stakeholder needs将被标记为NEED需求并放在一个不确定文档中。

此后系统分析员可以在RequisitePro中建立功能特性(例如：客户优先级、风险、rationale、来源等)。 在输入完以后，系统分析员为需求管理来定义有关的属性，因为它们涉及到开发周期中其它的工作。


Step 4: 拓展需求的细节

一旦你的特性需求定义好了，你可以创建底层的需求(它门可能被组织成软件需求) 。在搜集了整个团队的输入以后，系统分析员将需求输入到RequisitePro，同时还定义属性用以进行跟踪。

还有些组织会选择use case来规划他们的需求。系统分析员和所有项目成员聚集在一处，共同探讨需求问题，对软件中所有的use case和actor角色进行鉴定。通常这会在白板或纸上进行记录，系统分析员使用这些信息并把这些use case和actor记录到Rational Rose中去。你可以在Rose中拓展use case，并把它们和RequisitePro中的需求进行关联 (参见Step 10: 和Rational Rose集成)。如果你的工作过程不包括Rose，那么何不直接把它们作为需求输入到RequisitePro。

Rational提倡在详细描述uses case时使用分层次等级的需求。如果你在一个很大的非常复杂的系统中，那么你可以决定是否要为某一个use case使用分离的需求类型。如果你要为2个不同的需求类型使用不同的安全设置，或者你可能希望在use case和在其中定义的需求之间建立外在的可跟踪性，或者你需要一套2个不同的需求类型中彼此分离的属性，那么这还是有必要的。

一旦需求被加入到RequisitePro，系统分析员（通过团队的输入协助下）可以定义一些属性来对需求进行管理。Use case用例在项目的某个过程中可能接着被加入。你的列表可能还不完善，但这没有关系，因为它可以在任何时候得到进一步的更新和完善。 

Step 5: 跟踪需求，并扩展到功能上去

一旦所有的需求都已经输入到RequisitePro中了，系统分析员在软件需求(SR)和特性(FEAT)需求之间建立了可跟踪性。我们推荐对从SR类型到FEAT类型需求的过程进行跟踪，由此可以显示SR对FEAT依赖关系。
如果你选择使用use case，我们推荐对Use Case需求到FEAT需求的过程进行跟踪,因为use case依赖于对功能的定义。但在某些时候，功能特性并不和use case相对应，或者，很难通过特殊的use case来进行跟踪。在这种情况下，系统分析员要对功能需求进行Supplementary Specification (SUPL)跟踪。

Step 6: 对需求区分优先级

在需求之间设置了可跟踪性以后，系统分析员和整个团队成员要搜集并决定输入RequisitePro的需求的有限级别。

在你确定优先级的时候，要考虑这样一些因素：

需求是如何体现到产品功能、可用性、可靠性和性能中去的？
在进度约束下，需求实现后的效果是否值得？
现实下需求是否带来风险？
该需求如果实现了，对你进行产品维护的能力有什么影响？
你还必须检查你的进度。是否有时间完成所有高优先级需求？ 

在此阶段建立比较现实的期望将帮助你的团队在进度和预算范围内开展工作。

使用需求属性可以帮助你确定需求的优先级别。一旦你输入了需求数据，你就可以对它们进行查询、排序并决定它们的位置。

在RequisitePro学习工程中，属性"Planned Iteration"字段被设为一个数值，该数值反映了软件中的反复，团队准备用该软件来实现特定的use case。一旦第一次反复叠代的范围被定义完成，而且反复叠代次数被指定到use case，系统分析员对用例执行一项Attribute Matrix查询来分离那些在软件中首次反复可被定位的用例。你可以将该Attribute Matrix保存并在以后再次查看它。

原文转自：http://www.ltesting.net