2006-6-23 14:34:25 钦旋: 上次是一个电子会议的项目。硬件厂商为卖设备需要一套软件.主要是会议签到使用非接触式卡,但是子系统比较多.
2006-6-23 14:37:19 潘: 子系统比较多--??
2006-6-23 14:37:42 钦旋: 比如,与会人员资料必须事先录入,在此,录入资料是否可以认为是一个用例(或者是资料管理)
2006-6-23 14:40:39 钦旋: 子系统:1,签到时需要显示人员信息的子系统.2,提供手工签到的子系统,3,提供个人,单位,会议资料录入,排座位等功能的子系统4,还有控制音频视频的子系统 等
2006-6-23 14:42:03 潘: 子系统不是这么分的。系统就是系统,这些只能叫做需求分包
2006-6-23 14:43:32 潘: 你尝试用我们课上教授的业务序列图把这个开会的过程画出来?
2006-6-23 14:49:27 钦旋: 签到的流程比较好确定,但是会议中的流程不好定,因为这部分需求不太确定.在这种情况下应该如何处理呢
2006-6-23 14:50:32 潘: 因为这部分需求不太确定--是画你这个系统没上马之前的流程,然后结合愿景,推敲出新系统的职责,这样才能严谨的得到需求
2006-6-23 14:55:33 钦旋: 如果硬件厂商自己已经有想法,而且想法和我们推敲的流程不太吻合,是否应该以硬件厂商为准?
2006-6-23 14:58:06 潘: 谁是老大以老大的想法为准
2006-9-4 10:45:45 钦旋: 有一个用例,A 通过网络向B 注册,B 返回注册成功,然后B 向A 发送一个C 的列表,
然后A 逐个向C 注册.实际上C 有多个,B 起到C 的负载均衡的作用.这几个动作是否可以看作是一个用例?
2006-9-4 10:49:33 潘: 首先你要说清楚的是:研究对象是谁--谁的用例?否则是没有意义的
2006-9-4 10:50:14 钦旋: B 和C 同属于一个系统,即我们的研究对象
2006-9-4 10:50:28 潘: 研究对象是B+C 是吗?你开发的系统就是B+C?
2006-9-4 10:51:15 钦旋: 还有其他,不过是内部的.可以认为是B+C
2006-9-4 10:52:03 潘: 那么,B+C 首先就不是需求,系统对外界来说就是一个整体。以A 的观点来看,他就是向"系统"注册,至于系统里面是B+C,还是BBBBCCCC,不管他的事,他只要注册这个功能,加上一些性能要求。BBBBCCCC 那是设计人员为了满足非功能需求所构思的一种设计方案
2006-9-4 10:55:39 钦旋: 用例是否仅用于表达原始需求?因为有时候会遇到,比如把整个系统作为研究对象,
则有一个"注册"的用例.然后我们通过分析认为需要B+多个C,当把B 作为研究对象是,需要(可以)对B 写用例吗?
2006-9-4 10:59:58 潘: 认为需要B+多个C,当把B 作为研究对象是,需要(可以)对B 写用例吗?--用例本来就是为了反映涉众心里对这个系统的想法,如果认为设计上需要B+C,而涉众又无法验证和理解这一点,那么这种"用例"是没有意义的,为什么不说白了就是设计,何必套上用例的外衣?另外,B+C 到底是不是需求,这完全是实事求是的事情。如果项目是分包多方,一定要B+C,这个时候B+C 可能是涉众不允许改变的,那么,就可以以B 作为研究对象。而在这里,B+C 并不是涉众在意的,是设计人员的构思而已
2006-9-4 11:01:12 潘: "需求"是涉众不允许改变的东西,否则就不要写在用例文档里。这个不是"你" 怎么认为的问题,而是涉众怎么认为的问题
2006-9-4 11:03:51 钦旋: 这样说我对于B 写用例本身是一个错误的概念.因为对于用户只有系统没有B
2006-9-4 11:08:12 钦旋: 我们分析后决定分成B,C 两部分,然后各由不同的人来分析设计,这个时候,他们可能只关心各自的子系统以及相关的执行者
2006-9-4 11:11:12 潘: 他们可能只关心各自的子系统以及相关的执行者--完全可以用类图、序列图、构件图解释,不需要用用例这种方式,用例图不适合表达这种东西 |