User Stories - I feel are excellent ways to capture high level Business requirements. They may be enough when team are collocated and you actually have all stakeholders working from same location and interaction is not limited.
But the situation when you have multiple teams working and offshore teams working in varied time zones it makes sense to further detail out requirements using Use Cases. The mapping can be one to many-
So when the user story details out 'As an {User} I should be able to perform {task} so that is {Business objective} is achieved', the use case for the same user stories will take the requirement to next level :
- [Description of Use Case] ->From User Story
- [Actors] - >form User Story
- [Pre Condition] - >Not Covered in User Story
- [Post Condition]-> Not Covered in User Story
- [Basic and Alternate Flow] -> Not Covered in User Story
- [Assumptions] ->Not Covered in User Story
- [Exception]->Not Covered in User Story
- [Implementation Notes]-> try writing this section where the discussion from Architect and dependencies from other teams /system can be noted down
This helps a lot in saving a lot of communication time across team both at Onsite and Offshore. It also serves as a solid artifact to create unit leve test cases and where the combination of user stories can be used to create higher level integeration test cases.
The point I am trying to make is that Use Case and Use Stories are not mutually exclusive, they go pretty much hand in hand.
