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

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

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

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

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

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

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

谁来识别系统故事？

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

如何识别系统故事？

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

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

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

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

系统故事有哪些好处？

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

系统故事识别的优先级？

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

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

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

如何描述系统故事？

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

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

如下是示例：

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

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

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

为系统故事添加测试

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

小结

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