 <p>You are completely missing the system's boundaries (the center box with "System" labeled above).</p> <p>On a conceptual level it is very important to understand what your system's boundaries are, and what is just <em>human driven</em> collateral/corollary labor. Keep those outside the boundary (on paper don't even draw a use case for it, <strong>in your mind understand it's part of the system but not something you implement in code</strong>, it will be documentation, training or laws) but keep it in the diagram on a sidebar.</p> <p>That sidebar (the <em>at latere natural language semantic substrate</em>) should be written in simple words and sentences. If you can't do it, you should try to better understand the domain, simplify the diagram and split it in many diagrams.</p> <p>Split it down into 3 or 4 different diagrams, each of which should be focused on those use cases which are cohesive. Use different diagrams for un-related use cases and different facets of the system. Find the right cut between complexity and simplicity, I suspect you're a bit overdoing it with the extends.</p> <p>Remember: UML diagrams are surgical tools, use them as focused as possible. More is not better, it is only confusing or dispersing.</p> <p>Finally, write down actual scenarios for the more complex use cases (those with many extensions). You'll see how difficult it will be to take into account all extension points. This will be a good indication on how complex the system is going to be.</p> <p>The more you can simplify in this early stage the better for later design and implementation.</p>