RequisitePro中需求管理的步骤有哪些呢?
Step 1: 分析问题并收集stakeholder needs系统分析对总体任务负有责任。所有的团队成员,包括核心的stakeholder,都要帮助系统分析员从客户那里收集stakeholder needs。 可以使用以下方法:面谈交流问题调查表集体讨论与灵感收集讨论板原型这些和客户交互的结果可以很方便地记录到RequisitePro文档中去。
Step 2: 为RequisitePro工程创建一个概要说明一旦你的团队已经分析了问题,并且收集了足够的stakeholder needs,下一步是在RequisitePro中对你的项目组织安排进行规划。 你可以使用Requiremen...全部
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来进行跟踪。
收起