描述系统一个系统需要三个方面：
- 系统是什么样的。
- 系统中的计算以及所需的数据。
- 系统的行为基于其内部状态，以及系统内部和外部的系统交互。
传统工具
在互联网之前，用户体验被认为没什么价值，因为大多数系统用户都是公司的内部员工。如果他们想要完成他们的工作，就别无选择地使用这些系统。
这意味着低保真原型主导了人们描述系统外观的方式。有些人使用visio或powerpoint来创建这些原型。由于创建原型的速度以及我的同事对Excel的熟悉程度，我的偏好是Excel；
然后使用业务领域模型描述数据和计算。使用Rational Rose之类的工具进行数据和计算的抽象描述；使用用例usecase描述系统与外部参与者（人和其他系统）的交互。
这些都没有标准格式，但每个人都受到Alistair Cockburn的“只要能写出有效用例即可”的影响：
传统的分析世界是系统数据，而“计算和行为”这些抽象描述用于系统开发。
真实客户和示例规范
互联网开始将真正的客户暴露给软件公司，客户可以自由选择使用服务。因此，用户体验（研究和设计）已成为产品开发和系统设计的重要组成部分。低保真原型已经被高保真原型所取代，这些原型在软件开发开始之前就已经与真实客户进行了测试。高保真原型现在是系统规范的一部分，有时具有像素级精度。
互联网时间意味着快速、交货时间短。较短的交付周期需要自动化测试，并导致测试驱动的开发。自动化测试意味着需要“通过示例进行规范”以满足测试驱动的开发需求。
这就不是使用Rational Rose来表达抽象域模型，而是使用电子表格中表达数据和计算，并使用相关的正式计算定义。
2003年，Sanela Hozic和我使用电子表格，用例子来说明石油交易的信用风险计算。这是由Andy Pols和Joe Walnes在原型中实现的。2007年，我们使用包含示例的电子表格来指定复杂信用衍生产品的现金流量计算。这些示例与测试人员共同创建，并由通常计算现金流量的交易助手进行验证和添加。这些示例是使用JUnit实现的。2010年，Nat Pryce和团队创建了一个基于spredsheet的生态系统。
抽象用例和状态转换图已被Given-When-Then格式的示例所取代。usecase用例的一个缺点是，该方法不鼓励业务分析师探索替代路径，这导致了“快乐路径”的心态。Given-When-Then格式的重点允许业务分析师创建“快乐路径”场景，然后举行“三个Amigoes”会话以探索“质量路径”（假定波动性市场数据缺失）和“技术路径” “（假定服务器不可用）。
Given-When-Then的悲剧之一：
如果莎士比亚写过一部关于“Given-When-Then”的剧本，那么他可能已经开始使用“当你拥有的所有东西都是锤子时，世界似乎是由钉子制成的”。
尽管Given-When-Then是描述交互，状态和行为的绝妙方式，但用户描述数据和计算却是一种糟糕的方式。一个常见的反模式是Given-When-Then用于描述数据和计算：
- Give给定一组表中的市场数据和交易
- When当<执行诸如计算的任意事件>时
- Then那么，<基于输入的数据将被计算并被保存到数据表中>
Given-When-Then减少了理解和可读性，但通过像Cucumber和姊妹产品如SpecFlow这样的工具提供了非常珍贵的自动化。
Given-When-Then的悲剧之二：
与Given-When-Then相关的常见反模式有三个角色在用户故事中存储为验收标准的场景上进行协作。然后，测试人员将这些Given-When-Then场景转换为Cucumber格式的特征文件。这与开发并行发生，而不是在开发之前。将测试者降低为专业翻译/打字员是一个悲剧。这意味着业务分析师不一定会看到实际的Given-When-Then语句，并且它们与测试人员和开发人员之间会发生断开连接。Cucumber被视为一种测试自动化工具，而不是系统规范的存储库。
Given-When-Then的悲剧之三：
业务分析师和测试人员/开发人员之间的脱节反映在Given-When-Then社区中。业务分析师通常不会看到功能文件，也不会完全理解该过程。他们认为Cucumber没有价值，将其视为测试自动化工具。
为了填补这个空白，开发人员创建了对开发人员有吸引力的流程，这是开发人员告诉业务分析师他们认为业务分析师应该如何完成工作， 事件风暴和示例映射在培训课程和会议中很受欢迎。它们是有趣，积极的促进过程。它们易于学习和显而易见，但创造了复杂的结果。他们也无法满足业务分析师的需求，他们本质上是在复杂的文档编制和定义复杂系统的空间中运作。业务分析需要应用结构化学习技术，这需要学习和实践掌握。
悲剧是，Given-When-Then已经创造了一个更大的空白。
敏捷是那些学习“做并帮助别人去做”的人创建的，除了业务分析的情况，开发人员也做了业务分析师应该做的事情......是观察员，而不是行动者在定义过程与流程。
Given-When-Then的悲剧：结局
理想情况下，我们将意识到Given-When-Then是一个用于描述系统的交互，状态和行为的工具。我们将意识到使用Given-When-Then格式描述数据和计算会导致悲剧，应该使用Excel来记录示例。
Given-When-Then社区将联系业务分析社区，倾听，倾听他们的问题，倾听他们的需求。他们将放弃他们预先设想的解决方案，并合作创建工具，弥合业务分析师和开发团队之间的沟通差距。
当我们拥有一把锤子时，我们会发现世界不只是钉子而已。