What is User Scenario

What is User Scenario
场景是用来描述帮助用户解决问题的过程，即系统未来预期的使用过程。

它就像一个剧本，描述用户使用系统的过程。

场景可以看作是用户需求的内容，完全站在用户的视角来描述用户与系统的交互。

之后的功能需求说明，则是用户需求分解的结果，定义了开发人员必须实现的软件功能。

场景描述也是需要经过迭代细化的。

用户场景应当包含以下几个关键要素：
∙目的
∙期望
∙动机
∙行为
∙回应
User Scenario既不是假设也不是预测，而是试图反映或描述在其中一个应用或服务，是如何被用户在日常活动中使用的。

User Scenario以最少的技术细节，使得All Team Members（PM, DEV, TESTER, UX Designer），能有共同的例子，可以集中精力进行讨论。

场景编写技巧
如何抽取场景
首先，需要站在典型用户的角度，从问题出发，列出用户都有哪些问题，需要做什么，有哪些活动？在列出这些活动时，先不要考虑细节。

然后将这些活动按照重要性和常用程度排个序，将最重要的那些活动作为典型场景抽取出来。

并根据开发周期剔除那些这个版本不支持的活动。

场景抽取的过程是也是一个迭代过程，由粗到细，先分类抽取典型的场景，再一个一个细化场景描述
如何描述一个场景
∙以故事叙述的方式描述如何帮助用户解决问题，最好辅以交互草图（也可以将讨论过程中确定的草图拍成照片附在场景描述中）
∙需要有清晰、明确的上下文环境，说明这个场景发生在什么背景下，何时会发生
∙需要从用户的角度出发，描述用户做什么，与系统的交互行为，以及用户对出现问题的反应
∙不需要描述具体的界面是怎样的，场景的目的是让所有人员明白用户的目标是什么，以及用户希望怎样做
∙不涉及实现和技术的内容
∙内部的API不应该在场景中描述
场景的粒度如何把握
用户问题的大小决定了场景的粒度大小，并没有一个标准来定义场景的粒度。

场景应该具有高内聚低耦合的特征，一个场景内部各个环节的逻辑关系可以比较紧密，而各个场景之间应该是低耦合的。

不需要把所有可能的场景都罗列出来，只需要描述主要的、典型的场景。

一个例子：设计一个创建贺卡的网站。

对比两个不同视角的结果。

站在程序员的角度可能会为这个例子列出以下活动：
1.为卡片添加文本信息
2.为卡片添加图片
3.从卡片库中获取草图
4.发送卡片： 1) 通过email发送 2) 打印卡片
站在用户的角度则会列出以下活动：
1.发送生日贺卡
2.发送周年纪念卡
3.发送聚会请帖
4.从一张空白卡片开始制作贺卡
可以看出来，从程序员的角度列出的活动，系统大致按下述方式运行：开始是一张空白卡片，菜单功能提供：添加文本、图片，从库中加载卡，以及发送卡片。

这样，用户必须坐下来从一张空白卡片开始，弄明白所有的可用的功能，并通过这一堆功能创建一张自己需要的卡片。

而从用户的角度出发，软件就变得简单了，他们可以很轻松地完成自己所需要的卡片。

场景则是针对每一个活动再细化描述活动执行的过程。

如何抽取特性
特性（即Feature）是根据场景描述抽取的。

要将场景逐一模拟一遍，并通过头脑风暴的方式提出问题，讨论并给出解决方案，在此过程中，也是逐步明确特性的过程。

在此过程中需要注意几点：
1.讨论场景时一定不要匆匆忙忙的，需要有充分的时间，仔细地模拟场景过
程
2.尽可能多地提出问题，并从设计的角度讨论确定方案
3.要有市场、需求、架构、开发、测试等人员共同参与，最终需要达成共识。

如何取舍特性定义Scenario优先级
∙P1：首先从用户的角度出发，抽出那些支撑场景必须的功能和非功能性要求，标定为P1级的，这些是产品必须提供的特性。

∙P2：然后考虑开发周期、资源投入和开发难度，以及对用户的影响，确定剩下的哪些功能是需要提供的，标定为P2级的。

∙P3：从中剔除那些不做的功能，放到“非目标”中。

剩下有分歧，模棱两可的功能，可以标定为P3级，在有时间和资源的情况下才会考虑实现。

特性的优先级划分定义Features的优先级
∙P1--must have:属于产品必须具备的特性，没有此特性无法完成一个业务场景的；
∙P2--nice to have:属于产品的扩展特性，有了这些特性让产品更好用，但是没有此特性，用户也可以通过其他方式完成业务；
∙P3--may not have:属于产品的可选特性，在非典型场景下可能才会用到，锦上添花型。