evegao 2019-6-24 12:15
字段列表的定义和是什么？什么类型的字段应该列入到字段列表里呢？
例如 微信app 内有很多应用，例如红包，转账面对面。微信支付用户-发起转账。发起者的微信号 是不用列入到字段列表里面的吗？ 那个 这个用户身份如何描述呢
UMLChina潘加宇:
如实描述即可。在某一次交互中，外系统需要告诉系统什么，系统需要记住什么，系统需要告诉外系统什么
jeri:
1.助理请求开始创建公开课
按现有的写法是，这个请求需要给umlchina业务系统提交什么字段?
1.用户标识 长度:11位, 类型：数字+字母
evegao的疑问是类似为何umlchina业务系统不需要知道用户身份，是谁都可以创建？
UMLChina潘加宇:
如实描述即可，摄像机应该拍到啥就是啥。 UMLChina系统不需要验证身份，小偷捡到我们的电脑也可以用。 微信支付也是一样的，摄像机可能拍到需要输密码，其他应该不用输入的。
jeri:
人肉系统是输入了密码，但是微信支付系统需要知道哪个用户，不然不知道是哪个用户转账-----上面提问的是指这个问题
UMLChina潘加宇:
对。这就是你们几位思想上的糊涂点。仔细再想想。 这个地方糊涂的话，估计一大片用例规约都需要改了。
没拍到人肉系统提交用户名，但照样可以转账，是怎么回事呢？想想不就知道了嘛。
就像那个笑话一样，普通的雨伞对准狮子，结果啪的一下，狮子胸口炸出弹孔，莫非雨伞里有子弹？
UMLChina潘加宇:
我针对之前的问题再详细回答一下：
jiwei 2019-3-11 17:15
潘老师，字段列表应该写那些内容这个怎么判断？是写执行者输入的，还是说要把系统为了体验让一些内容系统自动提交的字段也要写。
例如：付款的时候需要用户输入支付密码，并且要让用户选择是银行卡还是付款还是零钱，那字段列表是只需要写支付密码，还是说支付密码、零钱、用户的微信号这三个都需要
UMLChina潘加宇:
先去掉"自动"这种不严谨的用语。
这也是很多人普遍存在的问题，没事找事。
第一句都已经说清楚了:
付款的时候需要用户输入支付密码（信息1），并且要让用户选择是银行卡还是付款还是零钱（信息2）。
事实已经说得明明白白了吧，下面又来了一句：
那字段列表是只需要写支付密码，还是说支付密码、零钱、用户的微信号这三个都需要。
如果可以随意加1个，加2个可以不，加3个呢，把数据库里面所有的字段都加上去怎么样呢？
图1
如图1，左边需要输入的信息更少，比右边更好用。那为什么我们的需求人员会自残，硬要把图1左边的聪明系统写成右边的笨系统呢？
原因可能是：
（1）需求人员不相信系统那么聪明，怀疑自己看到的图1左侧不是真相，设想右侧才是真相。
这个需要需求人员去医院检查了。
（2）需求人员了解图1左侧是真相，但由于掺杂了设计导致混淆了"系统"的边界。
图2
如图2所示，猜想系统可能的实现是Client（也就是那个移动设备上的app了）上会保存有一个SessionID之类的东西，这个SessionID是之前登录时Server分配的。每次交互，Client需要向Server那边发送的请求里要加上这个SessionID（应该不是发送微信号）。
因为app和执行者在同一个物理位置，执行者的手指和app的界面亲密接触，会感觉这两者是一体的，而Server物理位置在远方。需求人员在思考的时候，以物理位置为依据，不知不觉把系统边界往后移了一段。由蓝色线移到绿色线。
图3
《软件方法》里面也强调了，系统边界是责任边界，不是物理边界。"系统"就是"要履行的责任的总和"，不管物理上它长得怎么样。
需求人员必须把"系统"这个"责任总和"当成一个整体来思考，不要没事找事去操心提供"责任总和"的这个"系统"内部怎么分割。
（3）需求人员知道左侧是真相，也没搞错系统边界，但害怕要是请求步骤的字段列表里不加微信号（或SessionID），用例规约里体现不出来"系统里要保存微信号（或SessionID）这个数据"，导致无法指导设计人员做设计（请复习《软件方法》第1章第1道测试题）。所以，为了体谅设计人员的难处，故意加上去。
如果用例规约里真的需要出现这个微信号（或SessionID），即使这个用例的这个请求步骤的字段列表里没有，也可能会出现在其他请求、验证、改变或回应步骤的字段列表、业务规则里，或者其他用例的用例规约里。
如果用例规约里不需要出现这个微信号（或SessionID），那应该是好事啊！说明微信号（或SessionID）不属于"不这样不行"，设计人员爱想什么办法记住当前的会话状态都可以（SessionID当然也可以）。
另外再说一句，清晰表达系统应承担的责任即可，不能保证的不要写。前面提到UMLChina那个不用输密码的例子，其实微信也差不多，例如歹徒胁迫张三告知密码，歹徒操作；张三输完密码之后就被歹徒捅了一刀死翘翘了，歹徒捡起手机完成最后的确认……系统并没有承诺外面执行者一定就是那个人，只是会尽量做一些事情来靠近。
（2）和（3）说明，一旦需求人员操心设计，就会出现各种需求怪胎。
