实验1需求管理工具

1、RequisitePro中需求管理的12个步骤RequisitePro中需求管理的12个步骤需求管理是对变动的需求进行确定、组织和制作文档的过程。本文将介绍Rational Unified Process (RUP)中的有关于需求管理的基本概念，并展示如何使用RequisitePro来实行需求管理。    RequisitePro是很特别的产品，它集成了一个大家都很熟悉的环境：Microsoft Word，以及一个数据库来提供强有力的十分容易使用的框架，你可以用它来对产品需求进行管理。你要在需求文档中逐条标记你的需求，然后通过数据库对它们进行管理。以此为基础，你的

2、团队可以对同一个项目进行合作与联系，并进行不断的更新。    理解需求管理的第一步是建立一个通用的词汇表。Rational把需求定义为：一种在建系统必须遵循的条件或功能。需求管理应该是：可以对系统的需求进行引入、组织和文档化的一种系统化的方法与步骤，以及建立和维护开发团队和客户之间关于系统需求变更的确认的过程。    要注意的是目前的需求管理没有最通用的办法。以下的各步骤是作为一种起点来提供的。在你的开发环境中，由于你不断经历着你的软件的反复叠代并为此不断工作，你需要不断地重新定义你的过程，并且要找出最适合你开发需要的工作程序。 由于

3、这是反复迭代的过程，所以你要在项目中经常经历以下的12个步骤。    Step 1: 分析问题并收集stakeholder needs    系统分析对总体任务负有责任。所有的团队成员，包括核心的stakeholder，都要帮助系统分析员从客户那里收集stakeholder needs。可以使用以下方法：    面谈交流    问题调查表    集体讨论与灵感收集    讨论板    原

4、型    这些和客户交互的结果可以很方便地记录到RequisitePro文档中去。    Step 2: 为RequisitePro工程创建一个概要说明    一旦你的团队已经分析了问题，并且收集了足够的stakeholder needs，下一步是在RequisitePro中对你的项目组织安排进行规划。你可以使用Requirements Management Plan outline (rup_rmpln.dot)来创建一个需求管理计划文档。如果你使用的是RequisitePro Project Temp

5、late 4.5，那么你还可以选择需求管理计划文档的类型。你可以在需求管理计划文档中记载以下信息：    你可能在项目中要用到的Requirements artifacts (RequisitePro文档)，例如Stakeholder需求文档、 Vision（确定性不高的）文档、软件需求文档、测试计划书，还有需求类型，例如用于stakeholder NEED,特性 FEAT, 软件需求SR(software requirement),另外还有需求属性，跟踪要点等。    Step 3: 在一个可见的文本中的文档特性 

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

7、ionale、来源等)。 在输入完以后，系统分析员为需求管理来定义有关的属性，因为它们涉及到开发周期中其它的工作。    Step 4: 拓展需求的细节    一旦你的特性需求定义好了，你可以创建底层的需求(它门可能被组织成软件需求) 。在搜集了整个团队的输入以后，系统分析员将需求输入到RequisitePro，同时还定义属性用以进行跟踪。    还有些组织会选择use case来规划他们的需求。系统分析员和所有项目成员聚集在一处，共同探讨需求问题，对软件中所有的use case和actor角色进行鉴定。

8、通常这会在白板或纸上进行记录，系统分析员使用这些信息并把这些use case和actor记录到Rational Rose中去。你可以在Rose中拓展use case，并把它们和RequisitePro中的需求进行关联 (参见Step 10: 和Rational Rose集成)。如果你的工作过程不包括Rose，那么何不直接把它们作为需求输入到RequisitePro。    Rational提倡在详细描述uses case时使用分层次等级的需求。如果你在一个很大的非常复杂的系统中，那么你可以决定是否要为某一个use case使用分离的需求类型。如果你要为2个不同的需

9、求类型使用不同的安全设置，或者你可能希望在use case和在其中定义的需求之间建立外在的可跟踪性，或者你需要一套2个不同的需求类型中彼此分离的属性，那么这还是有必要的。    一旦需求被加入到RequisitePro，系统分析员（通过团队的输入协助下）可以定义一些属性来对需求进行管理。Use case用例在项目的某个过程中可能接着被加入。你的列表可能还不完善，但这没有关系，因为它可以在任何时候得到进一步的更新和完善。    Step 5: 跟踪需求，并扩展到功能上去    一旦所有的需求都已经输入到Re

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

11、级    在需求之间设置了可跟踪性以后，系统分析员和整个团队成员要搜集并决定输入RequisitePro的需求的有限级别。    在你确定优先级的时候，要考虑这样一些因素：    需求是如何体现到产品功能、可用性、可靠性和性能中去的？    在进度约束下，需求实现后的效果是否值得？    现实下需求是否带来风险？    该需求如果实现了，对你进行产品维护的能力有什么影响？    你还必须

12、检查你的进度。是否有时间完成所有高优先级需求？    在此阶段建立比较现实的期望将帮助你的团队在进度和预算范围内开展工作。    使用需求属性可以帮助你确定需求的优先级别。一旦你输入了需求数据，你就可以对它们进行查询、排序并决定它们的位置。    在RequisitePro学习工程中，属性"Planned Iteration"字段被设为一个数值，该数值反映了软件中的反复，团队准备用该软件来实现特定的use case。一旦第一次反复叠代的范围被定义完成，而且反复叠代次数被指定到use c

13、ase，系统分析员对用例执行一项Attribute Matrix查询来分离那些在软件中首次反复可被定位的用例。你可以将该Attribute Matrix保存并在以后再次查看它。    Step 7: 对需求进行分派    对需求指定优先级以后，系统分析员和团队将每一个use case或者requirement指派给团队成员，这可通过使用 "Assigned To"需求属性来完成。团队中的一些人将对每一个特性的具体实现负责。    通过参考上面步骤中的Attribute Matrix，分

14、析员为每一个需求或用例填写"Assigned To"属性。这将被作为第一次反复。    使用use case方法的组织将把use cases分派给use case定义者，他将对所有和流程相关的所有需求负责。    如果你的组织使用其它的方法，则分派也可能是其它形式：    SRS系统规格文档，可以包括多组需求；或者特定格式的需求记录    Step 8: 细化需求规格    团队成员 (或者use case 定义者)通过在Re

15、quisitePro中"Assigned To"属性来确认他们被分派了哪些需求。他们可以得到一张显示所有需求对个人的分派情况的列表。    从该表中你可以查询一个FEAT需求类型的Traceability Matrix，以及分派给你的需求类型。你可以通过选择需求类型得到所有特性跟踪的列表，并通过它生成一个特定的文档。    Use case specifier将进行查询，这些查询基于从用例的类型的跟踪，然后可使用来自requirement workshop的use case描述来创建Use-Case Specifi

16、cation文档。    Rational推荐在详细描述use case时使用分等级管理。你可以使用“属性Property”来组织你的use case需求。 可以用use case的名字来创建父一级的用例需求，并设置属性"Name"的值。你可能还要使用属性"Brief Description"或者"Basic Flow"来定义子一级的用例需求，他们可提供用例的细节。    Step 9: 在RequisitePro中将需求属性公布(Populating)  

17、;  在此之前，系统分析员已通过整个团队的输入而定义了需求管理的有关属性(见前面章节)。 被分派了需求的团队成员可以将这些属性在RequisitePro中通过赋予特定的用于需求管理的值来使之公布(Populating) 。    Step 10: 和Rational Rose进行集成    如果你同时拥有Rational Rose和RequisitePro，那么有2种方法来共享数据。    我们推荐使用Integrated Use Case Management来开始你的开发周期。系统分析员在R

18、ose中定义use case ，然后在RequisitePro中使用Integrated Use Case Management特性来创建use case文档。该方法只需要通过几项菜单操作即可实现Rose和RequisitePro之间的转化和关联。对use case的修改将自动在Rose或RequisitePro中得到更新。    但是，如果你在RequisitePro中开发use case，并且想转换到Rose use case图，并且带有关联属性，那么你要使用Rational Synchronizer，此后你可以通过Integrated Use Case Ma

19、nagement将这些use case关联到RequisitePro需求和文档。    Rational Synchronizer可以帮助你在Rose中从RequisitePro中已经存在的需求中创建use case。如果你已经在RequisitePro中建立了大量的use case，那么这时候将很有帮助。在这种情况下，你可以用Rational Synchronizer中的rules feature来把RequisitePro中的use case需求以批处理方式转换到Rose中。然后你可以使用Integrated Use Case Management来把这些Ro

20、se use case和已经存在的RequisitePro中的use case需求进行关联。    Step 11: 通过查询来找出项目的进展状况    在查询以前，要在FEAT需求和指派给你的需求类型之间建立一个Traceability Matrix，(Use case specifiers将在FEAT和用例需求之间建立Traceability Matrix)。视图将以行方式显示你的FEAT需求，以列方式显示其它需求。    点击Query column requirements按钮，并且在Select Attribute对话框中选择"Planned Iteration" 属性，点击OK。在Query Requirements对话框中，选择Equal to选项，然后键入你期望的反复次数。如果要看哪一项属性没有反复计划，则可以什么也不填。点击OK，并关闭每个对话框以执行查询。    查询结果将给出这些FEAT需求类型的跟踪情况。如果你选择了没有反复计划的类型，这样的列表可以在团队会议上被检阅，而被指派到这些需求上的反复叠代则没有任何指示。