Data Models

I'm a big fan of the Conceptual or Logical data model as a way of driving communication about the problem domain. Without one it's almost guaranteed that you will miss requirements and make some bad assumptions about the way users think of the world.

At a fundamental level a Logical Data Model is simply a glossary.

• When I say Customer what do I mean?
  
• When I say Location how do I describe it?
  
• When I say Measurement what information does that entail?
  
• When I say a Charge has a Recipient what sort of thing is the recipient?
  

Unless you can answer this sort of question you just can't reasonably communicate about much else.

One of the problems is that fully-laden ER diagrams are the most "correct" way to capture this information and also incredibly intimidating for end users as they're just so busy and technical looking.

To counter this I tend to strip my ER diagrams down to basics and then pretty them up. This isn't always appropriate, I've taken an example below from Bridging The Gap where the detailed mapping from an old to new system was important so the fully-blown ER was required.

This take a very busy & technical looking document like this:


To a quite simple, focused almost cartoon like output like this:


This trades off some accuracy and level of detail for possibly much higher user engagement, and you can do it without losing any fidelity about the things you actually are trying to communicate, e.g. composition of each entity and their relationships.