Usecases

-> description of different usecases, which as a whole should cover all the functionality of the system
-> illustrates the mechanisms from a user centric perspective, later used for automated integration tests
-> one usecase could be seen as a path of a user through the system, which contains several steps
-> several paths may belong to a certain workflow
-> the description of an usecase should be a numbered list of the performed steps for a path
-> the description may be assisted with a flowchart / workflow chart, if helpful
-> an useful usecase could be a path combining all actions of a controller
-> there's no need to describe a certain subpath more than once

== Usecases ==

=== Basic User Actions ===

  1. an anonymous visitor enters home
  2. anonymous browses to some accessible sites (home, legal, ...)
  3. anonymous browses to a non accessible site and is redirected to home
  4. anonymous browses to contact and sends a complaint about the navigation to administrator
  5. anonymous browses to user registration, registers as a user with an already existing email and gets an error
  6. anonymous registers with a valid emailadress and recieves a mail
  7. anonymous browses to a wrong email validation url and gets an error
  8. anonymous browses to the right email validation url, is now user and being redirected to user dashboard
  9. user browses to some accessible sites
  10. user browses to a non accessible site and is being redirected to user dashboard
  11. user logs out, is now anonymous and is redirected to home
  12. anonymous logs in again, is now user and being redirected to user dashboard
  13. user browses to profile and changes some values
  14. user browses to user settings and changes some values
  15. user deletes account, is now anonymous and being redirected to home
  16. anonymous tries to log in as user and gets an error

=== Payee of Artist ===

  1. user creates a new band
    1. user enters metadata
    2. user adds himself (bandmember1) and invites three other bandmembers
    3. bandmember1 proposes bandmember1 as payee
  2. all other bandmembers accept bandmember1 as payee, bandmember1 is now dismissable, no bandmember is proposable
  3. bandmember1 recieves a confirmation pdf, bandmember1 has no access to transaction mechanisms
  4. assumtion: bandmember1 has sent signed confirmation to administrator
  5. administrator confirms bandmember1 as payee, bandmember1 has now access to transaction mechanisms
  6. bandmember2 dismisses bandmember1 as payee, bandmember1 has no access to transaction mechanisms anymore, all bandmembers are now proposable
  7. bandmember2 proposes bandmember2 as payee
  8. bandmember3 does not accept and proposes bandmember4 as payee
  9. all bandmembers accept bandmember4 as payee, bandmember4 is now dismissable, no bandmember is proposable
  10. bandmember4 recieves a confirmation pdf
  11. assumtion: bandmember4 has sent signed confirmation to administrator
  12. administrator confirms bandmember4 as payee, bandmember4 has now access to transaction mechanisms
  13. ... 2do: different cases! flowchart? event mails sent (is now payee, is dismissed, etc.)?

== Unsorted List ==

-> to be sorted, elaborated, combined into workflows/usecases

=== Artist Types ===

  • soloartist
    • self administrated (defines an agent / adminstrated by agent)
  • band (soloartist as bandmember)
    • self administrated (all bandmembers should be allowed to access and change data of band / change of data may / defines an agent)
    • adminstrated by agent
  • coverbands
  • bands of bands (bands as bandmember)
  • orchestra

=== Claim Mechanisms ===

''not a usecase yet, but could be included in another''

  • object does exist already in our database, user wants to claim affiliation
    • user
    • artist
    • creation
    • bank_account

=== Delete Mechanisms ===

''not a usecase yet, but could be included in another''

  • user deletes soloartist, which is member of several bands

== Links ==