移动互联网时代的核心竞争力就在于场景之争。这里边所言的场景有两种：一种是天然的场景，比如去看演唱会，去咖啡馆喝咖啡，去听老师讲课培训，这种场景的亲临现场的体验感比较强，有极强的市场需求，但同时也都面临一个天花板;还有一种是构造的场景，比如用快的软件打车，用大众点评、微信消费，用线上视频观看直播等等，这种场景是通过与天然的场景形成互补，从而挖掘另一种维度的“体验感”，本质上也是具有场景消费特质的。在现场看演唱会，能够感知现场近距离与明星接触、与上万粉丝情绪传染的全身心的感官体验，这种体验是立体的，是无可取代的，但这种场景又像是一个“孤岛”上的狂欢，受时间、空间影响比较大。而通过技术驱动，大数据运用，快捷支付，云端连接等互联网技术给用户制造一种千里眼、顺风耳、时间逆转、空间放大、粉丝交互、参与感等多种互补的场景体验。我认为各行各业都应该达成天然+构造场景的融合，双管齐下才能真正给用户带来三维立体的体验感，不仅娱乐行业是这样，对在线教育、电商、旅游等多个行业都会有一定的参考价值。
======================================================
#==============以下摘自需求工程基础、原理和技术==================
======================================================
场景
场景中记录上下文的信息，包括：参与者、角色、目标、前置条件、后置条件、资源以及位置；
参与者：参与者是与系统交互的人或者其他系统；
角 色：角色刻画了一种特定类型的参与者；
目 标：场景描述了对目标的满足；
前置条件：前置条件是为了执行某个场景，在执行该场景钱必须满足的一些条件；
后置条件：在执行完某个场景之后，系统内部或者系统上下文应该满足的条件；
资 源：资源是一种场景执行前必须满足的特殊前置条件；
位 置：执行该场景的显示或者虚拟的位置；
需求确认是一种特定类型的分析性质量保障手段。
分析性质量保障还包括测试和验证；
确认：是否在构造正确的系统；确认有两种基本答案是：适当不适当；
验证：是否在正确的构造系统；验证有两种类型的基本答案：正确和不正确；
基于需求的测试：ScenTED方法--基于场景的测试用例导出
测试的目的是在受控的环境与条件下运行的一个软件密集型系统或部分的系统，以发现其与需求规格说明的偏离之处，并检查系统是否满足已定义的验收标准。
测试的两大核心活动是测试用例定义和测试执行。测试用例可以在实现系统或其构建之前就被定义。因此，测试用例的定义与需求工程有可能会并行的执行，即在开发过程的早期就能否定义测试用例；定义测试用例能发现测试所参照的需求规格说明中的缺陷。
