The second origin are the names used. If a programer write a source code unit, he usually have an idea about purposes. He chooses meaningful names and adds comments in the headers. In this case an user can find the information looking in the source code.
If none of above sources contains necessary information, the user may ask the developer of the source code unit, or other users. In the worst case the user shall study the source code to make some assumption about its purposes.
The advantages of user-oriented information are well known. In some companies management introduces corresponding standards and forces the developers to follow them.
Unfortunately there don't exist tools that can proof how good the user has understand instructions. The user-level documentation cannot be verified automatically too. The common practice is to consider such documentation as not very important and don't give resources to make it good enough. The results are lacks, ambiguity and errors.
If an user cannot get precise information, he makes assumptions, those may be correct and may be wrong. For instance a programmer sees the function "GetMaxWindow". This function gets no parameters and returns long integer value. The user may decide that this function finds the descriptor for the window of maximal size or the maximal size of a window or maximal possible number of windows. If he has more than one ideas, he can check each and choose the most probable. If he has only one assumption, he'll use the software component according with it. If this decision is wrong, the software gets a new error.