2008-2-27 21:49:00 dxyot： 有一个问题想问您 在写基本路径的时候 需要用户选择处理方式 而处理方式有好几种 可以选择其中一种方式作为基本路径吗 其它的写在扩展路径里？
2008-2-27 21:50:04 潘： 看用户的意思，如果在用户看来，这些是平等的，那就这样写： 3. 用户可以 创建新订单 修改现有订单
2008-2-27 21:50:20 潘： 然后出来3a 和3b 扩展路径
2008-2-27 21:50:46 潘： 你的具体用例贴上来看看
2008-2-27 21:51:58 dxyot： 原来我是这么写的：
2008-2-27 21:52:24 dxyot： l
执行者注册用户
前置条件 1. 用户具有小组管理员权限 2. 小组处于开放状态
后置条件 系统发送审核消息给成员 l
涉众利益 1. 用户担心审核通过后，成员还没有加入该小组。
基本路径 1. 系统显示需要审核的成员
2. 用户选择允许加入的处理方式
3. 系统将该成员加入到小组
4. 系统发送审核通过消息给该成员
5. 系统提示该成员已加入小组。
扩展
a2. 用户选择拒绝的处理方式：
a21. 系统发送审核不通过消息给该成员
a22. 系统提示该成员被拒绝加入小组 l
字段列表 l 业务规则 l 非功能需求：无 l 设计约束：
无
2008-2-27 21:53:03 潘： l 后置条件 系统（已）发送审核消息给成员
2008-2-27 21:54:34 dxyot： 这里有两种处理方式：允许加入和拒绝加入
2008-2-27 21:54:53 潘： l
基本路径
1. 系统显示需要审核的成员（第一句不能是系统，要加1. 用户请求审核申请）
2. 用户选择允许加入的处理方式（什么处理方式？不同处理方式会不会引起和系统的交互的变化？这是判断需不需要扩展点的根据） 3. 系统将该成员加入到小组
4. 系统发送审核通过消息给该成员
5. 系统提示该成员已加入小组。
2008-2-27 21:56:18 dxyot： 好的 记住了 我改过来
2008-2-27 22:23:00 潘： 从这里看来：
1. 用户对于审核是否通过并无偏好；
2. 拒绝还是通过，系统对外需要的交互（发消息给成员，给用户提示）没有变化，只是根据不同规则影响了消息的内容，所以可以不需要扩展点。
2008-2-28 8:56:54 dxyot： 哦 允许加入和拒绝加入应该是两个操作步骤 那这里是不是犯了 把步骤当用例的错误
2008-2-28 9:13:35 潘： 允许加入和拒绝加入，系统对外的交互有没有变化
2008-2-28 9:18:00 dxyot： 对外是没有变化的 但允许加入需要系统将成员加入到小组 而拒绝加入系统只是发送拒绝消息给成员
2008-2-28 9:22:00 潘： 噢，看漏了，那这个是不同的。还是回到开始的：用户可以选择以下处理方式： 允许加入 拒绝加入
2008-2-28 9:22:10 潘： 然后放在扩展点里
2008-2-28 9:22:57 潘： 或者，写"系统根据所选择审核结果作相应处理"，把细节写在业务规则里面
2008-2-28 9:35:38 dxyot： 对用户来说 审核无非就是允不允许成员加入
2008-2-28 9:44:09 潘：
1. 用户请求审核申请
2. 系统显示需要审核的成员
3. 用户选择成员，给出审核结果
4. 系统根据审核结果作相应处理
5. 系统反馈该成员审核完毕
3a. 审核通过：
3a1. 系统将该成员加入到小组
3a2. 系统发送成功消息给成员
3b. 审核不通过：
3b1. 系统发送拒绝消息给成员
2008-2-28 9:44:36 潘：
4a. 审核通过：
4a1. 系统将该成员加入到小组
4a2. 系统发送成功消息给成员
4b.审核不通过：
4b1. 系统发送拒绝消息给成员
2008-2-28 9:50:51 dxyot： 系统需不需要记录审核状态 防止再次被审核？
2008-2-28 9:52:15 潘： 记录审核结果，不是记录审核状态
2008-2-28 9:52:29 dxyot： 对
2008-2-28 9:52:46 潘： 要的
2008-2-28 9:52:55 潘： 这属于"改变"
2008-2-28 9:53:50 dxyot： 在4 的下面加一条"系统记录审核结果"?
2008-2-28 9:54:22 潘： 是
2008-2-28 9:55:35 dxyot： 写好一个用例真不容易啊 呵呵
2008-2-28 9:56:53 潘： 第二个，第三个就好了，无非是怎样才能反映涉众的心情，不别扭就行了
2008-2-28 9:59:36 dxyot： 有时往往就从技术角度来考虑了 需要多向您请教才行
|