CODEWITHSUNDEEP
umluse-caserequirements
Ihsan Ramli
Ihsan Ramli

Reputation: 91

How to define effective use case?

I'm trying to define use cases for my project. The problem is I'm not sure how to effectively define a use case, and it looks very messy.

For example like my use case below. I feel like 'View profile', 'View Club' 'View Workshop' is necessary to include because of 'common sense' for user to click on certain profile to view it. So do I really need to define such use cases?

Car Club Use Case

Upvotes: 0

Views: 101

Answers (2)

Vlad
Vlad

Reputation: 497

You need to define all the cases necessary to achieve your goal. Generally speaking if there is something important in 'View Workshop' to have it on paper or to pass it to someone - you have to write it.

Ihsan Ramli, while your problem is "I'm not sure how to effectively do %something%" and assuming that you can't give the task to someone else - why not to learn more about it? You can start from couple of widely recommended books, for example Writing Effective Use Cases by Alistair Cockburn.

Sentences like "because... for user to click on certain profile to view it" immediately light a red bulb since use cases represent behaviour requirements and are detached from implementation and design (but can and should refer to them when necessary).

Some comments about your diagram:

  1. 'Create club' (along with 'Delete club', 'Change club name') would look better as a use case one goal level lower and triggered from summary scenario 'Manage club'.
  2. 'Manage workshop' is probably missing for its owner.
  3. Name 'Update item' tells nothing to reader.
  4. 'Join club' would probably look more reasonably triggered from 'View club'.
  5. I don't believe that appointments for workshop and repair have a lot in common to be the same scenario.

Upvotes: 0

qwerty_so
qwerty_so

Reputation: 36295

Yes, synthesizing use cases is difficult. And often people try to depict functional parts using lots of include/extend to show the system under consideration. But actually use cases are not about functionality. They are about added value. So if you sit down a moment and think which of those bubbles really represent added value, you will find that Request repair service, Make appointment and Manage club are real candidates while most of the others are just technical paraphernalia. Manage <x> is a bit of a borderline. I'd eventually use CRUD here, that's 4 use cases, since they are used in different contexts and often different actors. When you synthesize use cases just ask yourself: does it add value. Only if the answer is yes, add this as use case. Else you have some technical sequence of actions or even simpler a constraint (like for Login).

Upvotes: 2

Related Questions