所在位置:答疑 - 内容   
正在开发的系统涉及一段货款管理员跟踪货款的业务
 

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

> 我们现在的做法是需求人员和涉众交流的时候画一些图来帮助沟通,但这些图是不会保留下来的,这些图能叫做原型吗?
----是,准确地说,这些图是"水平、静态、低保真、废弃型"的 原型,每个形容词都可以取反。
> 需求人员把需求向开发人员表达以后,开发人员会给出一个大体的解决方案,然后做一个类似实际界面的图形和一些模拟交互,然后再跟涉众交流,然后修改,最后做出来 的系统界面是几乎和它一样的,这个东西是原型吗?我觉得我们这个时候好像已经在问涉众 "这个方案可不可以"了。
---是的。
---还是我们课上说的:涉众没有责任、没有资格提供需求;和涉众交流的内容应该聚焦于涉众利益,交流的形式采用需求的视图