2007-6-25 17:29:13 jun_zhang： 有些东西可能理解不是很好，我想如果写分析报表的话，那会写很多这样的用例
2007-6-25 17:30:28 潘： 有多少个用例看涉众的看法，如果涉众看来没有太大区别，就写"查看统计结果" 之类即可。具体问题具体分析，你要去揣摩涉众的心意 （2011 补注：应从业务流程提炼最佳的结果）
2007-6-25 17:32:53 jun_zhang： 哦，就是可以将那些分析报表的需求抽象成"查看统计结果"，然后在实现的时候再把报表系统加进来，可以这样理解吗
2007-6-25 17:33:07 潘： 具体问题具体分析，你要去揣摩涉众的心意。另外，哪有什么报表系统，这些是项目的一部分功能吧？
2007-6-25 17:33:56 jun_zhang： 也是，不是报表系统了，就是一个功能，但对于用户来讲这个功能是无所谓的。如你没有这个功能，也可以为用户的每个报表都做一个页面来实现，用户也认为是一样的
2007-6-25 17:36:21 潘： 用页面实现的就不叫报表功能？
2007-6-25 17:37:57 jun_zhang： 对于用户来讲是一样的，但我们为了不要每做一张报表都做一个页面，自已做了一个定制报表的功能
2007-6-25 17:38:44 jun_zhang： 我刚才说的报表系统不对，应该是定制报表的功能，这样比较恰当点。这样的话定制报表功能需要写在需求用例中吗
2007-6-25 17:40:51 潘： 都要
2007-6-25 17:42:16 jun_zhang： 您是说用户要的分析报表还有我们的定制
2007-6-26 21:10:06 潘： 首先，形式上，完工的用例图，一个用例只能有一个主执行者
2007-6-26 21:10:58 jun_zhang： 哦，这个我明白，就是说要有泛化，对执行者
2007-6-26 21:11:32 潘： 所以，定制，查看主题报表，的主执行者应该只有一个，例如操作员，系统管理员是操作员的一种
2007-6-26 21:11:53 jun_zhang： 嗯，这个我会修改的
2007-6-26 21:11:57 潘： 查看自由报表什么意思？涉众知道什么叫自由报表吗
2007-6-26 21:12:14 jun_zhang： 就是浏览自由报表的数据
2007-6-26 21:12:38 jun_zhang： 是我们自已定义的，有部分涉众是知道的。比如系统管理员
2007-6-26 21:14:06 潘： 这个不是涉众关心的，也许设计人员认为查看线损、查看电量用的模块都差不多，只是执行的SQL 语句不同，但涉众不关心这些。去掉自由报表这种东西
2007-6-26 21:15:00 jun_zhang： 是的，最终用户要的是上面的三个分析数据
2007-6-26 21:14:31 潘： 使用系统不都是看数据，改数据吗
2007-6-26 21:15:01 潘： 要不要每个功能泛化出一个查看数据，修改数据？
2007-6-26 21:15:47 潘： 请看需求幻灯片的CRUD 部分，用例和数据的关系
2007-6-26 21:15:52 jun_zhang： 我们要做的是一个综合分析系统，所以数据一般都不会去改
2007-6-26 21:16:15 潘： 什么叫"一般"？
2007-6-26 21:16:17 jun_zhang： 嗯，我原来有写原操作员管理/权限管理之类的用例
2007-6-26 21:16:33 jun_zhang： 数据是不会改
2007-6-26 21:16:51 jun_zhang： 因为数据是从另外的系统中导进来的
2007-6-26 21:17:05 潘： OK。形式上就是这些问题。
2007-6-26 21:17:32 jun_zhang： 操作员管理/权限管理之类的用例这样的用例要的吗。这些东西用户不会明确提出，但可算作是非功能性的安全方面的需求。要写在用例中吗
2007-6-26 21:19:06 潘： 要的。这些用例大同小异，写起来很简单
2007-6-26 21:19:34 潘： 这不是非功能需求
2007-6-26 21:19:34 jun_zhang： 嗯，是的，但都要写是吧
2007-6-26 21:19:44 jun_zhang： 怎么呢
2007-6-26 21:19:52 潘： 都要写
2007-6-26 21:20:17 jun_zhang： 为什么不是非功能需求，那是什么呢
2007-6-26 21:21:20 jun_zhang： 用户没有提这些啊
2007-6-26 21:21:28 潘： 非功能需求是一种度量指标
2007-6-26 21:21:42 潘： 用户没有提的就叫非功能需求？
2007-6-26 21:22:07 潘： 那他今天提了，岂不是又可以叫功能需求？
2007-6-26 21:23:06 jun_zhang： 我感觉是这样
2007-6-26 21:23:28 潘： 功能需求：系统应该做某事
2007-6-26 21:23:41 潘： 非功能需求：系统应该达到某指标
2007-6-26 21:24:35 jun_zhang： 嗯，好的，那我再问下，为什么用户没有提操作员管理，但在用例中还是要写呢
2007-6-26 21:25:26 潘： 你不写也不做不就行了吗
2007-6-26 21:26:10 jun_zhang： 不做不行啊
2007-6-26 21:26:16 潘： 为什么
2007-6-26 21:26:53 jun_zhang： 因为没有登录就没有最基本的安全性了啊
2007-6-26 21:27:01 潘： 像我用Word 写文章就没有什么操作员管理啊
2007-6-26 21:27:43 jun_zhang： 嗯，是用户希望系统安全
2007-6-26 21:27:55 jun_zhang： 涉众利益
2007-6-26 21:28:01 潘： "用户"这个说法就不正确
2007-6-26 21:28:13 潘： 需求不是由用户提出来的
2007-6-26 21:28:29 jun_zhang： 那是谁提呢
2007-6-26 21:28:36 潘： 是平衡了涉众利益得到的
2007-6-26 21:28:46 潘： 是不是用户提什么你做什么？
2007-6-26 21:29:30 jun_zhang： 可能我说的"用户"就是涉众
2007-6-26 21:30:09 jun_zhang： 说用户的确不够准确
2007-6-26 21:30:53 潘： 既然是涉众，那应该是涉"众"才对，你应该说清楚是哪一种人需要安全
2007-6-26 21:31:48 jun_zhang： 好像很难说出来啊，我又想说用户了，就是系统的用户。潘老师您说呢
2007-6-26 21:32:56 潘： 我可说不出来啊，你还是需要再回去看看我的幻灯和模型，把这些问题想清楚，其实我课上都讲了的
2007-6-26 21:34:52 jun_zhang： 是的，你课上讲过的，可能这样东西比较抽象，很多东西没理解
2007-6-26 21:35:10 jun_zhang： 可能没有真正做到一次是很难理解的
2007-6-26 21:35:55 潘： 理解不理解，看你站在涉众的角度看问题的程度，学会从涉众的角度看问题了，就行了
2007-6-26 21:37:54 jun_zhang： 再说这个涉众的问题，假如我们这个系统是为电力局做的，那么我可以说需要用户登录是考虑了电力局的利益吗
2007-6-26 21:38:25 潘： 这个应该你自己想啊。没有这个功能，谁的直接利益会受损害
2007-6-26 21:40:19 潘： 电力局也不是铁板一块啊
2007-6-26 21:40:51 jun_zhang： "电力局也不是铁板一块啊"怎么说呢
2007-6-26 21:41:33 潘： 电力局里面也不是只有一个人
2007-6-26 21:42:07 潘： 考虑了电力局的利益－－这个说法说明你还是没有搞清楚有哪些涉众
2007-6-26 21:44:05 jun_zhang： 是的，我说的是很笼统，那如果把电力局涉及本系统的人员按岗位分类就可以了
2007-6-26 21:46:45 jun_zhang： 先与系统涉众勾通，了解他们与系统相关的利益，然后再综合分析出需求，是这样吗
2007-6-26 21:46:54 潘： 对
2007-6-26 21:48:23 jun_zhang： 那么，潘老师，我还有另外一个问题，那是就用例的粒度的问题
2007-6-26 21:49:09 jun_zhang： 今天我们自已的讨论的时候发现这个问题，因为用例肯定为某个涉众提供一个价值
2007-6-26 21:49:42 jun_zhang： 所以看上去整个系统只那么一两个用例了
2007-6-26 21:50:14 潘： 具体举例？
2007-6-26 21:52:04 jun_zhang： 比如您看到的用例图中我可以只要上面的三个查看分析数据就好了
2007-6-26 21:52:31 潘： 看涉众的想法
2007-6-26 21:52:51 jun_zhang： 涉众应该不包括系统的开发人员吧
2007-6-26 21:53:25 潘： 你这里有几个岗位，不同岗位的人关心的东西不一样，不可混为一谈
2007-6-26 21:53:42 潘： 开发人员也是涉众，只不过排位很低
2007-6-26 21:53:55 潘： 开发公司老板排位高一些
2007-6-26 21:54:17 jun_zhang： 哦，那既然这样，下面的的报表相关的还是要的
2007-6-26 21:54:33 潘： 开发人员肯定是想少干活多拿钱的，但行吗
2007-6-26 21:55:17 jun_zhang： 你说对了，下面的那些报表的用例就是想少干活，但不少拿钱
2007-6-26 21:56:07 jun_zhang： 因为做了报表功能，那么用户需要的分析数据就可以很轻松搞定了
2007-6-26 21:56:19 jun_zhang： 对于开发人员来说
2007-6-26 21:57:06 潘： 看老板怎么想
2007-6-26 21:58:06 jun_zhang： 投资建设这个系统的老板是不关心你开发人员是怎样让他看到分析数据的
2007-6-26 21:58:25 jun_zhang： 他关心的只是结果，就是看到了他要的数据
2007-6-26 21:59:51 jun_zhang： 还有一个问题，今天一个同事说用例可以进行分解，也就是说一个用例可以分解为很多子用例，这么说对吗
2007-6-26 22:00:23 潘： 基本上都不对。子用例不是分解出来的
2007-6-26 22:01:59 jun_zhang： 我也这么觉得，但有时候用例很复杂，路径会不会写得很长啊
2007-6-26 22:02:14 jun_zhang： 而且扩展路径太复杂
2007-6-26 22:02:56 jun_zhang： 哦，还有，用例的复杂步骤可以写成另外一个用例吗
2007-6-26 22:03:06 潘： 该有多长就多长，一般也不会太长，写得太长的一般都是把设计混进来了
2007-6-26 22:03:10 潘： 不能
2007-6-26 22:03:24 潘： 什么叫复杂步骤，步骤就是步骤
2007-6-26 22:04:20 jun_zhang： 还有，您说开发人员也是涉众，那是不是开发人员也可以作为系统用例的执行者啊
2007-6-26 22:07:45 潘： 嗯？
2007-6-26 22:10:03 jun_zhang： 就是说开发人员作系统系统用例的执行者啊，比如开发人员--》定制主题
2007-6-26 22:10:17 jun_zhang： 在用例图中增加这个
2007-6-26 22:10:22 jun_zhang： 可以吗
2007-6-26 22:13:18 潘： 你是说在投入使用后也是由开发人员定制主题？
2007-6-26 22:14:23 jun_zhang： 我明白了
2007-6-26 22:15:15 jun_zhang： 还有一个问题，您前面说：这个不是涉众关心的，也许设计人员认为查看线损、查看电量用的模块都差不多，只是执行的SQL 语句不同，但涉众不关心这些。去掉自由报表这种东西
2007-6-26 22:15:50 jun_zhang： 虽然用户不关心自由报表这个东西，但这是涉众"开发人员"的利益啊，需要去掉吗
2007-6-26 22:16:58 潘： 如果开发人员的排位高，它就是需求。但估计不高，高的是开发公司老板。看你们老板怎么想
2007-6-26 22:17:26 jun_zhang： 是的，排位最低
2007-6-26 22:18:31 jun_zhang： 是不是老板接受用自由报表的方式给来让他看到需要数据，那么就可以不去掉了
2007-6-26 22:19:23 潘： 看你们老板支持不支持你们这种方式
2007-6-26 22:20:50 jun_zhang： 如果支持就可以这样写了吧
2007-6-26 22:21:03 潘： 估计是了。因为你们省时间没准还可以去做别的项目给他挣钱呢
2007-6-26 22:24:54 jun_zhang： 再次谢谢您，我明天还会把我的分析类图发到您的邮箱，您抽空帮我看下
2007-8-6 11:04:28 jun_zhang： 我上次不是跟您说，我们刚刚开发使用面向对象分析设计方法做
2007-8-6 11:05:37 jun_zhang： 还有，上次我问您说用例的步骤是否可以分解为子用例的问题
2007-8-6 11:06:11 jun_zhang： 我现在也还是搞不清楚，是否可以
2007-8-6 11:09:43 jun_zhang 发送 需求片断.doc
2007-8-6 11:10:16 jun_zhang： 比如这是我们综合分析系统需求说明书中的两个用例
2007-8-6 11:10:23 jun_zhang： 您看看是否可以这样
2007-8-6 11:13:35 潘： 我看了一下，基本可以，就是没有涉众利益。"构造SQL"单独对开发人员是否构成价值。
2007-8-6 11:14:13 潘： 如果好多个用例会用到"构造SQL"的步骤集合，可以把它作为子用例
2007-8-6 11:15:07 jun_zhang： 是这样的，在其它用例中还是会有引用"构造SQL"的
2007-8-6 11:15:37 jun_zhang： 子用例的识别有哪些方法或者说标志呢
2007-8-6 11:17:38 jun_zhang： 我想"构造SQL"如果离开报表对开发人员应该是没有价值
2007-8-6 11:17:55 潘： 有多个用例复用的步骤集合，而且单独构成一个小目标
2007-8-6 11:18:32 jun_zhang： 小目标不是很理解
2007-8-6 11:19:29 潘： 就是能起出个名字呗，象构造SQL
2007-8-6 11:20:05 潘： 如果没有"多个用例有相同步骤集合"，那就不要分子用例 |