lin li
More options Feb 14, 10:25 am
老师，您好！
遇到问题，希望能够得到指点：
正在开发的系统涉及一段货款管理员跟踪货款的业务，按系统提供的价值来分析我觉得应该有这些用例：
货款管理员-->更改当前催款人
货款管理员-->记录最新进展
货款管理员-->录入已收款
货款管理员-->录入收款产生费用
货款管理员-->录入收款提成结算日期
疑问：
这些用例实现起来其实就只是一个表单的多个字段的修改，每次由货款管理员根据需要修改一个或两个字段，按以往的习惯我们都写成"货款管理员-->修改货款跟踪" 这样一个用例。现在这样需求写得好象很复杂，不知道是否是对的。
beenjoy
More options Feb 14, 10:32 am
lin li
你好！
如果每步操作和其他业务没有什么关联，而且由一个完成，可以只用一个用例"管理货款"来描述，但催款人的管理最好单独做另外一个，因为系统可能要管理其他类型的 人。
毕文杰
lin li
More options Feb 14, 6:20 pm
beenjoy,谢谢回复，不知道你说的其它业务有没有关联具体指的是什么？"催款人"是每笔货款对应一个"催款人"，跟系统要管理的其它类型的人没什么关系。
文字
More options Feb 14, 9:27 pm
用例应该以涉众的视角来考虑，要考虑"录入已收款"是否是一个业务步骤还是一个具体业务，如果是步骤不应该作为一个用例，如"毕文杰"所说，应该用"管理货款"来作为一个用例，而录入已收款可能只是一个步骤， 可以设计成类中的一个方法。
UMLChina
More options Feb 14, 10:18 pm
首先，因为"这些用例实现起来其实就只是一个表单的多个字段的修改"产生疑问，思想里已经犯了从设计找需求的错误（参见课上幻灯片"用例和数据多对多""值长－ > 查询缺陷"。。。），你想一想，如果这些事情不是一个贷款管理员做的，而是分成不同的岗位来做，例如：
岗位1-->更改当前催款人
岗位2-->记录最新进展
岗位3-->录入已收款
岗位4-->录入收款产生费用
岗位5-->录入收款提成结算日期
你还有没有"其实就只是一个表单的多个字段的修改"的想法？
或者
货款管理员-->更改当前催款人――或者，外部的某人也可以（通过web）自行修改催款人
货款管理员-->记录最新进展――或者，外部的某人也可以（通过web）汇报款项进展
。。。
你还有没有"其实就只是一个表单的多个字段的修改"的想法？
―――――――――――――――――
需求没有标准答案，只有最佳答案，所以不管最后是怎样来划分用例，只要是从"卖"的角度看问题，就是正确的。那么，要问的问题是，什么是货款管理员期望的，系统又能做到的？
"更改当前催款人"。。。等等活动不是无缘无故发生的，是业务流程中的一个小片段。货款管理员可能接了个电话，然后到系统那里去更改当前催款人，然后关电脑，干 别的去或下班了，过了几天，有个什么事，他用系统来记录最新进展 ….
也就是说，这些事情是在不同的场景，甚至可能在不同的业务流程中发生的，所以分成五个用例应该更合适，也可能更少，要揣摩货款管理员的心意，他对这个系统的用法有几种？
实际工作中，贷款管理员会怎么说"小张，等我一下，我到系统那边去___???_____"。
毕文杰和宋文鹏说的"管理货款"作为一个用例是不对的，"管理××"这样的名字尽量少用，实际工作中，贷款管理员不会这样说，"小张，等我一下，我到系统那边去管理一下货款"。"管理××"尽量只用于打扫垃圾――打扫从业务建模中映射不出来的，一些管理基本数据的功能。
我们可以扩展一下，假设组织里设了一个超级管理员，他可以按自己的意志随意修改任何数据。"超级管理员à 管理货款"也可以是用例，这个用例和"贷款管理员à更改当前催款人"等等用例是并存的。
参见附件文章"这个圈圈不简单"的保单的例子
可能的担心是，哇，要是一个表有几十个字段，每个理论上都可以单独修改，岂不是要几十个用例－－事实上，如果我们从涉众的角度揣摩，他对他所做的事情心里面是分 了三六九等的，很可能" 更改当前催款人"和"记录最新进展"就是一回事（我随便说的，具体要去揣摩他的心意）
我举个生活中的例子：要是家里着火了，我们心里面对各种事情分得很清楚我们先逃命，有可能再抢救财产AB，还有可能再抢救财产CD，其他的，随它去吧。。。。
lin li
More options Feb 15, 10:27 am
谢谢老师，好像明白一些了。对比了一下，我这边的业务应该符合您说的情况。还有一些疑问，下午有时间整理一下再上来问。
上个邮件我可能没有描述清楚业务，让毕文杰和宋文鹏误解了，补充一下：
我要调研的业务组织是合同管理部，和货款相关的业务简述如下：
合同签订以后,*合同管理员* 负责与销售员联系，收集订单履行信息所需要的信息并记录下来（其中包括货款信息，字段：合同编号、客户名称、货款类别、货款金额、要求付款日期、初始催款人（签 订合同的销售员）），之后就把这些信息的记录分发给参与订单履行的其他业务工人（货款管理员是其中一个）
*货款管理员*根据合同中的货款信息，创建该合同的货款跟踪记录（记录在一张excel 表中,每个货款一行），开始跟踪货款：
1.定期督促催款人回收货款，记录进展；
2.定期从财务部那边取得客户实际汇款信息，记录已收款项；
3.如果催款人发生变更，销售员所在部门会通知货款管理员进行变更；
4.如果催款过程中发生费用，催款人会在另一个系统（之前已经存在）中申请，领导审批通过后就可以生效，货款管理员定期从该系统中查看已生效的费用并把费用记录 到相应的收款；
5.货款管理员会在每月初筛选出上个月的收款结算提成，一般情况下一笔货款的收款日期就是它的结算日期，但有时候会有特殊情况需要提前结算提成或者延后结算，所 以如果货款管理员接到领导"某笔货款提前(或延后)结算提成"的通知,他会去修改那笔收款的结算日期，把它提前结算或放到下下个月。
lin li
More options Feb 15, 4:22 pm
是不是就算需求人员写成几个用例，开发人员也可以实现成一个表单:打开=>修改=>保存呢？
货款管理员现在是手工做账的，用excel，也是打开=>修改=>保存(只不过每次打开修改的是不同的字段)，所以她认为系统也做成这样就可以了，她能修改的全 部字段每次打开i 表单都给她开放，让她自己把握改哪些字段（改错字段的可能性很小），也给她做了原型确认过。
所以觉得写多个用例的话好像反而绕了一个弯，写那么多文档担心需求会跟不上开发的进度，开发人员也没耐心听那么多话。
另外：我开始也不知道货款管理员每次打开货款跟踪修改的是不同字段，后来分析她提出的查询需求，发现修改不同字段之前用来查询的字段是有差别的，问了好多次渐渐 越来越清楚。
UMLChina
More options Feb 15, 9:58 pm
（1）当然可以几个用例对应一个表单，或者一个用例使用好几个表单，或者根本没有表单（是命令行或者短信、语音控制）。
首先不要有一一对应的思想，如果一一对应，计算机自己就搞定了，还要人干什么。用例和类（表）不是一一对应的，用例和Form不是一一对应的。推而广之：涉众利益和需求不是一一对应的，业务用例和系统用例不是一一对应的….
开发人员爱怎么实现怎么实现，比较笨的可能每个用例搞一个Form 也行，掌握设计技巧的可能会很多个Form 从同一个base Form继承下来，或者一个界面模版通过配置生成很多个界面也行，这是开发人员的设计技能。一个需求人员去揣摩开发人员会怎么实现干什么？
买了车，在不同的时间，车主会去店里换轮胎、洗车、打蜡、加膜….人家工人都是在一个"表单"上工作嘛，人家卖服务怎么不卖"管理汽车"？
（2）"她认为系统也做成这样就可以了"、"给她做了原型确认过"不是需求的理由。我们课上说过了：需求不是问"这样行吗"，而是问"不这样行吗"？
如果涉众要求"一定要象我以前用Excel 一样"，而且这个要求又没有和其他更高级的涉众利益冲突，需求上加一个设计约束"界面应该是**
样子"是可以的。如果不是这样，那么应该理出真正的功能需求、非功能需求。将界面的具体细节交给交互设计人员来决定。
（3）说了这么多，还有最关键的问题，涉众利益，需求人员还没有提到过。难道货款管理员过去用Excel是一帆风顺的吗？出现过什么错误和混乱？有没有大量重复的体力劳动？花的时间长不长？…..在这些东西没搞清楚之前，不要去操心开发人员的问题。
涉众有奶便是娘，他只关心这个东西好不好，不关心这个系统是路上捡的，还是外星人造的，还是你们公司的开发人员做的。开发人员不了解上面的道理，要训练开发人员 ，如果开发人员是强势的，那说明公司的产品不是市场导向，而是开发人员导向的，那还认真做什么需求啊，混工资就行了，混不下去了就跑呗。
（4 ）文档多的问题。文档不会因为我们从涉众利益的角度观察而变"多"的，即使"多"，"多"出来的内容也是有价值的。现实中，需求文档"多"，
原因根本不是从涉众 角度看问题导致，而是大量设计掺杂进来的结果。要赶时间的话，一看就有共识的用例，可以不写文档嘛。即使写文档，也可以不写路径步骤，只要前置后置条件、涉众利 益和补充约束就够了。
lin li
More options Feb 17, 5:54 pm
谢谢指点。我再跟几个问题（老师辛苦啦）：
1.货款管理员并没有一定要和excel 一样，她是要求处理的时间不要超过她用excel 处理的时间就可以了，我应该怎么描述她这个要求？ 像"一分钟内可以录入 完毕"这样吗？还有她不担心全部字段都可以修改的情况下她会改错字段，需要表达出来吗？怎么表达呢。
2.界面设计完成后需要客户确认吗？有时候确认过的有很多问题的方案，要比没确认过的有少量问题的方案结局要好一些。
3.我可以把涉众利益写得很多很通俗吗？有什么注意点？比如像下面这么写是否可以：
合同管理部经理：
1）提高数据后期统计花费的精确度
2）减少数据后期统计花费的人力和时间
3）减少基础数据的重复录入，担心重复的数据不一致导致后期统计不准确，认为减少重复录入可以减少基础数据录入员的工作量
4）不打算增加工作人员，尽量不要增加基础数据录入人员的工作量
货款管理员：
1）其实不是很在意重复录入花费的少量时间
2）担心失去excel 的很多便捷的功能（比如鼠标圈上一个范围的单元格就可以统计出货款总额，随便可以筛选，复制）觉得没有这些功能才会真正的提高工作量
3）希望不要增加平时处理货款基础数据花费的时间
4）后期的数据统计不一定安排给自己。就算安排给自己，要花很多时间，老大自然会给时间的
UMLChina
More options Feb 20, 9:01 pm
> 1.货款管理员并没有一定要和excel 一样，她是要求处理的时间不要超过她用excel 处理的时间就可以了，我应该怎么描述她这个要求？像"一分钟内可以录入 完毕"这样吗？还有她不担心全部字段都可以修改的情况下她会改错字段，需要表达出来吗？怎么表达呢。
－－－设计混进需求中， 很多时候是因为开发人员没有去寻找非功能需求（问题本身），改用设计（解决方案）来代替所致。非功能需求和愿景一样，最重要的是度量。
－－"一分钟内可以录入完毕"确实是一个度量指标，不过这个度量指标还不够严谨，因人而异，系统不一定能承诺这一点。建议改为系统确实能承诺的指标：以**** 为样本，平均每笔录入，操作次数不超过***次，操作人员手腕移动距离不超过***
> 2.界面设计完成后需要客户确认吗？有时候确认过的有很多问题的方案，要比没确认过的有少量问题的方案结局要好一些。
－－不是"客户"，是"涉众"，准确地说是充当系统执行者的那些涉众。
－－和涉众交流的那个"界面设计"不是"设计"，是"界面原型"，是一种需求的视图，目的就是为了验错。而且验的不是需求，是涉众利益。
－－由程序员根据界面类的责任以及交互设计的方案，使用某种界面组件库来实现的那个东西才叫"界面"
UMLChina
More options Feb 21, 10:17 pm
> 我们现在的做法是需求人员和涉众交流的时候画一些图来帮助沟通，但这些图是不会保留下来的，这些图能叫做原型吗？
－－－－是，准确地说，这些图是"水平、静态、低保真、废弃型"的 原型，每个形容词都可以取反。
> 需求人员把需求向开发人员表达以后，开发人员会给出一个大体的解决方案，然后做一个类似实际界面的图形和一些模拟交互，然后再跟涉众交流，然后修改，最后做出来 的系统界面是几乎和它一样的，这个东西是原型吗？我觉得我们这个时候好像已经在问涉众 "这个方案可不可以"了。
－－－是的。
－－－还是我们课上说的：涉众没有责任、没有资格提供需求；和涉众交流的内容应该聚焦于涉众利益，交流的形式采用需求的视图