The benefit of simple use case diagrams to understand IT architecture
bernie_michalik 1100004GGT Visits (2484)
In the last year I have been working with a client on building, changing and even migrating systems. In discussions with other architects, I have found the best way to determine what we know, what we don't know, and what we assume, is to draw straightforward use case diagrams like this.
I typically start by drawing a box in the middle of a blank page and labelling it. Then I ask them who all the actors are that are going to interact with the system. They could be employees, admins, customers, third party systems, or legacy systems. Anyone or anything that will create or read or update or delete data in the system, I draw them around the system. Then I start asking them what they will do and add the use cases inside my system box (e.g. UC1 and UC2). Then I start labelling the transactions, because they may have different qualities. This helps me understand the non functional requirements. For example, UC1 may be: produce a report. But a user may do it every day during office hours in a certain time zone (T1), while an external system may do it on Sunday evening in a different time zone (T3). The more data I can list out like this, the better chance I have of understanding an existing system or developing or supporting a new system.
You don't have to be an experienced business analyst to produce a use case diagram. (Though having a good BA helps a lot.) But having a use case diagram, even a basic one, can help everyone better understand the systems they are talking about and ensuring everyone is on the same page.
By the way, you don't need complex tooling to produce use case diagrams. I created this using Plant UML. Then I just copied the diagram I created and added some detail in Microsoft Word. You can use better tools than that. The point is, you don't need sophisticated tools to describe your system. For more on Plant UML and use case, see here