I had an interesting email exchange with one of our extramural students who works as a Business Analyst. He was recently told by a developer that class diagram modelling should only be done by developers, not by the BA. However, I imagine the developer’s definition of ‘class diagram’ was the kind of detailed design level class diagram that developers might use. The type of class diagram we use in analysis is the domain model, which uses a subset of the notation of a class diagram. The role of the domain model in the analysis phase is to clarify business rules such as, for example:
- can an account holder have more than one account?
- how many courses can a student enrol for at any one time?
- how many course credits comprise a degree?
- how many standby tickets can be issued for a flight?
- etc.
These types of rules can be expressed in text, but I personally think they are much better expressed in a domain model. This would only include business concepts and their relationships, with some key attributes, and possibly some core operations. Here is a very simple example:
This part of a domain model expresses that a policy holder must hold one or more policies, that policies have one (and only one) policy holder, that zero or more claims can be made against a single policy, that claims have a reference number, that policies have a policy number, and that policyholders have a customer ID.
To me the diagram is simpler, clearer and more explicit than the text version of these 6 core business rules. The question is, I guess, whether your customer feels the same way. I would suggest that the effort involved in learning that a rectangle represents an important business concept, and that lines show important relationships between these concepts and their multiplicity, would be trivial compared to the benefits of clearer, unambiguous definition of business rules. I’d be interested to hear from any BAs about whether they do or don’t use domain models.
