实验1需求管理工具

《实验1需求管理工具》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、http://tech.it168.com/a2009/0813/623/000000623613_1.shtmlRequisitePro中需求管理的12个步骤RequisitePro中需求管理的12个步骤需求管理是对变动的需求进行确定、组织和制作文档的过程。本文将介绍RationalUnifiedProcess(RUP)中的有关于需求管理的基本概念，并展示如何使用RequisitePro来实行需求管理。   RequisitePro是很特别的产品，它集成了一个大家都很熟悉的环境：Microsof

2、tWord，以及一个数据库来提供强有力的十分容易使用的框架，你可以用它来对产品需求进行管理。你要在需求文档中逐条标记你的需求，然后通过数据库对它们进行管理。以此为基础，你的团队可以对同一个项目进行合作与联系，并进行不断的更新。   理解需求管理的第一步是建立一个通用的词汇表。Rational把需求定义为：一种在建系统必须遵循的条件或功能。需求管理应该是：可以对系统的需求进行引入、组织和文档化的一种系统化的方法与步骤，以及建立和维护开发团队和客户之间关于系统需求变更的确认的过程。   要注意的是目前

3、的需求管理没有最通用的办法。以下的各步骤是作为一种起点来提供的。在你的开发环境中，由于你不断经历着你的软件的反复叠代并为此不断工作，你需要不断地重新定义你的过程，并且要找出最适合你开发需要的工作程序。由于这是反复迭代的过程，所以你要在项目中经常经历以下的12个步骤。   Step1:分析问题并收集stakeholderneeds   系统分析对总体任务负有责任。所有的团队成员，包括核心的stakeholder，都要帮助系统分析员从客户那里收集stakeholderneeds。可以使用以下方法：  

4、 面谈交流   问题调查表   集体讨论与灵感收集   讨论板   原型   这些和客户交互的结果可以很方便地记录到RequisitePro文档中去。   Step2:为RequisitePro工程创建一个概要说明   一旦你的团队已经分析了问题，并且收集了足够的stakeholderneeds，下一步是在RequisitePro中对你的项目组织安排进行规划。你可以使用RequirementsManagementPlanoutline(rup_rmpln.dot)来创建一个需求管理计划文档。如果你

5、使用的是RequisiteProProjectTemplate4.5，那么你还可以选择需求管理计划文档的类型。你可以在需求管理计划文档中记载以下信息：   你可能在项目中要用到的Requirementsartifacts(RequisitePro文档)，例如Stakeholder需求文档、Vision（确定性不高的）文档、软件需求文档、测试计划书，还有需求类型，例如用于stakeholderNEED,特性FEAT,软件需求SR(softwarerequirement),另外还有需求属性，跟踪要点等

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

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

8、对软件中所有的usecase和actor角色进行鉴定。通常这会在白板或纸上进行记录，系统分析员使用这些信息并把这些usecase和actor记录到RationalRose中去。你可以在Rose中拓展usecase，并把它们和RequisitePro中的需求进行关联(参见Step10:和RationalRose集成)。如果你的工作过程不包括Rose，那么何不直接把它们作为需求输入到RequisitePro。   Rational提倡在详细描述usescase时使用分层次等级的需求。如