tl;博士
如果很难沟通的话。将行为（即“何时”子句）嵌入到需求中会更好（IMO）。
您发布的建议需要解释
您发布的建议实际上并没有告诉我要求是什么！相反，我现在必须弄清楚潜在的意图必须是什么才能获得你想要的东西。换句话说，我必须对预期的逻辑进行“逆向工程”。这是传达需求的一种更糟糕的方式。事实上，这是一种更糟糕的方式来传达任何复杂的东西。
这是对您发布的建议的一种解释
Given a user who is not an admin
And products which are not active
When that user ever views any products
Then he cannot view the inactive products
Given a user who is an admin
And products which are not active
And products which are active
When that user ever views any products
Then he can view the both sets of products
但是，在您发布的建议中，是否应该允许非管理员查看非活动产品？这是一个合理的问题。
如果您只是说某些产品是“为”某某某某而设计的，那么我不知道您是指“所有权”还是“可见度”。如果我编写的代码允许所有用户查看其他人的产品会怎样？如果您单击管理员用户配置文件，您会看到所有产品。如果您单击非管理员用户配置文件，您只会看到活动产品。看？我已经根据您的要求成功地为每个用户策划了列表。但是，如果您的意图是基于安全性的！不知何故，非管理员根本不应该看到那些存在于 UI 中的产品。这是一个非常不同的要求，但是您的文章没有区分它。这是另一个很好的解释：如果您希望我过滤的唯一内容是某种“选择性”怎么办？即：我可以查看所有产品，但我不能选择/附加/使用非活动产品（除非我是管理员）。同样，这是对策展和可见性的不同解释。
您可能会声称“上下文”使这一点显而易见。鉴于应用程序的页面流程，没有人会误解其意图。但是，在您看到足够多的程序发生重大变化后，您会根据“上下文”来评估不，以使事情变得“显而易见”。或者有人只是将你的小黄瓜文件分成两部分。如果需要周围的需求才能正确解释这一点，那么现在我们只需通过改进代码中的文件结构就失去了这一点。
简而言之，如果很难沟通的话。我相信将行为嵌入到需求中可以减少人们误解它的机会。
为什么我更喜欢我的建议（其中包含“when”子句）
相比之下，这个答案中的建议是字面的。以后添加或更改哪些其他权限层或 DB 架构如何更改都无关紧要，我们知道需求是什么。
我认为行为驱动的需求也可以帮助您更好地与产品负责人沟通。我打赌产品负责人会说“我不希望任何其他人（除了管理员）能够看到非活动产品。”我的建议几乎是产品负责人在这种情况下所说的话。您的建议必须将真正的意图“翻译”为程序员喜欢思考的“数据驱动”视图。但是，我们越将他们的 cmets“翻译”成不同的格式（如数据结构图），我们就越冒险假设和误解。这样的翻译是“有损的”。在我们的职业生涯中，我们听到产品负责人说“什么？那不是我说的！”的次数越多。我们对“隐式”沟通或“明显”的需求翻译越感到不舒服。相反，明确说明每一个文字要求。
根据我的经验，产品负责人总是首先考虑更多行为/客户驱动的术语。不过这只是我的经验。
关于小黄瓜
Gherkin 只是一个工具，所以它只做一件事，做好一件事：它迫使您以行为驱动的开发 (BDD) 进行思考。如果你使用小黄瓜，你必须根据“输入”行为来写东西，这是必需的结果。否则你使用了错误的工具。
相反，您应该决定是否认为 BDD 是一种强迫自己遵循的好哲学。如果您认为遵循该理念是好的，那么您将需要不断改写要求，直到出现“何时”声明。强迫自己做出“何时”陈述的做法被某些人（包括我）认为是好的。
此外，小黄瓜与其他文档并不相互排斥。例如，您仍然会有 ERD 图、UI 模型等。事实上，您甚至可以从其他设计文档中参考小黄瓜场景。 Gherkin 旨在帮助您了解您是否按照客户的要求进行操作，而不是帮助您了解代码设计是否良好。其他规范可以做到这一点，并且它们可以协同工作。
不仅如此，“需求”本身也有层次，并以不同的媒介表示。例如，您可能需要产品负责人为客户编写的“签字”文件。该文档的格式与小黄瓜非常不同，因此很好。在另一个极端，你有一个 ERD 图。我认为 gherkin 介于这些需求抽象级别之间。
此外，回归测试应该变得容易。使用小黄瓜，您甚至可以将其自动化。然而，再一次，根据您发布的建议，我担心回归测试人员必须推断并找出要测试的案例。这是一种可怕的回归测试方式。每个案例都应该详细说明。即使它对你来说是“显而易见的”，我保证对其他人来说并不明显（反之亦然）。另外，即使对于您自己，如果您必须进行回归测试，那么您希望事情变得简单。回归测试的压力越大，它发生的可能性就越小，而且做得越差。有明确的清单可以减轻压力，更容易遵循。行为驱动与回归测试完美契合。