Formal methods use abstraction and rigorously verified refinement to manage the design of complex systems, ensuring that they satisfy important invariant properties. However, formal verification is not sufficient: models must also be tested to ensure that they behave according to the informal requirements and validated by domain experts who may not be expert in formal modelling. This can be satisfied by scenarios that complement the requirements specification. The model can be animated to check whether the scenario is feasible in the model and that the model reaches the states expected in the scenario. However, there are two problems with this approach. 1) The natural language used to describe the scenarios is often verbose, ambiguous and therefore difficult to understand; especially if the modeller is not a domain expert. 2) Provided scenarios are typically at the most concrete level corresponding to the full requirements and cannot be used until all the refinements have been completed in the model. We show by example how a precise and concise domain specific language can be used for writing these abstract scenarios in a style that can be easily understood by the domain expert (for validation purposes) as well as the modeller (for behavioural verification) and can be used as the persistence for automated tool support. We propose two alternative approaches to using scenarios during formal modelling: A method of refining scenarios before the model is refined so that the scenarios guide the modelling, and a method of abstracting scenarios from provided concrete ones so that they can be used to test early refinements of the model. We illustrate the two approaches on the ‘Tokeneer’ secure enclave example and the ERTMS/ETCS Hybrid Level 3 specification for railway controls. We base our approach on the Cucumber framework for scenarios and the Event-B modelling language and tool set. We have developed a new ‘Scenario Checker’ plugin to manage the animation of scenarios.

形式化方法使用抽象和经过严格验证的优化来管理复杂系统的设计，以确保它们满足重要的不变性。但是，形式验证并不足够：还必须对模型进行测试以确保其行为符合非正式要求，并由可能不是形式建模专家的领域专家进行验证。这可以通过补充需求规范的方案来满足。可以对模型进行动画处理，以检查方案在模型中是否可行以及模型是否达到方案中预期的状态。但是，这种方法存在两个问题。1）用于描述场景的自然语言通常是冗长，模棱两可的，因此难以理解；尤其是在建模者不是领域专家的情况下。2）所提供的方案通常在最具体的级别上对应于全部需求，并且只有在模型中的所有改进都完成后才能使用。我们以示例的方式展示了如何使用精确而简洁的特定于领域的语言来编写这些抽象方案，其风格应为领域专家（用于验证目的）和建模者（用于行为验证）都易于理解。用作自动工具支持的持久性。我们提出了两种在正式建模过程中使用方案的替代方法：一种在模型精炼之前优化方案以使方案指导建模的方法，以及从提供的具体方案中抽象方案的方法以便可以用于测试早期改进模型的 我们在“ Tokeneer”安全飞地示例和ERTMS / ETCS Hybrid Level 3铁路控制规范中说明了两种方法。我们的方法基于场景的Cucumber框架以及Event-B建模语言和工具集。我们开发了一个新的“方案检查器”插件来管理方案的动画。