User stories are great for describing product features as well as the smaller components that make up that feature. The objective described in the story can be used to prioritise easily.
Modelling the more detailed user/system conversations will require different tools (acceptance criteria, acceptance tests). User stories are text so I would expect visual models to be used in addition to describe various interactions (Activity diagrams etc).
Your user stories should be laid out using epics an themes. These would help in creating a high-level overview of how the user stories tie together. Also, I was recently charged with creating a template for an Agile Functional Specification Design Document. This, of course, isn't traditional, but the operational side of the company I work for requires a document to sign-off when it comes to requirements. I created the document to be reminiscent of the waterfall doc, with the project overview and project scope, but I also have a section where each Sprint and the user stories that were completed in the Sprint are documented. This allows for a formal sign-off from the stakeholder, which is the only part of the waterfall methodology that I liked, along with the full team approach you get from agile/SCRUM.
In my experience US are an easy way to describe functional requirements in an Agile process, and if you've a functional requirement to describe that's the best way to do it. Possibly you should NOT use US if you're using a non-Agile process (waterfall) because in that case I'd probably use a more formal approach with Use Cases. Both tools are similar but in Use Cases you've diagrams which are not used in Agile processes (like Scrum) because not an Agile priority.
If you're interested to Agile development for BPM, pls have a look at this special offer for an Udemy course on IBM Blueworks. (offer expires next Mar22).
thanks
I'm currently working on a project where we are just getting going with user stories.
These are ein the form of As a user I want to...
The acceptance criteria is where we are capturing the NF req's. These are written in GHERKIN form.
GIVEN the user has done something
WHEN something happens
THEN this should happen within ???
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: