用例和UP的讨论

有关用例的阐述，最佳来源还是RUP。

下面是一些用户故事示例:

1.客户能申请通过ADSL上网。
    验证测试：
    新客户
    已申请的客户
    没有可用的硬件 资 源

2.客户还可以选择LAN的接入方式。

3.对于选定的接入方式，客户需要指定套餐类型。

4.客户能够修改上网帐户的密码。
    验证测试：
      密码过于简单
      密码不符合密码策略

5.自动停止欠费客户的所有服务。

6.提供欠费客户的名单列表。

7.稽核人员能够查询所有业务的变更明细（业务留痕）。

8.员工必须身份认证成功才能使用业务。

9.员工只能使用授权访问的业务，不允许未经授权的使用。

看起来，不包含交互的需求的确可以使用更少的语言来描述需求，但是毫无疑问，这样的需求如果不进一步分析，是不可能直接拿来开发的。
相比基本用例，其实还是把要做的事情挪了一个位置。
我想知道的是，你们是在哪一步中完成交互的分析的？
测试人员可以以这些交互步骤为主框架，写出测试用例吗？

你说得没错，用户故事就是基本用例的意图部分。
交互还需要进一步的设计，但是它已经不是需求，而是设计的一部分了。
在设计界面的时候，就是在设计这种交互。
用户故事中会包含验证测试的部分，测试员可以根据这些来展开测试。

这样的需求是可以直接拿来开发的，因为可以通过交流，弥补信息的不足，
这也是用户故事的重要要素。

wolfsquare 和partech你们两个讨论的内容，我刚才看了看，我比较认同wolfsquare的观点，partech的观点我一直没看明白，用例不包含交互？不太可能吧。

业务调研和业务分析阶段，我一直采用比较传统的功能分析的方法，没有采用过用例，你们能否先把用例、交互之类的概念统一了，再结合一个实际案例进行讨论，这样要好些，现在我感觉大家是各自按照各自的路线说，讨论的到底是不是一个问题都说不清。

不知道partech是不是想表达这样一个观点：用户故事相当于一个用户角色所执行的一个业务职能，这个用户故事是由一系列的用例构成的，这些用例相当于功能点，每个用例就是一个用户功能点名称和简介而已，不需要定义细节，进行用例编写的目的仅仅是为了捕获需求，细节部分在设计阶段去进行描述。我不知道我的理解是否正确？

没有啊，用例当然包含交互，要不就不叫用例了。用户故事不包含交互。

对于前期调研，我们通常会进行流程分析和业务对象建模，定义词汇表为后面的需求提供必要的背景知识。

你这种交叉使用用例和用户故事的观点比较新颖哦。
我个人认为，用例没有那么粗，它实际上要比一个用例细些，但比用例描述粗些。它同用例的主要区别在于一个是作为需求分析的开始，一个是作为需求工作的产物。并且用户故事是可废弃的，用例则会一直需要维护。这同他们对沟通的强调程度有很大关系。

第一，为什么用户故事就不能包含交互？
第二，为什么用户故事就不能一直维护？
第三，名字有那么重要吗？

1.因为交互是某种设计阿。
2.非要一直维护也不是不可以，只是说不是必须维护，因为需求从测试中可以体现出来。另外一个来源是用户手册。
3.是说词汇表吗？要交流，要协作编码，当然重要。不同的名字表示同样一个意思，同一个名字表示不同的意思，麻烦啊。

我时间不多，简单说点。
首先我觉得在国内使用用例，按照Ivar的方法肯定不行。我想大家都作过项目，看过需求说明。那个文档我想绝大多数人都会承认不是用例。但是用例确实可以使用在我们的工作中，当然方法要做调整。
至于说用例和用户故事应不应涉及到设计，这个问题要先明确这个设计究竟是什么。如果这个设计是功能实现的设计，而不是程序构成的涉及，那么它们都会涉及。而如果是程序构成的设计，确实有些人士有这个方面的说法，包括Ivar。而用户故事则根本不会有这个方面的作用。

写user stories的几个原则（我总结的），
1是反映用户的行为，标明用户意图
2是有足够的信息让developer想象出是什么样子并能评估时间
3是让客户能够明白每个story的涵义
4是用于trace需求，让客户知道你有哪些stories作完了



所以，上面的这些stories有些小问题，例如

这个很明显不是story。没有反映出用户的行为。
这也是story和use case的一个区别：story不关注system作了什么



1 Stories可以包含任何东西，只要你认为需要
2 什么叫维护呢？我们一般都不怎么修改story，只会增加新的story和task

但表达了用户意图。如果需要反映用户行为，如何表达自动化的行为？