1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
用户故事来描述产品需求是敏捷开发实践必须学习和转变的第一项工作，最经典的三段论，“作为一个…(角色)，可以<能够>…(功能)，以便…(客户价值)，这个语法很好地表明了需求的三个最重要的要素：角色，功能，客户价值。
为什么需要角色，
1. 有利于特定的用户核实，有一个“角色“字段，都令沟通工作可以与适当的角色进行，完成的产品自然也就令这些角色的人员满意。
2. 有利于开发人员理解场景，角色与“普通用户/管理员/执行人“这些区别，可以使开发人员更容易理解产品的用户，风格、操作人员的熟练程度、操作习惯。
功能描述最好遵从以下两条规则
1. 主语-谓语原则
比如，作为一个会议系统管理员，可以显示所有用户的提问，以便。。。。
是不是别扭，对可以转换成“可以查看所有用户的提问“，这样是通过角色+谓语的方式来描述
2. 动宾词组原则
在功能动作描述的时候，尽量采用动词+宾语的描述，如新建用户，查看所有评论等。
所以对于功能的描述应该是： 把角色作为主语，功能主题的描述采用动宾结构。
用户价值
用户价值看似很简单，但是其实是很难写，而且很重要。
如：作为会议管理员，可以查看所有用户的提问，以便了解哪些用户发表的评论。看上去这种价值描述不错。但是如果系统只是为了查看的话，会议管理员为什么要查看?如果评论很多，他如何查看?
所以用户故事的价值描述，给需求分析做了一些价值挖掘的要求，团队要去挖掘角色做这一动作的价值，要为角色挖掘出必要且合理的理由。
用户故事作为需求分析和研发的依据，是在敏捷开发实践过程中首先需要去实践的一个重要环节，看似简单的用户故事，在实际操作中是相对困难的，如何从传统的功能描述转变成客户和研发团队都能理解的用户，这里有很多技巧。包括如何确定角色，用户故事颗粒度，用户故事的评估等问题。
推荐大家一本书科恩(美)的《用户故事与敏捷方法》。