From various sources, the idea of an ubiquitous language seems to be a central part of BDD (Behavior Driven Design), where a dedicated effort is made to ensure that the business driven parts of a company are aligned with the development driven parts of a company in terms of a common vocabulary.
Joe Ocampo does a very good job of describing this at a high level here.
But as I suggest in the comments, I'm not sure I buy it. Not exactly any ways.
It is certainly true that there is often (per my comments, I would say 'practically always') a disconnect between different parties when trying to enunciate and understand requirements. To use the same example I mentioned in the comments, in a not so distant meeting, the word 'Audit' played a key role in some discussion.
Now, clearly, at a very high-level, just about anyone can understand what someone means when they say they want auditing functionality added to an application. But you still have to lay out those requirements in some detail to make them actionable, and so having a common vocabulary where the terms within the organization are clearly defined across functional units certainly can't hurt (or at least you wouldn't think so).
But would it really get you anywhere? What it means to have an audit trail from a database perspective is significantly different from what it means to have an audit trail from an application perspective, and meeting the requirements requires a lot of implementation knowledge that a business user simply isn't going to have (unless they are also technically inclined).
The standard ATM example that is used to describe BDD and how you could create specs and whatnot is particularly compelling, not only because it seems like a 'holy grail' of some sort, but because it involves basic math. Anyone can understand the concepts involved. Which is good, as a more complicated example would get in the way of explaining BDD itself (this is a complaint I have/had with a few of Fowler's examples...they were so obscure to me that the example itself got in the way of what it was supposed to be an example of).
But when you start getting into harder cases, then I'm not so sure. Even the specs could become difficult to write, in any way that was of use, or, more clearly, that got around the difficulties of implementing the requirements.
In the case of the 'Audit' example, as someone who barely understands the system, I have to pay very close attention to what everyone says, and ask a lot of questions. And it was clear to me almost immediately that there was a bit of a disconnect. But in the end, the real difficulty is that the architecture of the system simply can't implement what was asked for, for almost purely technical reasons. And the explanation of that real difficulty isn't something that I can see a 'ubiquitous language' helping with.
And I would be concerned with all parties having to 'dumb down' what they actually mean into terms that could be more commonly understood. Would your 'ubiquitous language' end up being just the lowest common denominator?
Having said all that, I am intrigued by many aspects of BDD. And since I have something I can greenfield, I think I'm going to try it out.