## 1 Introduction  
The Internet of Things (IoT) development community has been embracing new software development methodologies to make IoT system development faster, better, and cheaper [1, 2]. With success stories of the adoption of agile methodologies in IoT-related areas such as embedded systems and hardware [3, 4, 5], the IoT development community can be expected to continue to look into new methodologies, especially the ones with proven results in the broader software development community. In this context, this paper explores applying _behavior-driven development_ (BDD) [6] for IoT systems development. As a relatively new agile software development method evolved from _test-driven development_ (TDD) [7], BDD broadens collaboration by moving from developer-centric tests to whole-team executable specifications. BDD has gained a lot of traction in the software development community. According to a recent vendor survey, 37%, 44%, and a projected 50% of software development teams were adopting BDD in 2017, 2018, and the 3-5 years beyond, respectively [8]. With an ample amount of the literature (e.g., [9, 10, 11, 12]) and many supporting tools available (e.g., [13]), BDD makes a good candidate methodology for IoT system development. Indeed, we are beginning to see positive results in applying BDD for developing real-time embedded systems [14], automotive systems [15, 16], and avionic systems [17]. In our own experience, we have also benefited from BDD in the development of a smart cone system for protecting road maintenance crews working on highways [18]. Key to the success of BDD is the patterns that encourage the development team to _specify collaboratively_ and _illustrate with examples_[9, 10, 11, 12], thereby minimizing the gaps of misunderstanding between members of the IoT development team including domain experts, analysts, hardware and software developers, and testers. The captured specifications are recorded in textual descriptions written in a simple natural language template; an example is the _Given-When-Then_ template of the Gherkin language [19]. Since well-written Gherkin specifications are readable and understandable by all team members, the specifications can be continuously refined throughout the life cycle of an IoT system for feature changes, extensions, and bug fixes. Further, through tool support, the Gherkin specifications of an IoT system are _executable specifications_ that serve as _acceptance tests_ to drive the subsequent coding and testing activities [9]. When frequently executed and maintained, the specifications turn into _living documentation_ to replace the traditional requirements and specifications documentation that is prone to be out of sync with the current system behaviors [9; 12]. Despite the merits of BDD described above, in developing the smart cone system which encompasses both sequential and concurrent behaviors [18], we found that the Gherkin language does not yet support the specification of concurrent behaviors. This inadequacy created some difficulties in writing specifications with Gherkin for our interdisciplinary team consisting of traffic safety specialists, hardware engineers, embedded system developers, and software developers. In particular, the traffic safety specialists were unable to use Gherkin to precisely specify the concurrent behaviors of the smart cone system and had to depend on the developers to interpret the intended concurrent behaviors at the implementation level. We will further show that the concurrency inadequacy of Gherkin can lead to specification errors with two IoT examples in Section 3. To fix this inadequacy, we propose an enhancement to Gherkin to support the specification of concurrent behaviors. We follow the _parsimony principle_[20] by not adding new keywords to Gherkin. Instead, we introduce the concept of _sequential groups of concurrent steps_ by limiting the use of Gherkin keywords And and But for concurrency. Specifically, the groups are interpreted sequentially in the order they appear in a Gherkin specification.