用Use Case获取需求的方法是否有缺陷，有什么地方需要改进？

（提示：是否对所有应用领域都适用？使用的方便性？）

使用use case 的原则

1.通过讲简单的故事来传递信息。

　　讲故事是最有效的人与人交流信息的途径，通过将故事（use case），团队成员能对需求有一个统一的了解。当我们用自然语言讲故事时，我们会不自觉地把复杂的系统当作一个黑盒子，把重点放在用户的愿望、行动上面，这种做法非常有利于我们找到用户的需求和软件的功能点。当然，讲故事要包含具体行动（Actionable），并且是可以验证的（Testable），所以讲故事也要技巧。

2.保持对全系统的理解

　　虽然每个用例都是一个简单的故事，但不要忘记他是整体系统的一个部分。

3.关注用户价值

　　别迷失在长长的功能列表中，牢记软件的价值在于给用户提供价值。

4.逐步构建整个系统，一次完成一个用例。

　　Ivar认为这是use case 2.0方法论中最重要的一个观点。一个用例的完成可能触及整个系统的各个层面（例如，“用户在ATM上完成跨银行取款,”这一用例需要银行系统各个子系统协同修改，才能完成），不同模块荐复杂的依赖关系对团队是一个很大的考验。

5.增量开发，逐步构建整个系统。

6.适应团队不断变化的需要。

Use Case 方法论的理念和敏捷、MSF大致相仿；他对细节的要求和典型人物、场景有很对相似之处。这些方法也有局限性：

1.故事/人物/场景非常适合交互式的系统，但是对于其他类型的需求(算法，速度扩展性，安全性，以及和系统技术相关的需求）则不适用。

2.故事的粒度没有统一的标准，和每个具体项目有关。初学者比较难以掌控。

3.如果软件的关键在于用户体验的细节，那么如何把这些UI的细节嵌人每个故事中。并仍然保持故事的简明性?这是一个难题。有些团队把目前的技术扩展为Use Case Storyboard，当一个简明的故事加上很多附加说明和图画的时候，这事实上就成为了我们下面要提到的功能说明书(Functional Specifcation)，以及下一章要提到的各和帮助建模的图形工具。