What you are describing are use cases (use case documents and diagrams included). User stories are a step after the stakeholders and the developers signed off on the use case documents.
User stories are generally speaking just there for the developers. If a stakeholder is interested in a user story for some reason, you can show him the relevant use case document.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
Use Cases are also a good tool for mapping the Requirements into Specifications, I totally agree with that. However, Features and the Gherkin DSL provide a uniform syntax and a standardised way of verifying the Specifications, through a number of tools such as Cucumber, Specflow, etc. For that reason, I prefer using Features over Use Cases.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What you are describing are use cases (use case documents and diagrams included). User stories are a step after the stakeholders and the developers signed off on the use case documents.
User stories are generally speaking just there for the developers. If a stakeholder is interested in a user story for some reason, you can show him the relevant use case document.
Hi Slava and thanks for the feedback.
Use Cases are also a good tool for mapping the Requirements into Specifications, I totally agree with that. However, Features and the Gherkin DSL provide a uniform syntax and a standardised way of verifying the Specifications, through a number of tools such as Cucumber, Specflow, etc. For that reason, I prefer using Features over Use Cases.