商机被任务执行”或“任务执行BOM商机” 。
请客户评审ERD时,要让他们检查图中所显示的关系是否全部正确、合适和全面。
第二种武器： 孔雀翎——用例法
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（Actor）和用例（Use Cases）。角色表示与系统交互以实现某种目的的人、硬件或软件系统。
判断角色唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述，它描述了触发用例时受到刺激下反映的本质，输入和输出到其他活动者和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。 用例也可以用活动图来表示。
这样说可能会非常复杂，其实一个用例描述了系统和一个角色的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。
用例可以完成的目标如下:
用例捕获某些用户可见的需求，实现一个具体的用户目标。
用例由角色激活，并提供确切的值给角色。
用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。
用例转变了需求开发的角度，传统的需求分析方式是研究用户需要用系统做什么，而现在则是讨论用户需要实现什么。用例法的目的是描述。
通常我们是用如下方法确定用例：
首先明确执行者和他们的角色，然后确定他们各自参与了哪些业务过程。
系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。
用特定场景来描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色。
商机追踪系统就采用了第一种方法，我召开了一系列用例获取和分析讨论会，每周一到两次，每次会前都要请用户思考他们需要使用新系统执行什么任务。我发现，用例的名称应该表明用户需要达到的目标，而描述用例则需要在名词中使用动词。如此一来，才能真正描述用户的执行任务，即分析员需要描述的用例。
经过需求分析, 该电子公司商机管理的角色如下:
商机成员：其职责是发布商机。
商机管理：其职责是处理和分配商机任务, 常有如下动作:商机分配、验证、询价、议价、索样、确定。
第三种武器： 碧玉刀——原型法
原型是模型、样品的意思，显然它借鉴了制造业承接批量订单前先索要样品的经验，在系统初始阶段以可以运动的原型来说明需求和分析需求，给人以豁然开朗之感。 这里的思想实际上是以设计来获取需求,以设计原型的“砖”引出了真正需求的“玉”。我们也应该看到现在软件工具的可视化也是促成原型法得以快速生成的原因所在。原型实际上也分为几种：界面原型、概念模型、数据模型。心理学亦表明人们对活动着的界面原型的理解力远远大于对静态事务的理解，这就好像影像对视觉的冲击力远远大于文本一样。
一个快速实现的原型在整个需求开发过程中具有如下作用：
- 明确并完善需求
- 研究和设计选择方案
- 可发展为最终产品
原型的好处有很多, 掌握如下的原则去构建原型相信能获得更佳的效果：
- 安排在项目计划中的创建原型的任务和安排资源。
- 创建之前要陈述用途。
- 创建废弃型原型要尽量快速和经济,最少投资开发那些用于回答问题和解决需求不确定性的原型。
- 对于已经理解的需求不要建立原型,除非是研究设计选择方案。
- 在屏幕显示和报告中使用看似真实的数据。
- 不能期望用原型去代替软件需求规格说明（Software Requirements Specification，SRS）。
- 设计原型可以参考同类型软件的界面, 但设计不要脱离现实需求和目标。
好，现在就让我们来一窥商机追踪系统原型界面的庐山真面目吧。
从上面的原型界面看来，它是HTML的网页格式, 看上去很真实。但我们也会发现，原型法和敏捷开发(XP)的区别在于功能：原型法侧重在于界面和概念的定义，而敏捷开发则重在功能的迭代实现。