需求管理是一种查找、记载、组织和跟踪系统不断变化的需求的系统方法。
我们将需求定义为“系统必须遵循的条件或能力”。
我们将需求管理正式定义为一种系统方法,可执行以下两项任务:
-
获取、组织和记载系统需求
-
使客户和项目团队就系统不断变化的需求确立和保持一致意见
有效需求管理的关键因素包括保持明确的需求说明,以及其他需求和其他项目工件的相应属性和可跟踪性。
收集需求可能听起来是相当简单的任务。实际上,项目却会因为以下原因而遇到困难:
-
需求并非总是明显的,并可能有许多来源。
-
需求并非总是容易用语言表达清楚的。
-
有许多不同详细程度的不同类型的需求。
-
如果不加控制,需求的数量可能会变得难以管理。
-
需求是彼此相关的,并且与软件工程流程的其他可交付件也是相关的。
-
需求具有唯一的属性或属性值。例如,它们不一定同等重要或同样容易实现。
-
存在许多利益方,这意味着要由跨职能的几组人来管理需求。
-
需求会变化。
无论您多么仔细地定义需求,事情也始终会有变化的。使变化的需求的管理任务变得复杂,不仅是因为变化的需求意味着必须花时间实施特定的新功能,还因为一个需求的变化可能会对其他需求有影响。管理变更包括建立基线、确定跟踪哪些相关性很重要、建立相关项之间的可跟踪性以及实施变更控制之类的活动。
对于组织功能需求,我们推荐的方法是使用用例。组织需求时并不采用符号列表的方式,而是要以某种方式讲清楚某人可能如何使用该系统。 这使得需求更完整、更一致,也使用户能更好地理解需求的重要性。
使用传统的面向对象系统模型,通常很难说明系统如何执行其应执行的操作。这种困难源于系统执行某些任务时系统中缺少“红线”。在 Rational Unified
Process(RUP)中,用例就是这条线,因为它们定义了系统执行的操作。用例不属于传统面向对象的范畴,但它们的重要性则更为明显。用例作为统一模型语言的一部分,进一步强调了这种重要性。
RUP 采用一种“用例推动法”,这意味着为系统定义的用例是整个开发流程的基础。
用例在若干规程中都起了作用。
-
用例的概念可用于表现业务流程。我们将此用例变体称为“业务用例”。“业务建模”规程中包含了该用例。
-
作为软件需求,用例是在“需求”规程中描述的。用例构成一种重要的基础概念,客户及系统的开发人员与测试人员都必须接受这一概念。
-
在“项目管理”规程中,用例充当计划迭代开发的基础。
-
用例在设计模型中是作为“分析和设计”规程的一部分来实现的。用例实现描述的是,根据设计模型中的交互对象,设计如何支持用例。
-
用例最终成为已实施的和可测试的场景,所以在“实施”和“测试”规程这两方面都是重要的关注问题。它们用于推导测试用例和测试脚本;系统的功能是通过执行练习每个用例的测试场景而得以验证的。
-
在“部署”规程中,用例相当于用户手册中所描述内容的基础。用例还可用于定义产品的订购单位。例如,客户可以使用特定的一组用例来配置系统。
|