――蘑菇期就是被搁在阴暗的角落、像蘑菇一样不被重视、很可能自生自灭的阶段，新人刚入公司，都会经历这样的阶段，这就是蘑菇期。

  终于了解，什么才是自己与自己赛跑。习惯了在别人的注目下生活，对于无人问津的日子还真有些沮丧。但，抱怨不是本人的风格，咱说正事儿。前几天，我收到了最新的需求分析文档，原以为和想象中差不多，看着文档就能想象出系统的“模样”。（因为需求文档的初稿实在太粗糙，用例图和用例描述有部分不相符，甚至还有前后矛盾的地方存在。）但没想到，更新后的需求分析文档，连用例图都没有了~没有用例图，怎好同客户交流呢？诧异之余，引出了下面的思考。

  1.更新后的文档为什么要把用例图删去呢？通过交流我才发现，原来我们项目组的成员大多没有系统地学习过UML。使用UML图释，那些复杂的用例，以及用例间的include、extended关系，很容易产生歧义。这也正是初稿中出现用例图与用例描述不符的原因。不能增进交流，反而易产生歧义，不要此图也罢。但我还是在私下画了用例图，尽管没有通过这图同用户沟通，在需求的表达上有失偏颇，但画用例图对我理清思路，确定系统边界，还是很有帮助的:)

  2.更新后的文档为什么没有“字段列表”这项内容？首先得说说我们的项目背景。我们的ITSM（IT Service Management）系统是用来取代客户现有系统的。由于现有系统是客户的global公司所有，而客户仅作为一个使用者没有掌控能力，因而萌发了另行开发一套ITSM系统的想法。也就是说，ITSM系统涉及的字段大都与现有系统雷同，仅有小部分改动。而我们知道，IT管理的过程中，涉及到的字段是很多的，我们不可能在需求文档中一一列出，这样容易有缺漏，客户也不愿意去看。还不如用Visio画出UI prototype，这样，无论是客户还是开发人员都更有感觉。（之所以说Visio，因为它可以新建“Windows XP用户界面图”，画出的界面很逼真。）

  然而，我也不得不说，这篇更新后的需求文档还有某些细节上的需求没有阐明，当然，这也并不奇怪，需求本身就是一个迭代的过程。

==========================

  一般习惯将需求分为三个层次：

1. 业务架构

 围绕业务背景、业务目标、业务目标人员、业务参与人员、组织结构、岗位设置等展开，由此搭建起对业务领域的第一了解。虽然第一层次并不足以让人了解具体业务是如何运作的，但业务架构描绘出一幅业务全景，这对于进一步了解需求帮助巨大，这样就不会再迷失在茫茫的需求海洋中了。这一层中，业务用例模型的业务用例视图、领域模型视图被建立起来。

2. 业务流程

 着重让业务流程完整地运转起来，忽略具体的工作细节。在这一层中，包括业务用例实现、用例场景、分析场景在内的完整的业务用例模型和概念模型被建立起来。

3. 工作细节

 基于前面的工作，已经不用再考虑整个业务是什么，只需要专心细致地一点点挖掘参与者的工作细节。当这一层的工作完成后，一个完整的需求模型可以运转了。

==========================

  双杠线中的内容是谭云杰先生在《大象――Thinking in UML》一书中提到的。之前就瞅过，现在又被我翻出来啃，经典的书总有常看常新的感觉:)

  Liam中午在MSN上给我留言，说Matt已经让Eric教我些测试方面的东东。呵呵，又将有新的收获了。但我还是得对蘑菇期的自己说：调整心态，贵在坚持。