About requirements
First, let's handle the requirement question:
- A functional requirement tells something about what a software shall do. Everything related to goal, the gameplay or the rules of the game, is a functional requirement.
- A non functional requirement tells something about how the software shall be, for example how accurate, how performant, how easy to use, how easy to maintain. Your narrative shows no such requirements.
About use-cases
Use case driven software development methods start with the high-level user's goals that are captured in use-cases. Personally, I see only one such goal:
Very rare usage: a multiplicity on the actor side of the use case. This says that 2 or more instances of players are involved in an instance of the use case. Of course, this makes sense only for the game as a whole, not for individual actions (like you have in your diagram).
In your diagram, you have shown 3 use cases:
- is
EndTurn
an independent goal that the user may freely decide to chose ? No ! It's what always follows a player action. So this is definitely not a use case.
- you say that
RotateDials
extends ChooseDials
. This means that a player could ChooseDials
but not rorate it. Is this a valid scenario ?
- if on the other hand you'd say that
ChooseDials
includes RotateDials
, the latter would always happen. But then, wouldn't ChooseDial
not be more than just choosing a dial ? Shouldn't it then be called PlayTurn
?
I could understand that for learning purpose, you'd want to decompose the Play game
in more detailed use-cases. Typically, once the players try to reach their goal Play game
, this might include sub-goals of Play turn
. As long as it is goal-oriented, and not too detailed, this is ok. But do avoid simple functional decomposition (it doesn't help for being more user-driven, and use-cases are not functions ). And, above all, do not misuse a use-case diagram for trying to show a sequence of activities.
Requirement traceability
The use cases do not capture the full requirements. It captures the most enssential thing: the purpose of the system and the user goals.
When writing down the requirements, it's then useful to get guided by the use-cases and their narrative, and to trace-back every use-case specific requirement.
But of course, there are some general requirements as well. These are not specific to a particular use-case. Some are even common to all use case. Mark these as general requirements (e.g. use case *
).
Play Turn
or evenPlay Game
– Geert Bellekens