 1、如何抽取场景？首先，需要站在典型用户的角度，从问题出发，列出用户都有哪些问题，需要做什么，有哪些活动？在列出这些活动时，先不要考虑细节。然后将这些活动按照重要性和常用程度排个序，将最重要的那些活动作为典型场景抽取出来。并根据开发周期剔除那些这个版本不支持的活动。场景抽取的过程是也是一个迭代过程，由粗到细，先分类抽取典型的场景，再一个一个细化场景描述  2、如何描述一个场景？场景是用来描述帮助用户解决问题的过程，即系统未来预期的使用过程。它就像一个剧本，描述用户使用系统的过程。场景可以看作是用户需求的内容，完全站在用户的视角来描述用户与系统的交互。之后的功能需求说明，则是用户需求分解的结果，定义了开发人员必须实现的软件功能。场景描述也是需要经过迭代细化的。  *以故事叙述的方式描述如何帮助用户解决问题，最好辅以交互草图（也可以将讨论过程中确定的草图拍成照片附在场景描述中）  *需要有清晰、明确的上下文环境，说明这个场景发生在什么背景下，何时会发生  *需要从用户的角度出发，描述用户做什么，与系统的交互行为，以及用户对出现问题的反应  *不需要描述具体的界面是怎样的，场景的目的是让所有人员明白用户的目标是什么，以及用户希望怎样做  *不涉及实现和技术的内容  *内部的API不应该在场景中描述  3、场景的粒度如何把握？用户问题的大小决定了场景的粒度大小，并没有一个标准来定义场景的粒度。场景应该具有高内聚低耦合的特征，一个场景内部各个环节的逻辑关系可以比较紧密，而各个场景之间应该是低耦合的。不需要把所有可能的场景都罗列出来，只需要描述主要的、典型的场景。  一个例子：设计一个创建贺卡的网站。对比两个不同视角的结果。  站在程序员的角度可能会为这个例子列出以下活动： 1.为卡片添加文本信息 2.为卡片添加图片 3.从卡片库中获取草图 4.发送卡片： 1) 通过email发送 2) 打印卡片 站在用户的角度则会列出以下活动： 1.发送生日贺卡 2.发送周年纪念卡 3.发送聚会请帖 4.从一张空白卡片开始制作贺卡 可以看出来，从程序员的角度列出的活动，系统大致按下述方式运行：开始是一张空白卡片，菜单功能提供：添加文本、图片，从库中加载卡，以及发送卡片。这样，用户必须坐下来从一张空白卡片开始，弄明白所有的可用的功能，并通过这一堆功能创建一张自己需要的卡片。而从用户的角度出发，软件就变得简单了，他们可以很轻松地完成自己所需要的卡片。场景则是针对每一个活动再细化描述活动执行的过程。  4、如何抽取特性？特性（即Feature）是根据场景描述抽取的。要将场景逐一模拟一遍，并通过头脑风暴的方式提出问题，讨论并给出解决方案，在此过程中，也是逐步明确特性的过程。在此过程中需要注意几点：1)讨论场景时一定不要匆匆忙忙的，需要有充分的时间，仔细地模拟场景过程；2)尽可能多地提出问题，并从设计的角度讨论确定方案；3)要有市场、需求、架构、开发、测试等人员共同参与，最终需要达成共识。  5、如何取舍特性？首先从用户的角度出发，抽出那些支撑场景必须的功能和非功能性要求，标定为P1级的，这些是产品必须提供的特性。然后考虑开发周期、资源投入和开发难度，以及对用户的影响，确定剩下的哪些功能是需要提供的，标定为P2级的。从中剔除那些不做的功能，放到“非目标”中。剩下有分歧，模棱两可的功能，可以标定为P3级，在有时间和资源的情况下才会考虑实现。  6、如何确定特性的粒度？特性的粒度大小是通过规模估算得到的：S—小型，开发工作量在3人•日以内；M—中型，开发工作量在4-10人•日以内；L—大型，开发工作量在11-30人•日以内；XL—超大型，开发工作量在30人•日以上。特性的粒度可按照特性的优先级划分来区别对待，P1级的特性，建议最终的规模在S或者M—小型或者中型，开发工作量在3-10人•日以内比较合适；对于P2级的特性，可以定在4-20人•日开发工作量的范围；对于P3级的特性，则可以是较粗粒度的特性，可以在需要考虑实现时再进行细化。可参考微软的模式，一般特性的粒度按照1-2周的开发工作量（不包括测试）来划分，对于界面入口不同的功能则是划分成不同的特性，例如：有图形化界面和命令行方式，是分为2个特性来做的。  7、特性的优先级划分：  *P1--must have，属于产品必须具备的特性，没有此特性无法完成一个业务场景的；  *P2--nice to have，属于产品的扩展特性，有了这些特性让产品更好用，但是没有此特性，用户也可以通过其他方式完成业务；  *P3--may not have，属于产品的可选特性，在非典型场景下可能才会用到，锦上添花型。