譯揮 (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 基本路径