如何做需求分析(一)概述

需求定义

通过需求捕获，将系统建立不同的问题域，对每个问题域进行上下文关系分析。问题域可以用组件图来描述；上下文关系用上下文关系图来描述，它描述的其实是业务用例。

按照上下文关系的每个事件建立脉络。

脉络及框架分析

对上下文关系的每个事件进行分析，进行流程分析，描述事件的具体流程，可以用活动图和DFD来描述，在OO中，一般使用活动图。

下一步对活动中的业务实体进行分析，可以通过类图来描述，在需求阶段，类图用来描述业务实体，只用确定类之间的关系和属性，不用过早的确定操作，操作可以在设计阶段再确定。类图在设计阶段要遵守实体的规则，不要对大类进行拆分，对子类进行合并、抽象。这些都是设计阶段要做的事情，这里只要准确的反映实体的关系即可。另外一种表示方法是E-R图，但在OO中一般用类图来表示。

然后通过对业务流程的分析，确定用例模型，建立用例模型的一个要点是要站在系统外部去观察系统。举一个简单的例子，在信用卡系统中“增加客户”这个用例，是在系统内部，以软件开发人员的角度去描述用例，而如果站在系统外部，或站在业务人员的角度去描述则是“信用卡开卡”。
参与者是直接操作系统的外部用户(角色)，可以分为用户、外部系统、时钟，这里要注意是直接操作系统，间接操作系统的用户不是用例中的参与者（如顾客不是参与者，而银行柜员是参与者）

在系统用例中，用例是系统要实现的功能，在活动图中，每个用例活动都可以作为用例，但要区别这个活动是否需求系统完成。另外就是要确认这个活动是否太小，只是一个步骤，就不用作为用例。用例是对参与者有意义的一件事情。

填充细节阶段

根据第二阶段的脉络和框架分析，将每个事件中的用例和类片断整合，可得出系统的用例模型和类模型，填充细节阶段要做的工作主要是对用例规约进行描述内容包括：功能描述、基本事件流、扩展事件流、业务规则、UI原型、约束等。