It is very easy for use case modeling to become un-agile. To prevent this from happening you need to focus on creating artifacts that are j ust barely good enough , they don't need to be perfect. I've seen too many projects go astray because people thought that the requirements had to be worded perfectly. You're not writing the Magna Carta!!!!!!! For example, in Figure 2 there are several imperfections, the alternate courses aren't labeled in order (D appears after F and G) and the letters C and E aren't used (they were at some point in the past but then were dropped). The use case isn't perfect yet the world hasn't ended. Yes I could invest time to fix these issues but what would the value be? Nothing. Always remember AM's Maximize Stakeholder Investment principle and only do things that add value. Repeat after me: My use cases need to be just good enough. My use cases need to be just good enough. My use cases need to be just good enough. Why does this work? Because in an agile environment you'll quickly move to writing code based on those requirements, you'll discover that you don't fully understand what is required, you'll work closely with your stakeholder to do so, and you'll build something that meets their actual needs. It's software development, not documentation development.