所在位置:答疑 - 内容   
接收报销数据(费用系统)用例规约
 

譯揮 (25***466)16:02:10
用例名 接收报销数据(费用系统)用例编号 2-7
执行者 项目系统(主)
前置条件 系统收到项目系统提出的接收报销数据的请求
后置条件 系统已保存项目报销数据并做相应处理
涉众利益
领导:担心经过审批的报销数据被篡改了
项目经理:担心补充录入的单据数据太多,担心数据重复录入
组长:担心经过审核的报销数据被篡改了
报销复核员:担心经过复核的报销数据被篡改了
基本路径
1、 系统接收项目系统发送来的报销数据
2、 系统检查数据的合法性和完整性
3、 系统计算报销单据编号
4、 系统根据项目报销数据生成并保存费用报销单据
5、 系统请求项目系统接收报销单据编码
6、 系统为报销单据生成项目经理工作待办
7、 系统请求公文系统给项目经理发送工作待办
譯揮 (25***466)16:40:34
在写涉众利益,感觉到也是要注意不要涉及到对系统处理细节的担心
/sun(20***77)17:02:41
这用例规约感觉像在写程序
潘加宇(3504847)17:04:37
前置条件 系统收到项目系统提出的接收报销数据的请求
--前置条件不是第一步,应该是这个用例要开始应该具备的一些条件,例如,系统中已存在报销费用的规则

潘加宇(3504847)17:06:15
项目经理:担心补充录入的单据数据太多,担心数据重复录入
--这个用例是两个软件系统之间的交互,录入太多这些涉众利益和这个用例不相关吧
潘加宇(3504847)17:07:08
领导:担心经过审批的报销数据被篡改了
组长:担心经过审核的报销数据被篡改了
报销复核员:担心经过复核的报销数据被篡改了
---调研得不够仔细,家里两夫妻对同一事情还有不同考虑,更何况不同岗位

/sun(20***77)17:07:22
第一步是不是应该 项目系统请求系统接收报销数据?主动语句
潘加宇(3504847)17:10:11
实在没有调研,你可以从已经写的需求倒推一下,例如:
"系统检查数据的合法性和完整性"--不检查的话,谁会有什么样的麻烦
潘加宇(3504847)17:11:12
"系统为报销单据生成项目经理工作待办"-生成错了,张冠李戴,谁会遭殃
潘加宇(3504847)17:11:43
当然,这是闭门造车的不得已之举,还是要去调研
潘加宇(3504847)17:12:12
@(20***77) 17:07:22
第一步是不是应该 项目系统请求系统接收报销数据?主动语句
--对的。项目系统请求接收**数据。

譯揮 (25***466)17:13:02
好的,还要学习一下。
潘加宇(3504847)17:13:30
另外,用例名字"接收。。。。"不合适,费用系统不是收下来存起来就完成任务了,价值不仅是接收,还有后面的处理逻辑。可以改个名

譯揮 (25***466)17:19:29
对,接收应该是一个步骤。实际工作应该是: 生成费用报销单据()
譯揮 (25***466)17:24:18
这个有点不对,项目系统请求归请求,费用系统收不到怎么办啊。还是应该以费用系统收到请求为准吧
譯揮 (25***466)17:24:53
费用系统收到请求,这是费用系统可以检测到的。
譯揮 (25***466)17:28:45
关于担心: 因为是两个系统对接,涉众担心数据传的过程发生变化。另一个,项目经理希望把费用系统需要的数据都传过来,减少重复录入啊。
潘加宇(3504847)23:04:26
项目系统请求就像"会员提交***"一样,已经和系统(实现时系统提供的接口可能是api,也可能是键盘鼠标输入)接触了
如果担心:这是一个网络系统,要是项目系统请求了,费用系统收不到怎么办?为什么会收不到呢?哦,因为网络可能会断。但是,一台计算机内部也是一个由CPU、主板、内存、外存、I/O设备……组成的"网络"。怎么不担心键盘鼠标的信号传不到内部呢?如果是这个担心,说明已经想到实现问题,已经偏离需求了。涉众要的只是系统对外提供的功能和性能,能干活,而且干活速度快,还稳定,涉众要的不是"网络",更不是现在的以太网。
扩展开来说:
还有很多情况,例如没电了,程序员编码编错了……系统都会出问题,但这些【和我们要研究的系统没有特定关系】,是其他领域的问题。
一个环节出问题,软件可能不成功,但不是所有问题都是需求问题。有的"需求规约"操心到连代码规范也放进去。需求应该关注的是涉众和市场,开发人员不会设计,不会编码就要去学,市场不会因为程序员不会编码就可怜他"需求打个折扣吧!",只会让他喝西北风。

譯揮 (25***466)23:20:34
前置条件为:项目系统请求接收**数据,这个费用系统能检测到吗?
潘加宇(3504847)23:21:09
项目系统请求接收**数据
已经是里面的步骤了

譯揮 (25***466)23:29:01
前置条件,写了以后到设计和编程时,会转化些什么?
潘加宇(3504847)23:30:14
作为某些类的状态的参考

譯揮 (25***466)23:37:55

经过上面一番讨论,原来指向费用系统的用例写错了,应该改为:生成费用报销单(),请求接收报销数据只是一个步骤。
潘加宇(3504847)23:38:35
可以

譯揮 (25***466)23:38:41
实际是项目系统请求费用系统生成费用报销单,报销数据作为参数。
譯揮 (25***466)23:39:06
这样就理清了,看想来像个需求了。
譯揮 (25***466)23:40:52
现在有一个问题:用例规约里写那么详 细的执行者与系统之 间的交互,虽然不涉及到系统的工作细节,但一般人看来可能会认为这是设计了。怎么办? 可能有人认为:需求不想做这么细,让设计去做吧。
譯揮 (25***466)23:42:04
如:
领导【登录】
1、 领导请求查看待处理报销申请
2、 系统反馈待处理报销申请
3、 领导选择报销申请
4、 系统反馈申请明细
5、 领导输入审批意见
6、 系统验证审批意见
潘加宇(3504847)23:45:19
参见软件方法6.1.3 基本路径