CODEWITHSUNDEEP
umlmodelinguse-caserequirementsuse-case-diagram
KijeviGombooc
KijeviGombooc

Reputation: 342

What counts as functional requirement and what doesnt in the following example?

For my homework, I have to write functional requirement of a game called downfall (see Wikipedia). We have to make this game, but with not two sides but n (any number of) sides.

In an example solution (another game), the teacher writes the functional requirements, then writes what use case they belong to.

I have created a use case diagram in which I have the player as an actor, and ChooseDial, RotateDial and EndTurn as use cases:

enter image description here

What I dont understand are the following: Is the number of players functional requirement? Is the table having two sides a functional requirement? Is the goal of the game (getting coins from top to bottom) a functional requirement? Is a rule like coins must reach bottom in order a functional requirement?

If they are, what use case could they belong to? Is my use case diagram wrong?

I have no idea where to put these functional requirements, because I feel like they arent part of any of my use cases.

Upvotes: 1

Views: 772

Answers (2)

Christophe
Christophe

Reputation: 73366

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:

enter image description here

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 *).

Upvotes: 3

qwerty_so
qwerty_so

Reputation: 36295

Requirements management (RM) can be tricky indeed. A requirement like The board must have two sides seems to be more involved in the design, rather than the use case. In such cases you could relate that to the boundary rather than a single use case. That will indicate it's some "global" requirement (similar to a non-functional requirement). Usually in a project you start with a more or less strange mix of requirements mixed in user stories. The business analyst (BA) has to comb that information and come up with decent use cases (synthesize the added values). The system architect (with the BA) will then go through requirements and use cases to come up with a (business) class model.

There are tons of books and procedures describing RM. Lots of seminars too. I think if you grasp the condensed idea above you're ready to start. It's a marathon to start...

Upvotes: 0

Related Questions