Interesting you see understanding of the domain and requirements as two distinct processes. I’ve never seen it this way. For me, knowledge of domain comes during the lifting of requirements.
But I’m using "requirements survey" here in a very broad sense and I don’t know if we’re aligned, so allow me to go a little bit deeper.
What the customer knows
The customer never knows in advance what exactly he needs in terms of software, but he always knows what he needs in terms of business and he has some idea where a software fits the solution of the problem.
So the customer comes to us with a need of the kind:
"The machine that fills these containers should know on its own how much material to put in each one, because today this is controlled by an employee and it is difficult to hit the exact amount."
Steps in the lifting of requirements
What I understand by requirements survey starts here.
Desired capacity
What the client knows he needs we can call "capacity".
The client has just told us the new capability he wants to have on his system. See how the need can be rewritten using this word:
"The machine that fills these containers must have the capacity to match the exact amount of material to be placed on each without being dependent on the intervention of the official."
Understanding of dominance
Now, to figure out how to make software that delivers the desired capability, we need to understand the domain.
The process of understanding the domain is a work done in order to discover the software requirements, and is limited to meet this function.
This means that the software team is not interested in knowing the client’s entire operation; then the software team will not spend days in meetings with the business experts to become as expert as they.
Instead, the team will look to the experts how the employee decides the amount of material in each container; so as to understand what entries are available for the new software.
The team will also seek to learn how the employee operates the machine when they decide to interrupt the work of filling a container; so as to understand which outputs the new software should produce.
At first, the team is not interested in anything other than the operation of that particular machine, and it will only extend its learning to other details of the customer’s operation if this proves necessary during this effort to understand the machine. In principle, the domain problem is just machine operation.
So we can conclude that domain is area of knowledge of the problem that the software intends to solve. Domain is not the knowledge of the entire operation of the client.
While learning about the machine, the team begins to exercise the ubiquitous language. The language begins to be elaborated during the work of drawing the first requirements.
Software requirements
A software requirement is one of the features that software should offer. The set of all software requirements must deliver the desired capability.
In DDD, it is impossible to formulate a software requirement without the ubiquitous language. But the construction of ubiquitous language is not a separate process.
The construction of ubiquitous language occurs during the effort to formulate the software requirements.
Completion
The purpose of the software project is to deliver a capacity (possibly more than one).
Domain is the area of knowledge of the capabilities that must be delivered by the software.
To ubiquitous language is built during the effort to formulate the software requirements, it is enhanced during the elaboration of each requirement, and the elaboration of the requirements takes place throughout the project.
Software requirement is one of the features that software should offer.
The ensemble of all software requirements should deliver the desired capability.
The learning of the domain and the consequent construction of the ubiquitous language happens subject to the lifting of requirements, during the lifting of requirements, and is delimited by the desired capacity.
We can say that knowledge of the domain and the resulting construction of the ubiquitous language are "pulled"* by the need to raise requirements.
*See push system or pulled system, that in short is "do what is necessary only when necessary and only in the required amount".