UML软件工程组织

基于需求的规划策略:按优先次序排序
作者:Scott W. Ambler 本文选自:IBM DW中国 2002年09月26日

 

成功的项目组认识到不能等同地创建所有的需求,因此,需要对需求进行优先次序排序并按此顺序操作。

某些需求比其它需求重要得多。例如,对于联机银行的需求来说,对帐户间资金转移的支持要比银行每月声明的 Elbonian语言版本重要得多。成功的软件团队将首先集中精力构建最重要的功能,尽可能地满足用户需求中关键的功能,而那些次关键性功能留到以后处理。需求排序使您的团队能够为组织的软件利润作出最大贡献。然而,要有效地对需求进行优先次序排序,必须考虑几个因素:商业价值、交付成本、交付日期、交付复杂程度、风险(请参阅提示“控制风险:不让风险控制您”)、与其它需求的关系、何时需要该需求。

可能的优先级别范围

只要明确的定义了优先级并且在应用上保持一致,那么使用什么优先级别范围是无关紧要的。一般的优先级别范围包括:

● 高级、中等、低级

● 必需的、条件的、可选的

● 数字的(例如,1、2、3)

如何对需求按优先次序排序

您应该让授权的个人或小组来建立并确认指派的优先权。对需求的优先级进行优先次序排序通常是一个协商的过程,它涉及到许多项目参与者,包括您的用户、用户管理、高级管理、开发人员、操作人员和支持部门。

大多数项目小组将组织成一个“配置控制委员会 (CCB)”——有时称为“更改控制委员会”或“项目筹划指导委员会” ——它由系统中关键的并且希望是知识渊博的参与者组成。通常由该小组定期开会决定任何新需求的优先级和指派(对于系统的发布或者对于在现有开发成果中的重复)。

为何对需求进行优先次序排序?

需求排序列表是输入进项目定界过程中的关键因素。项目早期,需要认识到,最困难的事之一是不要打算能交付项目参与者要求的每个功能。项目范围定义了项目组将要交付的范围。这是很重要的,因为它有助于避免“超出范围”,即,项目进展的附加的新需求。已定义的项目范围使您能协商是否有责任交付新确定的需求,并判断新需求对于交付日期/成本的增加的合理性以及讨论是否应该在后续发行版中交付该需求。缺少确定的范围,项目组将承担无法交付的风险,因为经常要向正在构建的项目中添加“再多一条功能”。

『引自 IBM DW中国


版权所有:UML软件工程组织