In most cases, this idea is embedded in the domain of the customer, it adresses data which are key parts of its domain. Or it is related to actions performed in this domain. In either way, it has no technical nature. (It may be that the customers domain contains technical things, computers, machines, but then they are part of the domain as all other and therefore are natural to him.)
Then there is the other case: the customer has no idea, just a problem. But then, he has at least a goal, which means there is an idea of a situation which he (or she) wants to achieve.
Now it is our job as software professionals, to draw a picture of a system, which, beeing embedded in the customers world, would solve his problem and let him reach his goal. If we have this picture and it its approved by the customer, we could build the system and the customer will be happy.That sound's easy but it is not. The customer has a sound picture of his domain in mind, but a weak imagination of the new system (well, he is no technician...). And this new element must fit in. The software professional on the other side has a strong imagination of "his" new system (what a wonder...), which must be embedded in the - from his point of view - weak picture of the customer domain. It is easy to understand, that the weak parts are in danger of beeing forced to fit and therefore getting distorted. Now the problem is obvious: all parties have different parts of the picture that are weak. In consequence, the resulting overall picture of the customer and the software developer will differ necessarily.
We know, that an iterative process for software development is the best solution. By creating prototypes and mock-ups, things that can be "touched", the picture comes out of the head of all parties and can be experienced directly by each other in early project stages. And because it is not feasibile to come through this in one step, many steps are done, where ever news prototypes and mock things display and stress different aspects. But in the sum, over all iterations, the picture should become more and more equal for all parties. The picture of software becomes clear and sharp, we've got consensus. (BTW, this would be the planing guide for iterative processes: touch all constitutive aspects at least one).
Sounds easy. But software is developed in teams, and not all members of the team can talk with the customer directly. And more worse it is not always possible to talk with one customer, there may be many stakeholders. So the picture in mind must be communicated via documents, but how ?
To find an answer, think about a patchwork image, and the task is to fill a empty place. So the first question is: the shape. Which shape I need to fill ? Related to our software project, this would be the interfaces, logical, functional and physical. Then, one might look which colors would match, then which things the part should show to continue shapes or patterns of the whole picture, and so on. That means: for communication via a documents, one should take certain point of views to the domain and the new system, explain them and why the part fits in the hole. One chapter one point of view, with the goal, to come close to the picture of software.
If all important aspects are described like this, then there is a chance that many people which read the documents become a more ore less comparable picture of software (and its environment) in their minds and the right software at the end.
BTW: There are people, which can design such missing parts of a picture handling all aspects at once - we call them artists.
