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

Posted 2020-09-04

Use case通常只能捕获功能方面的需求，但对非功能需求得借助于其它的手段。

传统的Use case模型已经被扩展用于建立领域需求模型,但该模型并不支持领域测试用例的复用和自动生成。给出了领域用例的形式化定义方式,增加了最小数据触发集的描述,提出了用例的动态模型和静态模型概念。扩展活动图用于表示用例之间的动态关系和执行过程,并将值流和对象流融入到活动图的表示中。依据用例的动态模型,可以直接产生测试用例,同时获取测试数据,从而实现领域软件需求与领域测试用例的裁剪过程一致性和同步性。

Use Case的局限性。

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

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

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

Use Case了解

在软件工程中，用例是一种在开发新系统或者软件改造时捕获潜在需求的技术。每个用例提供了一个或多个场景，该场景揭示了系统是如何同最终用户或其它系统交互的，从而获得一个明确的业务目标。用例要避免技术术语，取而代之的是最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

定义：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。"

创建原则：用例是短文；用例可以是一个场景，包括动作和互交；用例可以是一组场景，描述不同场景下的行为；这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求， 业务流程，系统设计说明；用例里不要有系统设计；用例里不要有界面设计；用例里不要有特性列表；用例里不要有测试；用例应该描述行为需求；用例的主场景不要超过九步；可以在适当的层次上得到子目标和移除设计说明。

Use Case使用原则：通过讲简单的故事来传递消息；保持对全系统的理解；关注用户的价值；逐步构建整个系统，一次完成一个用例；增量开发，逐步构建整个系统；适应团队不断变化的需求。

事件流：Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括基本变化，特殊情况，处理错误情况的异常事件流

Use Case 说明书应包括以下内容：功能描述，可用性，可靠性，性能，可支持性，设计约束。

Use Case 由以下元素组成：名称，简单描述 事件流，关系，活动图和状态图，Use Case 图，特殊需求，前条件，后条件。use case是对一项系统功能使用情况的普遍适应的描述