2006-10-27 9:48:42 春华： 业务建模好像没有几个执行者，业务好像很简单，我们的产品有的类似GOOGLE,
用户端很简单，而复杂的是技术方案
2006-10-27 9:52:15 春华： 比如说，我们客户端端对于用户仅仅就是点击一个网络节目的链接，其他他都没有感觉的，然后就是他就等着节目播放就可以了。而实践上，系统需要进行节目资源的搜索，建立对等通信，合并不同共享数据，最后播放。
2006-10-27 10:04:05 潘： 首先说业务建模，是为了理出需求。你需要对"使用你的这个东西的人群"进行建模，看他们没有你这个东西的时候，要想达到类似效果，他们是怎么做的，用序列图或活动图表达出来
2006-10-27 10:04:42 潘： 例如：他为什么要使用你的系统"点击一个网络节目的链接"，他想达到什么目的
2006-10-27 10:05:51 潘： "进行节目资源的搜索，建立对等通信，合并不同共享数据，最后播放"这对涉众是无意义的。涉众只需要又快又好
2006-10-27 10:09:34 春华： 对。所以，我就不好把我这个度。因为在项目组中，更关系技术上如何达到又快又好
2006-10-27 10:11:23 潘： 如果项目组能在涉众排行榜中靠前，这可能也是需求，但即使是需求也是设计约束，不能写在用例正文中和功能需求混在一起
2006-10-27 10:12:07 潘： 你可以在"系统播放×××"后面加设计约束"采用××P2p 协议"之类
2006-10-27 10:13:10 春华： 我就感觉用例写出来后很多技术涉及的东西好像无法覆盖，因此很难过渡的设计
2006-10-27 10:13:48 潘： 另外，要挖掘"对等通信"之类背后的涉众利益，为什么要"对等通信"？对涉众有什么好处，他在意什么
2006-10-27 10:14:17 春华： 这两天我写了一些，你能帮我指出一些问题吗？
2006-10-27 10:15:17 潘： 用例描述了需求，指出了涉众对这个系统的需要。－－这是出题。如何实现这种需要，有很多中技术方案，不能把这个交给用例－－出题人和做题人能是一个人吗
2006-10-27 10:16:59 春华： 哦。我因为是项目经理，过去大半年一直感到无法控制项目进展，我觉得是需求上没有做好，所以我想利用用例来提高
2006-10-27 10:17:25 春华 发送 用例描述.doc
2006-10-27 10:18:01 春华： 那么，出完题后，如何使得它能够转换到设计呢、
2006-10-27 10:18:27 潘： 按照我们课上的来
2006-10-27 10:18:52 春华： 我也是按照可上的来
2006-10-27 10:19:18 春华： 但是进展到用例的地方就感觉写不出来了
2006-10-27 10:20:27 潘： 用户――――>点播节目 1． 登陆网站发布系统页面 2． 节目信息浏览 3． 选择点播的节目，点击节目链接 4． 认证用户是否合法 5． 将节目数据传送给网民的客户端程序 6． 播放节目，包括
播出，快进，快退，停止
2006-10-27 10:20:50 潘： 就拿这个来说，你就捕获了这点需求，当然不够
2006-10-27 10:21:20 春华： 提供一些理由
2006-10-27 10:21:23 潘： 但是需要添加的绝对不是"建立对等通信，合并不同共享数据，最后播放"
2006-10-27 10:21:47 潘： 前置后置条件
2006-10-27 10:21:50 春华： 那应该是什么、
2006-10-27 10:22:00 潘： 路径步骤－－动作、验证、改变、回应
2006-10-27 10:22:14 潘： 都没有按照我们课上讲的要点写
2006-10-27 10:22:32 潘： 字段列表呢？节目有什么信息？
2006-10-27 10:22:33 春华： 这些我没有写，我想先在大的层面去关注一下。
2006-10-27 10:22:48 潘： 认证合法性规则？
2006-10-27 10:23:09 潘： 播放节目，包括播出，快进，快退，停止－－这些又都是另外的路径甚至是用例
2006-10-27 10:23:45 潘： 最重要的，决定你的技术方案的"非功能需求"，你根本提都没提
2006-10-27 10:24:08 潘： 可靠性、性能（速度、并发容量）、可支持性、可用性
2006-10-27 10:24:18 春华： 哦。我再写处理吧。不过我们已经写过需求分析文档，我想把他重新表达一下。
2006-10-27 10:24:47 潘： 你为什么要p2p，为什么要合并,不就是性能问题或者并发问题或者可靠性问题吗
2006-10-27 10:25:43 潘： 只要又快又好，24 小时稳定，涉众才不管你用什么技术放节目呢
2006-10-27 10:25:47 春华： 主要是考虑提高用户下载的速度，降低运营商的带宽，同时支持更多用户
2006-10-27 10:26:19 潘： 提高用户下载的速度－－提高到什么地步？度量指标？
2006-10-27 10:26:33 潘： 降低运营商的带宽－－降低到什么地步？度量指标？
2006-10-27 10:26:44 潘： 同时支持更多用户－－支持多少？度量指标？
2006-10-27 10:27:05 春华： 对。你说的对，我们这个项目是公司一个新方向，一开始就更关心技术，我感觉问题非常大
2006-10-27 10:27:37 潘： 技术是要专门关心的，但需要有人（例如你）来想这些问题。
2006-10-27 10:28:08 春华： 我再发一份文档给您，您帮忙看看，提一下建议。
2006-10-27 10:28:15 春华 发送 网络媒体加速1.0--软件需求规格说明书(带优先级）.doc
2006-10-27 10:28:47 潘： 好，我收后晚上看了再给意见
2006-10-31 11:22:57 春华： 潘老师，我针对上次你提出的问题有修改了用例描述。你帮我看看，有什么需要改进的？
2006-10-31 11:23:10 潘： 好
2006-10-31 11:23:17 春华 发送 用例描述2.doc
2006-10-31 11:24:12 春华： 有一个问题，系统内部的实现是否属于用例描述的范围？
2006-10-31 11:25:10 潘： 不属于
2006-10-31 11:25:36 潘： 用例无非就是描述需求，需求指：功能、性能、设计约束
2006-10-31 11:25:48 春华： 那么用例到底能帮助设计什么？
2006-10-31 11:25:52 潘： 也就是外观：快、好、壮
2006-10-31 11:26:01 春华： 就是提出设计约束？
2006-10-31 11:26:06 潘： 用例不能帮助设计什么
2006-10-31 11:26:33 春华： 但是这些很难帮助开发组来提出开发的方案
2006-10-31 11:26:33 潘： 只能帮助你知道到底到设计什么
2006-10-31 11:26:49 潘： 但是这些很难帮助开发组来提出开发的方案－－怎么会？
2006-10-31 11:27:39 潘： 我知道你想说的问题，例如内部的一些p2p 算法等等是吧
2006-10-31 11:27:52 春华： 我们目前带领的项目组，我个人感觉在开发控制上很难把握，所以我想借助用例和UML
2006-10-31 11:28:02 春华： 对
2006-10-31 11:28:07 潘： UML 和用例不是一个概念
2006-10-31 11:28:26 潘： 用例关心"需求"，UML 包括需求和设计
2006-10-31 11:28:50 潘： 设计时你可以关心你的算法，但不要把这个和需求混在一起
2006-10-31 11:28:54 春华： 那么如果从需求到设计呢、
2006-10-31 11:29:08 潘： 需求和设计分不清，是项目里最大的危害
2006-10-31 11:29:27 潘： 其他分不清都还在其次
2006-10-31 11:29:47 春华： 你在课上不是画类图，序列图来发现责任和分配这些责任吗？
2006-10-31 11:29:56 潘： 那么如果从需求到设计呢－－还是得看幻灯
2006-10-31 11:30:16 潘： 另外，"技术难点"和需求不是一回事
2006-10-31 11:30:48 潘： 也许对你的开发人员来说，以前没有接触过p2p 开发，他觉得这是重要的难点
2006-10-31 11:31:07 春华： 对
2006-10-31 11:31:22 春华： 他们往往更重视技术上的东西
2006-10-31 11:31:42 春华： 而我很难对他们的工作进行估计和评价
2006-10-31 11:31:52 春华： 我希望能找到一个方法
2006-10-31 11:31:53 潘： 但涉众并不关心这个，你需要回答：为什么现在这么多视频网站，你还要再搞一个，为什么开源的p2p 也有，为什么不照搬之类。
2006-10-31 11:32:25 潘： 这才是你的系统和别的系统的不同点，跟开发人员拥有的技能无关
2006-10-31 11:33:20 潘： 试想一下，不说P2p，就说数据库开发，如果换一批新人上来，连基本的SQL都不掌握，是不是需求文档里也要写好SQL 语句给他们？
2006-10-31 11:33:29 春华： 这是我们立项的时候曾经思考的问题，不过我们领导主要是希望我们能开辟一个新的应用，提供点播和直播的产品方案，因为P2P 现在很热门
2006-10-31 11:34:00 春华： 把这个项目也列为探索性的项目
2006-10-31 11:34:05 潘： 如何根据功能、性能、现实条件来得到解决方案，是设计人员应该具备的技能（不够就去补），跟产品本身需求无关
2006-10-31 11:34:39 春华： 需求是我们自己提出来了，目前没有客户
2006-10-31 11:35:28 潘： 客户当然有啊，就是领导啊，要去揣摩领导的意思。否则，照搬一个一样的不就行了？
2006-10-31 11:35:37 春华： 现在的问题是我们的需求分析人员提出需求后，设计根本就不太理会，他有他自己的想法，他关心技术和算法
2006-10-31 11:35:56 潘： 就算是照搬，也有好几个样板，到底哪一个更好，还是看领导
2006-10-31 11:36:46 春华： 关键我们领导并没有太多指示，全凭我们开发自己做，他就看结果
2006-10-31 11:37:05 潘： 他关心技术和算法－－应为：他喜欢学习技术和算法（因为他可能之前不会）
2006-10-31 11:37:56 春华： 我作为项目经理，感觉很难控制整个开发的进度和方向
2006-10-31 11:39:07 春华： 技术总在改变，而我现在需要找到一总能够为设计所接受的需求表达方式
2006-10-31 11:39:09 潘： 我看了一眼，觉得有不少改进，我晚上细看了再回复！
2006-10-31 11:39:25 春华： 好，谢谢潘老师
2006-10-31 11:40:57 潘： 为设计所接受的需求表达方式－－这句话有问题。需求就是说人话，没有多少种表达方式。用例只是一种组织方式，就算你不用用例，功能需求、非功能需求设计约束还是跑不掉，不该是需求的就不是需求。
2006-10-31 11:42:33 潘： 现在情况下，不需要改善团队一定要用用例来写，只要有人（例如你）清楚需要达到什么功能性能，不断一遍一遍告诉他们就行
2006-10-31 11:42:44 春华： 因为之前，我们一个系统分析员写了一个多月的需求，也和设计架构师有一些冲突，到现在设计架构师自己走一套，需求放一边
2006-10-31 11:43:27 潘： 需求放一边－－可能需求写的太多了，写成了设计，设计架构师当然有权利否定它
2006-10-31 11:43:48 春华： 是的
2006-10-31 11:44:01 春华： 需求确实涉及到了设计
2006-10-31 11:44:52 春华： 所以我想帮我们系统分析员重新用用例来组织需求
2006-10-31 11:45:15 春华： 也希望采用UML 来画一些分析和设计图
2006-10-31 11:45:25 潘： 其实用例也未必帮得了
2006-10-31 11:45:54 春华： 这更多是项目管理方面的问题
2006-10-31 11:45:55 潘： 我的建议是：把愿景和涉众利益搞清楚，写出来，告诉大家就行了
2006-10-31 11:46:11 潘： 需求规范不规范无所谓
2006-10-31 11:46:32 潘： 因为本来就是一个探索
2006-10-31 11:46:33 春华： 这个之前也多次沟通过，应该大家比较清楚
2006-10-31 11:47:38 春华： 可是探索也有成功和不成功的分别呀，我希望它至少不属于不成功的
2006-10-31 11:48:07 潘： 所以要用这个来评价工作 |