为什么用例不是“功能”？是？还是不是？【原创】

     今天读了一篇文章 讲得就是 人们对用例的误解。感触比较大，而且和公司上司意见不大一致，所以写下来，希望证实对否？
相信大家都看过这篇文章“为什么用例不是“功能”？”
以下我想阐述几个自己的观点，如有不对的地方，欢迎大家指正。
1.用例应当在需求调研之后，需求分析之前先行。
2.用例应当贯穿整个项目前期（需求和设计）。

     当我们在接到一个项目任务的时候，首先想的是什么？ 是 客户想通过这个软件来做什么？
那么这个时候通过需求调研，获得大致的需求。
我们当下需要做的就是用例（可以叫概念级用例）
何谓 “概念级用例” 就是把软件的特例 进行描述 用以表达软件将要完成的,描述某人某物如何使用系统来完成对他们有价值的事情，它描述了系统在概念层次上做什么，使我们足够理解系统以便决定系统是否要做恰当的事。概念级用例是我们能够形成一个系统的概念模型。。

例如图1.

明确表示 客户 想使用 软件 做什么?

    当我们在完成了系统级用例，对客户使用软件来完成什么事情清晰之后，我们同步需求分析，将需求概要根据该用例逐步完成，这是一个迭代的过程。
当我们的需求做到详细分析阶段，那么设计也到了这个阶段，用例图的下一个层次就是 功能级用例。
     功能级用例 用以描述 具体功能细节，为代码编写做准备。也就是我们很多人平常理解的“用例”、
很多人（包括以前的我）心中的用例图：
例如图2

 描述功能级关系
关注价值

很多人认为用例不可以先行，我觉得用例可以驱动需求分析，也可以进行设计迭代。
先行之用例即为概念级用例，用以描述软件粗粒度的服务，用以明确软件之真正目的，以抑制软件的需求歪曲和不可控。（当然需求管理在起至关重要的作用）
在概要设计完成之后，需求分析进入详细分析阶段，用例进行细化，从而实现功能级用例。用以实现详细设计。

举例

考虑一个你在互联网上用过的一个电子商务系统，当你登录这个站点的时候，你的目标可能是查找产品相关的信息、选择要购买的产品、安排支付及送货约定。在做这些事的过程当中，你可能会改变主意、输入错误的信息以至不得不修改它、改变邮递或送货地址，以及其他的一些东西。如果这个网站不允许你通过一种吸引人的方式来找到并订购产品，你也许不会完成你的订购，更不用说再次来到这个网站。

当建造一个系统时，始终要记住用例的核心定义：关于采用某种方式使用系统来做有价值的事情的故事。如果你能够实施这个定义，展示用户希望通过系统获得的价值，然后创建反映这些价值的用例的时候，你的系统将会更好地满足用户的期望。

转载于:https://www.cnblogs.com/Fly-sky/archive/2009/09/25/1574134.html