主题

什么是需求管理? 回到页首

需求管理是一种查找、记载、组织和跟踪系统的变更的需求的系统方法。

我们将需求定义为:

系统必须遵循的条件或能力。

需求管理的正式定义是:是一种系统的方法,用于

  • 获取、组织和记载系统需求,并
  • 建立和维护客户和项目团队之间关于系统的变更的需求的一致意见。

有效需求管理的关键包括维护明确的需求陈述,以及每种需求类型的适用../../artifact/ar_rattr.htm -- This hyperlink in not present in this generated website属性和对其它需求及其它项目工件的可跟踪性

收集需求可能听起来象是极为直接了当的任务。然而,在实际项目中,您会遇到困难,因为:

  • 需求并非总是明显的,并且可能来自许多来源。
  • 需求并非总是很容易用语言表达清楚。
  • 有许多不同详细程度的不同类型的需求。
  • 如果不加控制,需求的数量可能会变得难以管理。
  • 需求是彼此相关的,并且与软件工程流程的其它可交付工件也是相关的。
  • 需求具有唯一的特征或特征值。比如,它们不是同等重要的,得到满足的难易程度也不同。
  • 存在许多相关方,这意味着需要由跨职能的人员组来管理需求。
  • 需求会变化。

因此,您需要在组织中发展哪些技能才能帮助您处理这些困难呢?我们已了解到,以下技能很重要,需要掌握:

问题分析 回到页首

执行问题分析以理解问题和初始的涉众需要,以及提议高级解决方案。这是一种推理和分析行为,以查找“隐藏在问题后面的问题”。在问题分析期间,将对真正的问题以及谁是涉众达成一致。并且,要定义解决方案的界限(从业务角度而言),以及解决方案的业务约束。还要分析项目的业务案例,这样能对正在构建的系统中所作的投资的期望收益有较好的了解。

另请参阅wfs_anpr.htm -- This hyperlink in not present in this generated website工作流程明细:分析问题

理解涉众需要 回到页首

需求来自许多来源,比如客户、合作伙伴、最终用户和领域专家。您需要知道如何对来源方作出最佳的确定、访问这些来源以及如何以最佳方式从这些来源引发信息。提供此信息的主要来源的个人被称为项目中的涉众。如果您正在开发一个要在公司内部使用的信息系统,您可以将具有最终用户经验和业务领域专业知识的人员包括到开发团队中。通常您要在业务模型级别而非系统级别上开始讨论。如果您正在开发一个要向市场出售的产品,您可能要广泛地利用销售人员来更好地理解该市场中的客户需要。

可以使用诸如访谈、头脑风暴、建立概念原型、问卷和竞争分析这样的技术来执行引发活动。引发的结果将是以文字和图形描述的请求或需要的列表,并且已对这些请求或需要指定了彼此相对的优先级。

另请参阅wfs_unsh.htm -- This hyperlink in not present in this generated website工作流程明细:理解涉众需要

定义系统 回到页首

定义系统意味着将对涉众需要的理解转换和组织成对要构建的系统的有意义的描述。在系统定义初期,要决定需求的构成部分、文档格式、语言形式、需求指定程度(数量以及详细程度)、请求优先级和预估工作量(在独立的练习中,不同的人通常会给予两种极为不同的评估)、技术和管理风险以及初始范围。此活动的一部分可能还包括与最重要的涉众请求直接相关的早期原型和设计模型。系统定义的结果是对系统的描述,该描述同时采用自然语言和图解方式。

另请参阅wfs_defs.htm -- This hyperlink in not present in this generated website工作流程明细:定义系统

管理项目范围 回到页首

为了有效地运行项目,您需要仔细地根据来自所有涉众的意见为需求确定优先级,并管理项目的范围。某些开发人员会着力于所谓的“复活节彩蛋”(开发人员觉得有意思且具挑战性的特性)而非及早致力于用于缓解项目风险或稳定应用程序体系结构的那些任务,因而有许多项目受到影响。为确保您尽可能早地解决或缓解项目中的风险,您应该递增式地开发系统,为用于缓解项目中已知风险的每一个增量仔细选择需求。为此,您需要与项目的涉众协商(每次迭代的)范围。这通常需要在管理项目不同阶段的输出的期望值方面有良好的技能。您还需要控制需求来源、项目的可交付工件的外观以及开发流程本身。

另请参阅wfs_sco.htm -- This hyperlink in not present in this generated website工作流程明细:管理系统范围

优化系统定义 回到页首

提供详细系统定义的方式应使涉众能理解、同意和签署该定义。它不仅需要涉及功能、还需要遵循任何法律或规章要求、可用性、可靠性、性能、可支持性和可维护性。通常会犯的错误是,认为您觉得很复杂而难以构建的系统就需要有一个复杂的定义。这导致难以解释项目和系统的用途。人们可能会留下深刻印象,但不会提供良好的意见,因为他们不理解。您应投入大量的努力来了解文档(您为描述系统而生成的文档)的读者。通常会发现有必要为不同的读者生成不同类型的描述。

我们已知道,用例方法(通常与简单的可视原型结合使用)是一种非常有效的用于沟通系统的用途和定义系统的详细信息的方法。用例帮助将需求置于某个环境中并描述有关如何使用系统的事例。

详细系统定义的另一个组成部分是陈述应如何测试系统。有关要执行哪些测试的测试计划和定义可告知我们将要验证哪些系统能力。

另请参阅wfs_refs.htm -- This hyperlink in not present in this generated website工作流程明细:优化系统定义

管理变更的需求 回到页首

无论您如何仔细地定义需求,也始终会有变化的事物。使变更的需求变得复杂而难以管理的原因不仅是因为变更的需求意味着在实现特定的新特性方面需要耗费或多或少的时间,还因为一个需求的变更可能会对其它需求有影响。您需要确保为需求提供一种可弹性适应变化的结构,并确保使用可跟踪性链接来表示需求与开发生命周期的其它工件之间的相关性。管理变更包括如下活动:建立基线、确定哪些相关性很重要而值得跟踪、建立相关项之间的可跟踪性以及更改控制。

另请参阅wfs_mnch.htm -- This hyperlink in not present in this generated website工作流程明细:管理变更的需求

更多信息

可在以下部分找到关于此主题的更多信息:

概念:需求
概念:需求类型
概念:可跟踪性
../../../papers/apprmuc.htm -- This hyperlink in not present in this generated website白皮书:通过用例来应用需求管理



Rational Unified Process   2003.06.15