用Use Case获取需求的方法是否有缺陷，还有哪些地方需要改进

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

Use Case使用原则：

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

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

2.保持对全系统的理解

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

3.关注用户的价值

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

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

一个用例的完成可能要触及整个系统的各个层面（例如，“用户在ATM上完成跨银行的取款”这一用例需要银行系统各个子系统协同修改，才能完成），不同模块间复杂的依赖关系对团队是一个大的考验。

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

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

---

但Use Case的使用也有其局限性。

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

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

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