IT项目管理之需求管理工作流

星空无垠

　以下为RUP推荐的需求管理工作流图:

　　1.问题分析
   
　　问题分析可以通过了解问题及涉众的最初需要，并提出高层解决方案来实现。它是为找出“隐藏在问题之后的问题”而进行的推理和分析。问题分析期间，将对“什么是面临实际问题”和“谁是涉众”等问题达成一致。而且，您还要从业务角度界定解决方案，以及制约该解决方案的因素。您应该已经对项目进行过商业理由分析，这将便于您更好地预计能从构建中的项目中得到多少投资回报。

　　2.理解涉众需要

　　需求来自各个方面，比如来自客户、合作伙伴、最终用户或是某领域的专家。您需要掌握如何准确判断需求应来源于哪方面、如何接近这些来源并从中获取信息。提供这些信息主要出处的个人在本项目中称为涉众。如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。通常讨论将在业务模型这一级上展开，而不是在系统这一级上展开。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。获取需要的活动可使用这样一些技巧：访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。获取结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。

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

　　4.管理项目规模

　　为使项目高效运作，应仔细根据所有涉众的需求确定优先级，并对项目规模进行管理。有的开发人员仅仅重视所谓的“复活节彩蛋”（即开发人员感兴趣或觉得有挑战性的特性），而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面，这已使太多的项目蒙受损失。为确保尽早解决或降低项目中的风险，应以递增的方式开发系统。要慎重选择需求，以确保每次增加都能缓解项目中的已知风险。要达到目的，您需要和项目的涉众协商每次迭代的范围。通常，这要求具备管理项目各个阶段的期望结果的良好技能。除了控制开发过程本身，您还需控制需求的来源，并控制项目可交付工件的外观。

　　5.改进系统定义
   
　　系统的详细定义应能让涉众理解、同意并认可。它不仅需要具备所有功能，而且应符合法律或法规上的要求，符合可用性、可靠性、性能、可支持性和可维护性。感觉构建过程复杂的系统就应该有复杂的定义，这是一种常见的错误看法。这会给解释项目和系统的目的造成困难。人们可能印象深刻，但他们会因不甚理解而无法给出建议。应该致力于了解您制作的系统说明文档的读者。您可能常会发现需要为不同的读者准备不同的说明文档。
   
　　我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法，它常与简单的可视化原型结合使用。用例有助于为需求提供一个环境，利用它可生动地说明系统使用的方式。

　　系统详细定义的另一个构件是说明系统采用的测试方式。测试计划及要执行测试的定义将会说明要核实哪些系统功能。

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

z12

谢谢分享  

q12

写得好啊　估计有马甲  

c1532

哈哈，看的人少，回一下  

啊12

先看看怎么样！  

guli

支持~~  

a12

回帖是种美德.  

s23

自己知道了  

anything

呵呵,支持一下哈  

ctdsb2011

(*^__^*) 嘻嘻……