Here's the relevant quote:

A common risk with software development includes communication breakdowns between Developers and Business Stakeholders. BDD uses the specification of desired behavior as a ubiquitous language for the project team members. This is the reason that BDD insists on a semi-formal language for behavioral specification: some formality is a requirement for being a ubiquitous language. In addition, having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally.

I'm thinking an actual formal rigorous "language" that has a grammar and compiler could be useful for, say, auto-generating test stubs from specs or for guaranteeing that specs have certain properties (consistently named nouns and verbs, etc.).

In the BDD paradigm, then, why should the "ubiquitous language" be merely semi-formal and not completely formal/rigorous?

  • 1
    Have you ever met a Business Stakeholder? You couldn't get them to observe a rigorous syntax and formal semantics if you spent your entire working day on it. Sep 12, 2014 at 21:03
  • Met, yes. Did stories or requirements or anything like that with them, no. You clearly have more experience than me - why is that true? Is it a willingness issue on their part or not knowing how or ... ? Sep 12, 2014 at 21:32
  • 5
    Basically, business stakeholders are not programmers. They deal every day in shades of gray, and don't have the same black and white sensibilities that we do. Sep 13, 2014 at 0:02
  • 1
    +1 I would argue that formal language is quite foreign to most people for the bulk of their day-to-day activities and that most people don't realize the sheer level of detail that goes into making software. Suppose you ordered a sandwich at a restaurant and they asked you how to make it - but in the level of detail that is required to write software. By the time they asked you details about the tensile strength of the knife used to spread the butter on the bread, your hunger might start to erode your desire for the formally-specified sandwich because of your perspective on the issue at hand.
    – J Trana
    Sep 18, 2014 at 2:13

2 Answers 2


The "ubiquitous language" should be semi-formal because you want to have conversations about how the code should behave.

If you make the language formal, you'll end up having more conversations about adhering to the formal language than you will about the behaviour of the code.

I wrote a blog post that illustrates what happens when the concept of formal examples is taken a bit too far. The ability to simply have a conversation, be forgiving about the language used, and sort the rest out later, is key to successful BDD. Here's another blog post on deriving Gherkin from conversations which might also help.


go ahead an formalize the ubiquitous language if it helps describe/define/solve the problem in the chosen domain - that's called a Domain Specific Language

But don't expect business users to write DSL; it's enough if they can read it, to facilitate the conversation described by Lunivore

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.