When helping ArgonDigital clients define software requirements, one of the many models we use is the Business Data Diagram (BDD). At a high level, the BDD is used to describe the relationships between business objects; in this way, it’s very similar to an Entity Relationship Diagram (ERD). In this post, I’ll share how I learned about the importance of context in BDDs.
When I first started working for ArgonDigital, the BDD was the hardest model for me to grasp, but after a lot of guidance from colleagues and practice with it, it is now one of my favorite models to create because it provides a very different – and interesting – way to think about the data that is used in everyday business processes. I recently worked on a project where, to show the client the ways in which visual models could be useful on their project, we drafted several example models. In this “gift package” of visual models, we included examples of BDDs.
Since the project made heavy use of business data, and there were several quirks in the relationships among business data, the BDD model was a great fit for communicating requirements clearly and completely. My first iteration in creating the example was a “classic” BDD, and looked something like this (note that all images have been altered a bit for client confidentiality):
This, to me, made complete and total sense. But I learned the “classic” BDD wasn’t enough. While reviewing this draft with a colleague, I was taught why and how to “overload” the BDD.
The idea is simple enough: the BDD is used to show relationships, but it lacked context. My colleague made sure I understood the importance of considering how models may be consumed, and then began to teach me the ways in which to overload the classic BDD model with everything that I could think of that would help the development and testing teams understand the model. After working through different revisions of the model, we produced something like the following:
Now you can see the difference between the “classic” and the “overloaded” model – how the classic BDD simply illustrates information, and how the overloaded BDD provides the same information plus more context.
In the original BDD, cardinalities are represented by numbering the relationship: 1 to 1, 0 to many to 1, etc. However, not every recipient will “get” the cardinalities in this presentation. In the second BDD, the cardinalities are illustrated in two ways: by number and by symbol. This can help bridge the gap if you are showing a model to groups of people who may have different ways of learning. (Personally, I am a more visual person, so my eyes would gravitate towards the symbols rather than the numbers, but I have met many people who would rather just see the numbers without a visual representation.)
Furthermore, the relationships between objects are additionally specified with the operating verbs. In the second diagram, we can see that a Loan belongs to a Product type. Without these “belongs,” someone may infer that a loan merely “has” a product type, which understates the importance of the relationship between loan and product type. While this is not incorrect, by overloading the BDD with “belongs to” context, the model communicates more clearly that the loan itself exists in a greater hierarchy of product types, which can lead to further elicitation of requirements around product types and loans.
As I’ve been learning from my colleagues at ArgonDigital, communication is one of the most important things to consider in business analysis. If you had elicited and built the most complete requirements definitions possible, but did not communicate it effectively to stakeholders and developers, it’s almost as if all your (and your team’s) efforts never happened. Requirements are pointless without ensuring they are understood. Overloading a visual model like the BDD with more context can help greatly in your communications, in the effectiveness of your efforts, and ultimately in the success of your projects.
