I'll take a stab in the dark here. In UML terms, they are talking about (either) a business object model or a domain model (it really doesn't matter which).
Consider the business term "Order", to the Purchasing department it is a thing they create against a supplier, to the manufacturing department it is a thing they fulfill for a customer. Two very different things. If you leap into creating an ERM (not ERD - see below) based on an unclear idea as to which thing you are modeling, errors may arise. Obviously this is a trivial example, but you can get my drift. A domain model or BOM can be used to define exactly which business thing we are talking about in a given context, it doesn't have to be detailed down to the last association role either, just far enough to provide the desired clarity.
By way of example, I was working on a project for a stock broker some years ago where the developers had an understanding of the term "ex dividend" that was completely the opposite of what it means within the broking industry, they thought of it as it is used between a broker and a client. Unfortunately this had become lost in the (typical) truckloads of documentation associated with the system and I was the only one to spot it (as a tester) very late in the dev cycle as we were reviewing the specs against the test plans.
Now, another thing I keep mentioning and I'm not sure you've got it yet. The diagram is NOT the model. You appear to me to talk about specific diagram types and issues with diagrams. One thing that I have learned over some (cant remember) years of UML usage is that a paragraph is worth a thousand diagrams. Hence in the above I have mentioned an ERM not an ERD. Diagrams (IMO) are a way to provide convenient access to model details and provide a means to illustrate a cohesive view of the model detail. My models may have anywhere between 1 and 20 odd diagrams on a specific aspect of the system. They are a tool used in developing and communicating the model, not an end in themselves.
For instance, I rarely, if ever have needed to include sequence diagrams in any published model document. Yet, some architects seem to derive pleasure by demanding their inclusion. I either ignore these pedants or shoot them, the latter is usually easier. BUT, to be sure I have used a couple of trainloads of seq diagrams in the development of some models.
hth
bruce
