During system development, how do you get from the abstract vision (see method in the book) and the goals of the system to the concrete requirements, which are, for example. be formulated as user stories (see User Story Map in the book)?
A practical method to bridge the gap between the two is use cases. These specify high-level functional requirements that describe what specific actors want to do with the system.
A use case diagram usually visualizes the following aspects:
– The system and its boundary to the environment (represented as a rectangle)
– The use cases (represented as Circles resp. Ellipses)
– The actors (represented as stick figures) and neighboring systems (represented as stick figures or cylinders).
The system environment with external systems and system boundaries is also analyzed in more detail in so-called context diagrams, but in practice these two diagrams overlap a bit. When looking at the use cases, it is also worth taking a look at the third-party systems and system boundaries.
So with a use case diagram, you immediately gain a quick and easy overview of the most important functions of the system and who they come from. It also forces us to think in a user-centric way, as the use cases come from the users (or neighboring systems). From the individual use cases, one can then in turn derive more detailed requirements up to and including user stories.
It should be noted, however, that the use case diagram mainly answers the question of “what?”, i.e., what functions the system provides. In order to visualize process flows, one can, for example. use the SIPOC diagram (see book method).
