2 comments

  1. At the first reason you give the actor should be the person who is hitting button. If the button only works between a certain time that could be a precondition of the use case.

    My personal opinion is that timer or scheduler are more technical terms that are difficult to understand by the users who are reading the use cases. Therefore I like the possibility of using “Once every month” and “Every day at midnight”, but these have the disadvantage that if the time constraint of the event changes so will the name of the actor.

    Alex van Assem

  2. Problem with buttons is that they aren’t there at the time the Use Case is written. But I understand the direction. A scheduler in my perspective is not technical at all. It’s someone or something that is responsible of scheduling tasks that need to be run and making sure they do at a certain time. It leaves it in the middle which of the two this would be.

    I now wonder if we should still use an actor for triggering the Use Cases. It’s only triggering a Use Case and has no interaction what so ever. Maybe we should leave the actor aside and create a list of system or “world” events which would trigger the Use Case.

    Like this:

    Use Case A is triggered at twelve o’clock midnight.
    Use Case A is triggered at the last sunday of the month.

    gijsd

Comments are closed.