Well … whenever I find myself caught in this predicament, I ask myself one question: Is my use case model comprehensible? That is, do my stakeholders understand it without me explaining it to them?

I consider use case modeling more useful during the analysis phase. Although UML (Unified Modeling Language) allows us to use various design level elements in use case modeling, the basic purpose of use case modeling is to help us communicate with domain experts (people who understand the business) to stipulate various business workflows. For design, we can go for more accurate models like class and sequence diagrams.

The key to a functional use case diagram is its simplicity. If its comprehensiveness and detail obscure the understanding of end users, we need to revisit our strategy. The basic purpose of UML is to bridge the gap between the understanding of end users and developers. However, if our models fail to do that, then the whole effort of modeling serves no purpose.

In my projects, I usually include the most important functionalities in my use case diagram. In this regard I replace all the CRUD (create, read, update, delete) use cases with a single use case like Manage Data or something like that. It helps me establish the priority and importance of most important use cases, which later helps me find the critical path to develop a fully functional product within the least amount of time. I also avoid monolithic use case models that try to encompass the full functionality of systems in a single diagram. As per my experience, monolithic use case diagrams are practical for only small projects with less than 10 use cases. Anything bigger than that requires the use of subsystems.