In the book titled ”Domain-Driven Design”, Eric Evans suggests that one of the fundamental ingredients of effective software modeling is the deliberate adoption of a shared language between domain experts and software developers.
Such a ubiquitous language develops as the understanding of the domain evolves.

The idea is that by eliminating the linguistic barriers between different groups, we enable the creation and refinement of a rich model that embeds the language in code.
This model should be sufficiently expressive to support both domain experts and developers in their communication of rules, requirements, etc.

I’m still not sure about the feasibility of such approach, but don’t get me wrong, the objective is certainly admirable.
My fear is that our capability of building a ubiquitous language on which our model should be based is inversely proportional to the number of individuals and groups involved in the effort.

Each member tends to have only a partial view of the domain (including domain experts!). Each individual has different mental maps about how things are or should be.
The process of creating and sharing both language and underlying model could face challenges similar to the ones that experts find in an enterprise when adopting a shared database strategy or a global canonical model: it’s very hard to do properly (trust me… I know.).

Are there valid alternatives? I don’t know for sure. Use cases, for example, are great at bridging the gap between domain experts, users and developers. But admittedly they are not of huge help in all situations and they give limited or no support for validating models and business rules.

Whatever style we adopt for gathering requirements however, it is important to keep the right attitude, and learn the most important skill of all: the ability to listen.
The biggest failures in software development often happen when developers or analysts don’t question their mental maps enough to ensure that those accurately reflect reality.