如何描述模型
通用语言的建立，就是战略设计的一部分
用户故事
用户故事就是对问题的描述，用户故事提供了一种恰到好处的粒度，使得产品再需求分析阶段能够极大地节约时间，并且使得产品和研发人员始终把注意力集中在关键点，避免过早地陷入细节以及被细节所局限，同时给产品功能流出了讨论空间。
用户故事的构建一般来说有三个环节：
- 简单描述用户需求；
- 围绕简单描述进行讨论；
- 明确如何验证；
分别对应用户故事的三个元素，也就是 3C: Card、Conversation、Confirmation。
Card卡片
卡片就是对用户故事的简述（传统上人们通过便利贴在白板上构建用户故事），一个好的用户故事卡片包含三个要素：
- 谁：谁需要这个功能；
- 需要什么：想通过系统做什么事；
- 为什么：为什么需要这个功能，这个功能带来什么价值。
Conversation（谈话）
谈话指的是用户、领域专家、产品经理、研发之间围绕用户故事进行的讨论，谈话是明确需求细节的必要环节。可以用问题对谈话进行简要记录，此外，也可以基于图形或其它工具进行讨论。
Confirmation （验证）
验证代表了验收测试，描述了客户或者产品owner怎样确定用户故事已经被实现，且能够满足要求。一般可用如下模板写 Confirmation ：
假设我是 <角色> ，在 XXX 情况下，
当我 <操作>
那么 <结果>
使用用户故事收集和梳理 SmartRM 的需求
当 SmartRM 立项之后，我们开天辟地要做的第一件事，就是梳理出最顶层的用户故事。在团队中，撰写用户故事的一般是 产品经理。在 SmartRM 案例中，我们的产品经理梳理出来以下这些最主要的顶层用户故事，迈开了系统分析和建模工作的第一步，为后续工作打下了基础。
tip
所用用户故事的详细描述，都是建立通用语言的关键资料，因此，我们将其收录进 SmartRM 通用语言文档
1. 售卖机扫码支付购物
-
卡片
作为用户
我希望在售卖机上通过手机扫码支付购买商品
以便快速便捷地购物
-
谈话
详见 SmartRM 通用语言文档
-
验收标准
假设我是一名用户，货道售卖机的商品列表上有商品 A，B，C
当我在售卖机屏幕上选择了商品 A，并扫描展示的二维码完成支付后，
那么商品 A 就会从售卖机中弹出，我可以拿到商品 A。