RUP：通过用例应用需求管理(下)

　　问题 确定问题

　　对涉众影响 列出受问题影响的涉众

　　问题的影响 描述问题的影响

　　成功的解决方案 列出成功解决方案的一些主要优点

　　问题说明简明扼要解释了项目的目的。问题分析员深入调查所有涉众请求和初始商业理由，包括显著优点以及大致估计的成本等。在定义问题说明的同时，团队还应该编写词汇表，记录常用术语并统一其定义。

　　用例模型简介

　　用例模型包括主角、用例以及它们之间的关系。主角代表了必须与系统交换信息的所有事物，包括通常所谓的用户。当主角使用系统的时候，系统执行一个用例。好的用例是一个事务序列，该序列为主角提供一个可评测的价值结果。用例集合是系统的完整功能。

　　Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison Wesley - ACM Press, 1992

　　问题分析员还确定系统的主要主角。主角是系统的用户或者将与之交换信息的其他任何系统。在这一阶段，问题分析员应该简单确定主角与系统交互的一些显而易见的方式。说明应面向业务流程而非系统行为。例如，预算程序可能会允许一个类型的主角“制定部门预算”，而其他类型的主角可以“合并部门预算”。系统分析员以后可以将它们用到其他用例中，这些用例与特定系统行为结合起来更有意义。例如，“制定部门预算”可以产生像“导入电子表格信息”以及“创建预算视图”等系统用例。

　　上述问题分析会话通常进行不止一次，会话对象可能是不同的涉众，并且中间还夹带开发团队的内部会话。与涉众打交道的系统分析员将主持一次与开发团队成员的会话，展望问题的技术解决方案，从初始涉众输入中导出特性，并起草前景说明，即待建系统的第一个定义。为了方便初始涉众理解提议的解决方案，系统分析员可以利用建模工具或手工绘图技术来完善前景说明。

　　要从多方面向初始涉众咨询，以帮助改进问题说明，限制可能解决方案的个数和规模。涉众和系统分析员就关键特性的优先级进行谈判，对资源及开发资源所需的工作量取得一般性的理解，藉此来管理该工作流程中的依赖关系。尽管优先级和工作量/资源的估计不可避免会发生变化，但提早管理依赖关系可建立起一个在整个开发生命周期中一直延续使用的重要模式。这是规模管理的本质所在，是一个项目成功的早期预报器。

　　在经过几次草案更新后，前景文档进入团队必须决定是否对额外需求获取进行投资的阶段。同时，商业理由的批准过程也分别开始启动了。本文不打算深入探讨商业理由，只对其进行简单说明。商业理由描述：

　　1 环境(产品领域、市场和规模)，

　　2 技术方案，

　　3 管理方案(时间安排、风险、对成功的客观评测方法)，

　　4 以及财政预测。

　　工作流程明细：理解涉众需要

　　如果初始问题分析证明增加投资是合理的，则郑重开始理解涉众需要工作流程。这一阶段的关键活动是获取涉众请求。主要结果是收集确定优先级的涉众需要和特性，利用此结果可改进前景文档，加深对需求属性的理解。另外，在这个工作流程中，您可以根据用例和主角对系统展开讨论。另一个重要输出结果是经过更新的词汇表，它使团队成员对常用词汇有一致的理解。