There is often confusion in the mind of the business analyst about the need for or application of user stories and Use Cases, especially if the organisation hasn’t been exposed to these tools and techniques in the past.
User stories (syntax: as a <who>, I need to <what>, so that <why>) are useful to define the boundary of a functionality such that the required functionality can be designed, developed, tested and deployed. A good user story can improve tractability when properly aligned with the wider business requirements. Developing user stories is not difficult but, all too often, is done badly or, worse, is not done at all! The business analyst could set up a workshop with the project team to chalk out the bare bones of a few stories from the requirements such that each one of these is a small piece of functionality in itself that can be delivered independently. The idea is similar to divide and rule. Instead of putting the whole cake in the mouth, we cut it to small pieces that can be chewed
User stories are different to use cases – there are dozens of Use Case templates available using a Google search. As long as the business analyst understands the logic and purpose of the Use Case templates the concepts are not too difficult to grasp. A Use Case may be or relate to a collection of user stories and will describe the triggers, actors, preconditions, flow of events (primary, alternate and exception) and the post-conditions (or outcomes). A good user story moves the focus from writing about features to discussing them.
Frequently the business analyst (or even other stakeholders) may be writing use cases or user stories right now and unaware that they are doing so. At the end of the day, user stories and Use Cases do not have a structure the first time you write them down (even if they do, they will rarely be right first time). That’s where the conversation comes in.
When looking for user stories and Use Cases the business analyst must consider the whole organisation as an open and adaptable system. The environment interacts with the organisation and to best understand that interaction Use Cases and user stories are the best tool for communication of requirements to stakeholders.
Being a good business analyst is much more than any way of documenting the requirement. If you are able to express why a certain change is needed and what’s the desired business outcome and then collaborate with business users and the development team to come up with the right solution, then learning a new way of presenting the requirements is not a necessary solution. Where these two techniques/tools come into their own is when you are struggling to communicate the business requirement to stakeholders, be they the business or the developers or testers. In my experience use cases can end up being more solution central (especially if “the system” is portrayed as an actor) whereas user stories accompanied with acceptance criteria are a neat way of expressing solution neutral requirements.
Crucially, as long as the systems analyst can understand what is needed and the business is happy with the outcome, then the how is not really important. Don’t agonise over methodologies and forget the no 1 thing – listen to and understand what your customer wants (of course strictly speaking that’s a no 1 and a no 2 thing to ensure that the requirement is binary!). If in doubt, try it, see if it adds value and move on.