Entity Relationship Diagrams (or ERDs) are a way of modelling the connections between different classes of “thing” in a system. They identify a particular type of business rule – how many of one type of thing can be connected to another type of thing.
If you’ve ever found yourself in User Acceptance Testing (or worse still, going live!) with a system, and a user tells you “it won’t let me store multiple addresses for the customer”, then you’ve already found a use for ERDs – albeit perhaps a little late!
Many business analysts shy away from using them, as they can feel a bit too abstract. They’re certainly less easy to explain to a stakeholder than your average process model! The model itself will probably mean very little to anyone other than you, but getting to the stage of having the model will have taught you a great deal about what the system needs to do. They are however worth serious consideration, and like all models in business analysis, it is what you find out while creating the model that’s important.
I’ve put together a brief guide on building ERDs here, and of course you can get in touch if you’re looking for training on the subject.
I tend to build myself an ERD during the problem definition or solution selection stages of a change initiative. The diagram is unlikely to be complete at this stage, but it provides a way of clarifying your understanding of the problem space, or comparing different solutions. On more than one occasion I’ve been able to rule out an off-the-shelf software product because it didn’t support the entity relationships we needed.
When it comes to the solution delivery stage, your ERD becomes invaluable. You may not need to actually present an ERD in your requirements documentation, but you should make sure you can still tick-off both of these actions:
- You’ve confirmed with business stakeholders that the business rules you identified are accurate.
- You’re communicating these business rules to the developers in your requirements documentation.
I often present an ERD, but showing textual descriptions of the business rules as well as the formal symbols. Stakeholders quickly tell me if any of those rules are wrong!
I tend to go a step further in this stage, and use my ERDs as a way of working with stakeholders to identify the attributes of entities. These can includes things like a customer having a name, or an invoice having a reference number. I’m very careful not to stray into designing the system – as a BA, I recognize that system architects and developers know much more about the best ways to build a system – and so I avoid the language of “tables” or “fields”. However, by identifying what information belongs to which entities, you can make sure nothing gets missed in your process designs, use cases or user stories.
The true value of the ERD is in testing assumptions and avoiding oversights. The act of constructing the diagram forces you to ask the right questions. The discoveries you make help to ensure you’re giving developers all the information they need to design systems that are fit for purpose.