In Learning to Use Visual Requirements Models: Adding Context by “Overloading” the Business Data Diagram, the author tells us how to overload a Business Data Diagram (BDD).
One of the main goals with visual software requirements models is effective communication, so I tend to be “for” anything that furthers the cause. When I look at the author’s example, I understand the value in what the author is doing, but have a couple of questions when looking at that BDD. (If you click on the BDD with my questions in green and yellow below, you can see the details that follow.)
For example, in the BDD below I read “Co-signer can have Borrower,” but my sense of logic tells me the opposite is probably true. Similarly, I’m not sure if a loan belongs to a product type or a product type belongs to a loan. 
At this point, I realize I don’t know exactly how to read the text added to the BDD. Oops; the author was trying to communicate more effectively, not add confusion. Should we throw out the additional text? Nope, it’s good information. We should just present it in a way that eliminates confusion.
So, how do we make it clear which direction to read the text between the business objects? We could add a directional indicator to tell which way to read the text… But, people already have trouble with the cardinality on BDDs, so adding another symbol for them to learn probably isn’t a great idea. Light bulb moment: this model is in English, we should be able to make reading the added text obvious by leveraging the way people read English: left-to-right and top-to-bottom. That’s why I was confused—I expected it to make sense when read like that.
I also question whether Loan number, Amount, and Interest rate are really separate business objects, or just important attributes of the loan. If they are important attributes the author wants to call attention to, they can do that using another technique. The author can overload the BDD with a call-out that contains the information.
Here’s the BDD updated so that the text joining the business objects can be read left-to-right and top-to-bottom. It also has the key attributes as a call-out.
My questions are now eliminated. I do realize that reorganizing a BDD is not always the solution; sometimes it is just not practically possible. In this case, just change the text joining the business objects. You can always pick words that are correct reading left-to-right and top-to-bottom. For example, “Co-signer might be needed by Borrower”.
Someone recently put up a paper towel dispenser beside our break room sink at the office. I used a paper towel from it before I consciously realized it was new. That’s the way it should be when we overload our software requirements models—people should successfully use the added information without having to think about it.
