|
锁定老帖子 主题：用例和UP的讨论
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-11-06
partech 写道 冰云 写道 所以，上面的这些stories有些小问题，例如 引用: 5.自动停止欠费客户的所有服务。 这个很明显不是story。没有反映出用户的行为。 这也是story和use case的一个区别：story不关注system作了什么 但表达了用户意图。如果需要反映用户行为，如何表达自动化的行为？ 要考虑到客户如何验收这一张story，如果没有交互界面或任何能够看到的部分， 客户怎么会知道你做了什么？ 可以改为： 用户应该能够在被系统自动停止服务后获得通知，以便能够及时续费 |
| 返回顶楼 | |
|
发表时间：2005-11-07
冰云 写道 要考虑到客户如何验收这一张story，如果没有交互界面或任何能够看到的部分， 客户怎么会知道你做了什么？ 可以改为： 用户应该能够在被系统自动停止服务后获得通知，以便能够及时续费 这没有问题阿。 在验证测试中添加： 未欠费客户 欠费客户 你建议的故事主要表明了客户的意图，这不同于表现Purchaser意图故事“自动停止欠费客户的所有服务”，两者的受益者是不同的。不过它们可以组成一个 epic。来描述客户和Purchaser共同关心的主题。如下：
自动停止欠费客户的所有服务，以维护运营商利益。
验证测试:
未欠费客户
欠费客户
提供欠费客户的名单列表。
欠费客户能够在被系统自动停止服务后获得通知，以便能够及时续费。
|
| 返回顶楼 | |
|
发表时间：2005-11-08
dlee 写道 另外大多数情况下，文本形式的用例比 UML 图形形式的用例更加有用。 有道理, 感同身受 |
| 返回顶楼 | |
|
发表时间：2005-11-09
ozzzzzz 写道 至于说用例和用户故事应不应涉及到设计，这个问题要先明确这个设计究竟是什么。如果这个设计是功能实现的设计，而不是程序构成的涉及，那么它们都会涉及。而如果是程序构成的设计，确实有些人士有这个方面的说法，包括Ivar。而用户故事则根本不会有这个方面的作用。
在用例中尽早的考虑和挖掘功能实现的设计,正是用例增值所在。如果没有交互细节，用例又将变成一堆类似于"IEEE标准的'系统将...'". |
| 返回顶楼 | |
