When you reach that point of the project where your head simply hurts from how hard you are thinking, you’ve spent hours in meetings rehashing the same concepts, and yet you and your team members are not communicating effectively either about the problem or the solution, you most likely need to take a step back and confirm what each of you understands (or doesn’t).
I call this the “gnarly part” of the project and no matter what your methodology or expertise, you are likely to hit it at some point.
One technique I like to use when I sense my project team is failing to communicate about important concepts is a Business Domain Model. A domain model logically represents the business concepts to be fulfilled by the system and how they relate to one another. It should not be confused with a data diagram, with represents the actual database design or architecture. Although they may look similar, a domain diagram should use terms that are in the business domain.
(Both Business Domain Models and Data Diagrams are two of many visual models that BAs use in their work.)
Here’s an example of a domain model
This is a small section of a domain model I completed a few jobs back. It probably won’t mean much to you, because without understanding the business context and what the terms mean, domain models do not really tell you much. However, I’ve found them to be great conversation pieces, much like a coffee table book of your favorite vacation spots.
Let’s take a quick look at each element of the domain model
The boxes represent entities, or business concepts, and the lines between them explore the relationships between each concept. In this example, an RC Account can be related to zero to many VL customer profiles. This was a key concept for this product as we were leveraging a one-to-many relationship between the accounts in our legacy system and the accounts in our new system. As can be imagined, there was a lot of disagreement and discussion about this. Hence, the coffee table book effect.
Within each box, you list key data elements (in a precise data model these would be the fields in the table) that are part of the business concept. You can also identify whether each element can have multiple values.
>>Interested in Learning More?
We provide more detail about business domain models and 21 other models BAs use in the Visual Model Sample Pack. The Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.