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

usecase的局限性

对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。 因此，.故事/人物/场景非常适合交互式的系统，但是对于其他类型的需求（算法，速度，扩展性，安全性，以及和系统技术相关的需求）则不适用。并且故事的粒度没有统一的标准，和每个具体项目有关。初学者比较难以掌控。如果软件的关键在于用户体验的细节，那么如何把这些UI的细节嵌入每个故事中，并仍然保持故事的简明性这是一个难题。有些团队把目前的技术扩展为Use CaseStoryboard，当一个简明的故事加上很多附加说明和图画的时候，这事实上就成为了功能说明书（Function Specification）以及各种帮助建模的图形工具。

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

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

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

Use Case在文档系统和软件需求领域成为一 项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺骗性，即使项目小组在开始使用Use Case 时没有任何麻烦，当他们将其应用于大项目时常常会遇到许多同样的问题。

Use Case 图形符号已经被标准化并作为对象管理小组UML的一部分，但自然语言的Use Case 说明书还没有被标准化。为了成功书写Use Case 说明书，我们需要一个标准模板来保证Use Case 的一致性。