最佳方案：管理需求

海的主人

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

我们将需求定义为：系统必须符合的条件或达到的性能。我们将需求管理正式定义为：需求管理是一种系统化方法，可用于征集、组织和记录系统需求并使客户和项目团队在系统变更需求上达成并保持一致。

有效需求管理的关键在于保持需求的明确阐述，还需保持适用的属性以及其他需求和其他项目工件的可追踪性。 收集需求听起来似乎是个相当简单的任务。但在实际项目中却会遇到困难，原因在于： 需求不总是显而易见的，而且它可来自各个方面。 需求并不总是能容易用文字明白无误地表达。 在不同的详细级别上，需求的种类也各种各样。

如果不加以控制，需求的数量将难以管理。 需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。 需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。 需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。 需求会变更。

那么，在组织中需要培养哪些技能来解决这些困难呢？我们认为掌握以下技能至关重要： 问题分析理解涉众需要定义系统管理项目规模改进系统定义管理变更需求问题分析 通过问题分析可以了解问题、了解涉众的最初需要，并提出高水平的解决方案。它是为找出“隐藏在问题之后的问题”而进行的推理和分析。问题分析中将对实际问题和谁是涉众达成一致。而且，您还要从业务角度界定解决方案，以及制约该解决方案的因素。您应该已经对项目进行过商业理由分析，这将便于您更好地预计能从构建中的项目中得到多少投资回报。

另请参见需求工作流程中的工作流程明细：分析问题。

理解涉众需要 需求来自各个方面，比如来自客户、合作伙伴、最终用户或是某领域的专家。您需要掌握如何准确判断需求应来源于哪方面、如何接近这些来源并从中获取信息。提供这些信息主要出处的个人在本项目中称为涉众。如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。通常讨论将在业务模型一级上展开，而不是在系统一级上展开。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。

引发需求的活动可使用这样一些技巧：访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。引发结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。 另请参见工作流程明细：理解涉众需要。 定义系统 定义系统指的是转换并组织对涉众需要的了解，使之成为对要构建系统的意义明确的说明。

在系统定义的初期要确定以下内容：需求构成、文档格式、语言形式、需求的具体程度（需求量及详细程度）、需求的优先级和预计工作量（不同人在不同的实践中通常对这两项内容的看法大不相同）、技术和管理风险以及最初规模。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。系统定义的结果是用自然语言和图解方式表达的系统说明。 另请参见需求工作流程中的工作流程明细：定义系统。

管理项目规模 为使项目高效运作，应仔细根据所有涉众的需求确定优先级，并对项目规模进行管理。有的开发人员仅仅重视所谓的“复活节彩蛋”（即开发人员感兴趣或觉得有挑战性的特性），而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面，这已使太多的项目蒙受损失。为确保尽早解决或降低项目中的风险，应以递进的方式开发系统。要慎重选择需求，以确保每次递进都能缓解项目中的已知风险。要达到目的，您需要和项目的涉众协商每次迭代的范围。

通常，这要求具备管理项目各个阶段的期望结果的良好技能。除了控制开发过程本身，您还需控制需求的来源，并控制项目可交付工件的外观。 另请参见需求工作流程中的工作流程明细：管理系统规模。

改进系统定义 系统的详细定义应能让涉众理解、同意并认可。它不仅需要具备所有功能，而且应符合法律或法规上的要求，符合可用性、可靠性、性能、可支持性和可维护性。感觉构建过程复杂的部分就应有复杂的定义，这是一种常见的错误看法。这会给解释项目和系统的目的造成困难。人们可能印象深刻，但他们会因不甚理解而不能与系统有效交互。应努力理解正在开发的工件的涉众；通常，不同的涉众需要不同的说明。

我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法，它常与简单的可视化原型结合使用。用例有助于为需求提供一个环境，利用它可生动地说明系统使用的方式。 系统详细定义的另一个构件是说明系统采用的测试方式。

测试计划及要执行测试的定义将会说明要核实哪些系统功能。 另请参见需求工作流程中的工作流程明细：改进系统定义。

管理变更需求 定义需求时无论怎样谨慎小心，也总会有可变因素。变更的需求之所以变得难以管理，不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接可以代表需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线、确定依赖关系的追踪重点、建立相关项之间的可追踪性，以及变更控制等活动。

另请参见需求工作流程中的工作流程明细：管理变更需求以及配置与变更管理工作流程中的工作流程明细：管理变更请求。 受用例驱动的开发 用例是我们推荐用来组织需求的方法。不同于带项目符号的需求列表，通过用例，您可以按照叙事的方式讲述用户可能怎样使用系统。这种方式使需求更加完全，且能够保持一致，同时也可以从用户角度出发更好地认识需求的重要性。

通常，很难通过一个传统的面向对象的系统模型来说明系统是如何完成任务的。难点在于当执行某些任务时，缺乏一条贯穿系统的“主线”。在 rational unified process 中,用例定义了系统执行的行为，所以用例就是那条主线。用例不是“传统”的面向对象技术的一部分，但其重要性却日益显现出来。用例被纳入统一建模语言这一事实进一步证实了这一点。

rational unified process 运用了“用例驱动方法”。此方法意味着为系统定义的用例是整个开发流程的基础。

用例在多个核心工作流程中都发挥了作用。 用例的概念可用来表示业务流程，业务流程的定义在业务工程工作流程中提供。我们称这种用例的变体为“业务用例”。 用例模型是需求工作流程的结果。在这一早期流程中，需要通过用例来建立用户希望系统完成的任务的模型。这样，用例构成了一个重要的基本概念，客户和系统开发人员都必须认可这个概念。

在分析设计中，用例是在设计模型中实现的。您需要生成用例实现来说明在设计模型中如何通过对象的交互来执行用例。此模型根据设计对象来说明所实施系统的各个组成部分，以及这些部分如何通过相互作用来执行用例。

在实施阶段，设计模型就是实施的规约。由于用例是设计模型的基础，所以用例需通过设计类来实施。 在测试期间，用例是确定测试用例和测试过程的基础。也就是说，通过执行每一个用例来核实系统。 在项目管理工作流程中，用例被用来作为计划迭代式开发的基础。

在部署工作流程中，它们构成用户手册阐述内容的基础。用例也可用来确定产品构件如何排列组合。例如，客户可通过将用例进行某种组合来配置一个系统。

开心果

帮顶  

开心果

不错啊! 一个字牛啊!  

开心果

牛牛牛牛  

浮光掠影

楼上的稍等啦  

小米米

呵呵,明白了  

小羽毛

顶你一下.  

清露

呵呵,明白了  

游手好闲

我想要`~  

清风

支持你加分