UserStories + AcceptanceTest''''''s are basically the same thing as a UseCase.

	* UserStories have a name (the story); UseCases have a name.
	* UseCases have pre-condition/post-condition clauses; AcceptanceTest''''''s have setup and checks.
	* UseCases have steps; AcceptanceTest''''''s stimulate the system and then verify that certain steps have occurred.

How do extensions and variations fit in?   They are either additional AcceptanceTest''''''s or additional stories.  Does it really matter as long as we know the system handles it?

UserStories + AcceptanceTest''''''s can be looked at as executable UseCases.  Sounds like something good to have your case tool do.  The
AcceptanceTest''''''s bring UserStories to the engineering level.

Another realization I had is that if you do UseCases and automated AcceptanceTest''''''s you are essentially doubling your work.  There is duplication between the UseCases and the AcceptanceTest''''''s.  I think there is a good case to be made that UserStories + AcceptanceTest''''''s are more efficient way to work when compared to UseCases + AcceptanceTest''''''s.

You could try to prove this to yourself.  Go ahead and use UseCases, but automate your AcceptanceTest''''''s.  The automation must be done to a level that your customer can understand the AcceptanceTest''''''s.  You might see the duplication that I saw. 

--JamesGrenning on the XpMailingList

''How do you run a Use Case?  A use case is a picture not a test.'' <-- UseCase is not a picture. UseCase is a text.

Could UseCases incorporate tables to be fed to a runner for the FrameworkForIntegratedTest?