«Необходимо» зависит от того, какой аспект вы пытаетесь задокументировать, но я бы сказал нет.
Если вы находитесь в фазе спецификации (разработка варианта использования), я обычно советую вообще не использовать диаграммы состояний; Я считаю, что мероприятия лучше подходят для этой цели. Диаграммы состояний, на мой взгляд, лучше подходят для описания дизайна.
Это потому, что действия сосредоточены на самом потоке и, таким образом, описывают что-то с внешней точки зрения, тогда как диаграммы состояний описывают внутренний поток, в котором некоторая определенная сущность перемещается между различными состояниями.
Когда вы составляете диаграмму состояний, вы должны ответить на вопросы «что это за состояние, которое имеет состояние? и "что каждый штат значит для вещи?" (Замените «вещь» на «часть системы», если хотите).
В вашем случае я бы предположил, что именно пользователь (строго говоря, учетная запись пользователя) имеет состояние, а не система.
Непонятно из вопроса, каков сценарий, но если мы говорим о типичной учетной записи пользователя ОС, она, вероятно, должна иметь такие состояния, как «Вышел из системы», «Вы вошли в систему», «Истек срок действия и заблокирован».
Если вы действительно хотите смоделировать системную сторону, то вам, вероятно, следует разбить ее на меньшую часть, такую как пользовательский клиент (или терминал, или что-то еще). В соответствии с вышеизложенным, ключевой вопрос заключается в том, «ведет ли (целая) система себя по-разному, когда пользователь вошел в систему?» и, вероятно, это не так. Пользовательский клиент, а не вся система, будет иметь список состояний, которые вы перечисляете.
Но при прочих равных условиях я бы сказал, что диаграмма состояний, описывающая цикл входа / выхода из системы, должна фокусироваться на учетной записи пользователя.