The people involved in requirements elicitation have to learn and to communicate continuously. If you have read the Quick-start Guide, you saw how Domain Storytelling helps to learn domain language and to reach a shared understanding. Sometimes, this is all that development teams need to jump directly into code. However, usually jumping from scenarios to code is a bit too challenging, and you need to bridge the gap between domain knowledge and requirements.
You can derive requirements from domain stories so that you can discuss priorities and viable products.
From Domain Story to User Story
In our movie theater example, Matthew and Anna discuss how the sales process at the box office will work in the future. They realize that the cashiers need a digital seating plan that also shows the seats sold via the app. If a moviegoer wants to buy tickets at the box office, the cashier searches for the seating plan for the show and offers the available seats. This activity must by supported by a new system:
“As a cashier, I want to search for available seats for a show so that I can offer them to a moviegoer.”
A Tool for Many Different Roles
Domain Storytelling is a helpful tool for anyone who works with requirements, whether as a product owner, product manager, business analyst, requirements engineer or cross-functional team that does its own requirements elicitation. They can all use it to…
- find out what is expected of a piece of software and
- understand the context of requirements.
Chapter 11 of the Domain Storytelling book describes a recipe for breaking down domain stories and building a backlog of requirements with User Story Mapping.