用户故事自最早1998年诞生以来，由于其突出的优点，到现在得到了广泛的应用。一般而言，用户故事里面的用户是人类用户，用户故事在表达人类用户与系统的交互方面已经证明了其有效性。

那么当处理系统之间交互时，我们能不能参照用户故事来说明系统交互的需求？让系统来讲讲故事？
这样的故事不妨称之为系统故事。
微博上有朋友形象的说这是瓦力和伊娃之间的故事。

在另外一篇文章中已经分析了用户故事的新扩展，见此链接，答案是肯定的。本文具体来说明系统故事。

下面是按照故事经典句型给出的2个例子。
* 作为ATM系统，我要发送客户卡号给银行中央系统，这样可以获得客户的余额。
* 作为ATM系统，我要把客户取款成功的信息送给银行中央系统，这样可以记账

什么情况下需要识别系统故事？

最典型的情况是两个系统分属不同部门或者团队在开发维护。采用故事的表达方式有利于跨部门或者团队来快速沟通。

另外的情况是不同组件（或者叫子系统）之间的交互。利用系统故事来更清晰的说明，某种程度而言，这算属于设计的范畴。当然，这是为了让编程者更快的工作，属于什么范畴并不重要。

谁来识别系统故事？

对于用户故事，一般是PO或者PO的助手来识别用户故事。而对于系统故事，也是相同道理，对于担当中间系统的PO来说，可以假设PO是知道系统之间业务意义上的交互的，了解系统交互是应当的。当然了解系统交互的其他工程师同样可以担当系统故事的识别。而如果系统多数交互是与人类用户交互，而只有少数是与后台系统交互，那么PO可能并不了解与后台的交互，那么应当有其他了解后台交互的工程师来协助。

如何识别系统故事？

从系统交互中识别系统故事，提议将有业务意义的最少交互可以识别为一个系统故事。
比如：
* 两个系统的时钟同步只是技术意义上的交互，不是系统故事
* 但凡传递业务信息，那么属于系统故事，比如ATM机向银行中央系统提交银行卡卡号和密码来签权

在这么多表示系统交互的图形中，推荐使用泳道图来绘制交互，在穿越泳道的地方来识别系统故事。

试图利用Wiki的表格来绘制泳道图，由于无法绘制箭头，活动顺序是在表格中从左到右，再从上到下。
分析对象是ATM机，大场景是取款。

储户	ATM	银行中央系统	银联系统
插卡登录	登录储户卡	校验用户身份，如果非本行用户，提交银联校验	校验用户身份
	显示登录成功欢迎页
取款	核对储户余额	[[查询用户余额]]，如果非本行用户，提交银联校验	用户余额
	吐钱
获得现钞	校验取款结果	记账，非本行用户，提交银联记账	记账

银联系统放在上表中只为扩充理解。

系统故事有哪些好处？

以故事形态进入的Backlog，与其它形态故事放在一起，可视化效果好
容易让编程者理解，方便配套验收条件和自动化测试
以故事的方式来进行接口设计，帮助进行架构演进

系统故事识别的优先级？

如果能够识别覆盖系统故事的用户故事，并且该用户故事也方便进入迭代处理，那么优先识别用户故事，不必识别系统故事。
虽然站在编程者角度的赋能故事（enabler story）也能表达系统故事的内容，但是系统故事的识别优先级高于赋能故事，因为系统故事对比赋能故事有更好的表现力，系统故事本身着眼于描述系统行为。
在用户故事、系统故事和赋能故事中，赋能故事的识别优先级最低，因为赋能故事描述的是赋能者（包括编程者、测试者）的行为，灵活多变，并不是描述系统的行为。

而一旦识别了系统故事，那么实现系统故事的编程者行为就不必再识别为赋能故事。

这与用户故事是一样的道理，没有必要把实现用户故事的行为作为赋能故事另外再识别出来。

如何描述系统故事？

如同用户故事一样，采用讲故事的方式来描述系统故事。如下推荐一种参考自用例规约的写法。
首先给系统故事起标题，由于考虑到直观显示到看板，因此要尽量缩短标题，又能保持意思。
其次概述这个故事，推荐采用故事描述经典句型：作为XX角色，我要做XXXXX，这样可以XXXXXX
故事主体采用情景描述方法，先描述成功情景，也有基本流、主成功场景等另外的说法，再补充描述异常/失败情景，也有异常流、扩展场景等另外的说法。
最后说明验收条件，设定类内容可以写在验收条件里面。由于以上的情景描述本身就是验收要点，因此有时候验收条件可以不用写。比如如下例子中的条件如果已经写在了总体验收条件中，那么没有必要在故事内再重复说明。

如果有必要可以添加其它说明。

如下是示例：

标题：ATM查询客户人民币余额
概述：作为ATM系统，我要发送客户卡号给银行中央系统，这样可以获得客户的人民币余额。
成功情景：
1. ATM发送客户卡号到银行中央系统
2. 银行中央系统返回该卡的人民币余额

异常情景：
* 2a 无法链接到银行中央系统
* 2b 该卡不在可处理范围之内
* 2c 该卡已经被冻结
* 2d 该卡余额超出可处理范围

验收条件：
1. 响应时间小于10秒
2. 银行卡可处理范围是中国银联支持的银行卡
3. ATM可处理余额最大范围是99999999元

为系统故事添加测试

根据系统故事的描述，配套编写相应的自动化测试。成功情景与异常情景几乎与测试用例等价类划分直接对应，从中设计测试用例相对容易。

小结

采用讲故事的方式来说明系统之间交互是完全可行的，而且容易让编程者理解，而且也能更好的关联到需求和业务。

系统故事 --- 让系统讲故事相关推荐

删除表格数据后自动刷新_Calliope: 表格数据的自动故事生成系统
视觉数据故事以叙事可视化的形式呈现,如海报或数据视频,通常用于面向数据的故事讲述中,以促进对故事内容的理解和记忆.虽然有用,但技术障碍(如数据分析.可视化和脚本)使可视化数据故事的生成变得困难.现有的 ...
浅谈WMS系统(SAP WMS系统及非SAP的WMS系统）
随着国内信息化.数字化的普及,WMS系统的实施越来越成为一个常规的操作.本文对此做简要的说明,具体包括如下内容全球范围的WMS系统厂商中国市场的WMS系统厂商 SAP提供的WMS 系统产品 SAP ...
serch安装2012 windows_随身携带电脑系统 U盘系统工具WinToGo系统安装到U盘
大家好,分享君今天分享的软件名为WinToGo,这是一款制作U盘系统的小工具.可以将你喜欢的计算机系统直接安装到U盘,也可以将系统安装到其他存储设备.不仅节省了计算机存储空间,随身携带U盘,无论你在哪 ...
系统技术方案系统构架_构架系统时应注意的事项
系统技术方案系统构架 by Ayelet Sachto 通过Ayelet Sachto 架构系统时要记住的6件事 (6 Things to keep in mind when architectin ...
鸿蒙系统比比安卓系统好么,鸿蒙系统与安卓系统的区别鸿蒙系统与安卓系统哪个更好...
鸿蒙系统2.0即将要上线了,这个系统是由华为团队自发研究的,这个也是国产的操作系统,虽然在开发操作系统时面临了重重困难,但是华为从不退缩,坚持到底,国内人还是很期待它的到来,今年的12月份就可以与大家 ...
基于suse linux系统的cacti系统部署——rpm包方式
豆丁 http://www.docin.com/p-191889788.html rpm包方式:啊扬--沙迳:2010-12-1:更改:2011/5/16:一.Cacti的简介(来源:网络):Cact ...
SAP 对HU做转库操作，系统报错 - 系统状态HUAS是活动的 - 分析
SAP 对HU做转库操作,系统报错 - 系统状态HUAS是活动的 - 分析近日收到业务团队报的问题,说是对某个HU做转库时候,系统报错.如下图示: HU里有是三个序列号, 1191111034011 ...
树莓派进阶之路 (002) - 系统烧录及系统使用(多平台)
windows操作系统树莓派(Raspberry pi)是一块集成度极高的ARM开发板,不仅包含了HDMI,RCA,CSI,HDMI,GPIO等端口,还支持蓝牙以及无线通信.由于 Raspberry ...
[Linux学习]虚拟机系统与实际系统共享文件的方式
对于虚拟机系统与实际系统之间的文件共享,有很多种方式,这里只是列举其中几种比较简单的: 1. VMware自带的hgfs共享.在Vmware里对系统进行简单设置即可,不过这需要安装VMware too ...

系统故事 --- 让系统讲故事