X项目是一套服务公司销售与客服的系统。我们部门是系统开放方。我作为开发人员在项目初期就投入到热火朝天的需求调研中。。。
需求方是公司Y部门（可以理解为营销支撑技术部门），所以需求方是懂技术滴！这为需求调研带来了极大的便利。
下面介绍下整个需求调研过程，省略了一些细节过程。
调研过程0、项目经理和技术负责人与需求方进行了第一次沟通。（我没有参与）
这一过程，我没有参与。 主要做的事情应当是初步了解Y部门需求。
1、需求方提出了“X系统特性需求V1”版本；
这是第一次沟通的结果，需求方把这个“特性需求”发给我们项目组（参与需求调研的有四人）。
2、针对“X系统特性需求V1”项目组内部进行了第一次沟通，并整理成“X系统特性需求V1-建议与疑问”；
拿到这个 “特性需求”后，内部进行了多次沟通。最终出了一份“建议与疑问”。
3、将“X系统特性需求V1-建议与疑问”发给需求方，并和需求方进行了第二次沟通，并整理出“X系统特性需求V2”版本；
这次是我和需求方的第一次接触，主要针对我们提出的问题，需求方给出解释，并接受了一些建议，又出了一版“特性需求”。
4、针对“X系统特性需求V2”，项目组内部抽象出系统一级功能模块；
对于新版的“特性需求”，我们首先想到的是抽象成系统功能模块，并确定了系统功能模块一级大类。
5、项目组内部成员利用1-2天时间对一级功能模块进行了细化，功能细化到3级（1，1.1，1.1.1），并整理成“X系统功能需求V1”。
参与需求调研的几个同事分别对一级模块进行了细化，并整理出了一份系统功能需求。
6、 将“X系统功能需求V1”发给需求方，并和需求方进行了第三次沟通。
沟通前，我们所思考的是系统功能是否完善。开会的时候，需求部门却提出这样的一个功能需求不是他们需要的东西。
因为他们还需要和十多方系统使用者去谈。他们希望看到的是Actor、UC以及Actor和UC之间的对应图----也就是我们需要设计出系统的用例模型。
用例建模
ICONIX过程
针对需求方提出的非常专业的用例驱动开发，项目组进行了讨论，最终我们注意到了ICONIX。ICONIX类似于RUP，也是用例驱动的，不过规模较小，比较紧凑。规模在RUP和XP之间。
下图是ICONIX过程：
1、域建模(Domain Model)
2、用例建模(User Case Model)
3、需求复核
4、健壮性分析 (Robustness)
5、初步设计复核
6、时序图(Sequence Diagram,绘出设计级类图）
7、关键设计复核
用例建模步骤
目前我们走到了用例建模，下面简单的介绍一下用例建模：
1、系统用户是谁？
X项目的需求方是公司的Y部门，系统的使用者至少有10多方。所以首先要确定的就是actor。
2、系统用户想要做什么？
确定actor以后，需要问的就是每个actor想要做什么，这时要做的就是在一大堆UC中为actor分配对应的UC。
3、创建用例。
首先确定尽可能多的用例，然后不断地编写和改进描述这些用例的文字。在这一过程中，有可能发现新的用例和通用情况。
4、创建用例模板。
用例模板主要包括：主事件流、分支流、前置条件、后置条件等。可以根据实际情况进行取舍。
主事件流和分支流确定方法：
1）提出问题“将发生什么”，进入主事件流。
2）不断提出问题“然后将怎样”，完善主事件流。
3）提出问题“否则将如何”，确定分支流。
用例模板可以参考http://www.javaeye.com/topic/61183 给出的两款模板。
用例建模目标
如何确定用例建模是否完成，判断是否完成以下目标即可。
2、对于每个用例，基本流程和分支流描述清晰、准确；
3、确定了用例通用的地方。
用例建模常犯的错误
10.编写功能性需求，而不是编写使用场景文本。
9.描写属性和方法而不是使用情况。
8.编写用例过于简洁。
7.让自己和用户界面完全脱离。
6.不给边界对象提供明确的名称。
5.不从用户的角度进行编写，并使用被动语态。
4.只描述用户交互，而忽略系统作出的响应。
3.不描述操作的分支流程文本。
2.不将重点放在用例内部，而是放在如何到达这里或以后将发生的情况。
1.花一个月的时间来决定使用包含结构(include)还是扩展结构(expand)。
参考书籍
《用例驱动的UML对象建模应用—范例分析》