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.
In my last job i worked as a PM and did quite a bit of system process/enhancements to existing system/new developments. When we decided to update the workflow associated with our core system we worked with some consultants (who had been very good in the past), but for this work engaged another consultant who spent quite a lot of time doing business requirements/analysis through interviewing mostly senior managers/managers (I was in the group that was interviewed).
On completion he produced a bound book (in colour, he got quite picky if you printed in black and white because the colour represented different things) full of class diagrams. I hadn’t (and neither had any of the other managers) come across class diagrams. I think there may also have been some use cases, can’t remember if there were any activity diagrams but i’m thinking not. As the stakeholders the class diagrams were not a good tool to represent what we had spent exhaustive days talking about (and it was exhausting). And then another 3 or 4 days listening to what they represented was even more exhausting – we got more and more confused and it wasn’t a process we enjoyed. As a tool they didn’t work for him because he didn’t get the job preparing our detailed requirements, we just found it really difficult to work with him.
However from the work on this course i could absolutely see the relevance of completing a domain model and from a very high level i would have a crack at explaining it to stakeholders – but in the context of all the other tools that are available to show them (eg workflow diagrams and business use case diagrams etc.).
My take would be – it’s more about how it’s presented and the clarity it brings to explaining the requirements to the stakeholders – as always communication is key. We thought the consultant was undoubtedly really clever but he wasn’t able to translate our requirements into something that we could understand, so that we could verify it was what we wanted.