思考题：用Use Case获取需求的方法是否有什么缺陷，还有什么地方需要改进？（提示：是否对所有的应用领域都适用？使用的方便性？.......）

Posted 2020-09-03

思考题：

用Use Case获取需求的方法是否有什么缺陷，还有什么地方需要改进？（提示：是否对所有的应用领域都适用？使用的方便性？.......）

简答：

一.用例解释：

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

二.创建用例的原则：

用例是短文 用例可以是一个场景，包括动作和互交。 用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。 用例里不要有系统设计 用例里不要有界面设计 用例里不要有特性列表 用例里不要有测试 用例应该描述行为需求 用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。 用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

三.Use Cases应用当中的复杂性和危险

1.主要行为者（Actor）和Use Case之间没有连

2.情节步骤不需要连续 

3.Use Cases的大小 

  当开始做Use Cases的时候有个很显然的危险就是它要么有很多步骤要么就很少步骤。如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动的单一线索。

4.较少的人类行为者（Actor） 

5.需求捕获和系统复杂性 

   总而言之，这些情节捕获到系统复杂度的同时行为者：目标语句对容许大的系统以相对压缩的格式说明。Use Case的格式的作用是用户和开发者能标志出行为者，然后确认这些行为者工作职责对应（或不对应）的目标，代替一个大的很难读的功能规格说明书。

仅仅这样，用户和开发者就有足够的兴趣进而研究那些情节的细节。

6.运行时期和建立时期的需求比较

一个重要的因数要记住，就是系统的赞助者是大过用户团体的。系统中有许多的风险承担者，Use Cases仅仅捕获其中一些风险承担者的需要，具体说，Use Cases仅仅捕获系统运行时期的需求而忽略做为系统开发组织的风险承担者的需求，开发组织最有兴趣的是对建立时期需求的描述。

1> 运行时期需求包括：系统范围、用户组织对产品的期望和目标、Use Cases、其它非功能性需求。

2>  建立时期需求包括：减少开发成本、较少的变更处理、现存组件的重用。

3> 建立时期的需求可以部分的由Use Cases把握。但许多方面是需要由开发组织的处理的。

4> 项目范围和目标：项目必须提交什么。（和系统范围的区别是它提交的是所有项目的东西）

5> 增长性和变更请求：这些可以在捕获为常规Use Cases格式中的“Change Cases”

6>开发负责人的约束：包括标准、习惯、工具、品质度量标准、品质保证原则、及品质保证的习惯。

四．Use Case存在的局限性

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