种为业界所广泛采用并经验证的需求捕获方法，即用例模型。 用例模型是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。
　
　　用例模型用作分析，设计和测试活动的基本输入。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。参与者（Actor）和用例（UseCase）是用例模型中的主要元素。 下图显示了自动取款机系统用例模型的一部分：

　　客户

　　查询

　　提款

　　转帐客户身份验证系统时钟

　　数据库服务器

　　（from ）系统维护

　　信函打印机

　　打印对帐单

　　用例图用于显示包含参与者和用例的用例模型示例。系统建模有许多种方法，每种建模方法可以满足不同的目的。然而，用例模型最重要的作用是将系统行为传达给客户或最终用户。可能与该系统交互的用户和任何其他系统都是参与者。由于参与者代表了系统用户，它们协助界定系统并提供十分明确的系统用途说明。编写用例依据参与者的需求来进行。这样就确保该系统成为用户期望得到的系统。
　
　　参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的。找到这些用例和参与者后，应对它们作简要说明。在详细说明这些用例之前，客户应复审该用例模型以核实所有的用例和参与者都已经找到，并且它们可以提供客户所需要的东西。 在迭代开发环境中，您可以选择用例的子集以便在每个迭代中详细描述。参与者和用例找到后，需要详细说明每个用例的事件流。这些说明指出系统与参与者交互的方式以及在各个独立用例中系统执行的有关操作。
　
　　最后，对已完成的用例模型（包括用例说明）进行复审，开发人员和客户使用该模型对系统应执行的操作达成一致意见。
　
　　需求管理模型在需求管理的流程中，需求的捕获手段固然重要，但在需求的捕获和需求最终成型的过程中，我们会面临各种和需求相关的信息和资料（也可以把这些信息笼统地称做"需求"），如何发现这些信息之间的关系并有效组织，更为关键。 需求类型 在RUP中，我们采用一种金字塔方式的管理办法，来组织和管理我们获取的信息乃至最终的需求。
　
　　为了建立一个真正满足客户需求的系统，项目团队首先必须确定系统要解决的问题。然后，团队必须确定涉众，从中获得业务和用户需要，对其进行描述，并区分它们的优先级。从这一组高层期望或需求出发，对产品或系统特性集达成一致意见。而后，由产品特性来抽取软件需求，在我们的模型中，软件需求是以用例模型的方式来描述。从测试的角度来看，测试项一定来自于软件需求，即软件需求中确定了哪些需求项，测试就要根据这些需求项来制定和实现。
　
　　系统越大越复杂，出现的需求类型就越多。一个需求类型不过是指需求的一个类。通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。从上述的分析中我们可以看到，通常，一类需求可以细分即分解成其他类型的需求。这里，我们就把需求分解为几种类型，并在他们之间建立相应的关联。业务规则和前景声明包括高层次的需求，团队可以从中导出用户需要，特性和产品需求类型。用例和其他建模形式驱动设计需求，该需求可分解为软件需求，并可以用分析设计模型来说明。测试需求源于软件需求，它被分解为具体的测试过程。如果既定项目中有成百上千个，甚至上万个需求实例时，对需求进行分类可以使项目更容易管理。上述的这些需求类型同时保存在对应的RUP文档和数据库中。
　
　　应用需求类型通过定义需求类型，以及他们之间的关系，我们就建立了一个需求管理模型的框架。当然，我们建立这样的一个模型，是为了方便我们使用需求，为了达到这一目的，我们还需要在此基础上添加相应的内容。 需要对各种需求类型添加它们的属性，以便于对需求进行查询等管理手段。比如，可以针对用户需要，确定该需要的必要性，优先级，确定性等属性。在实际的项目中，就可以确定这些属性的值，而后根据这些实际属性值来安排项目的进度表等。或是在项目进度紧急时，确定哪些需求是可以延期完成，而哪些是必须完成的，等等。

上一页  [1] [2] [3] 下一页

【责编:Lili】