A Вариант использования должен генерировать бизнес-ценность . Является ли «вход в систему» (или получение доступа и т. Д.) Самоценным? Будет ли пользователь системы авторизоваться , а затем оставить все как есть? Возможно нет. Следовательно, логин не сам по себе. Это может быть задокументировано как шаг в прецеденте (если вы достаточно знаете о решении и хотите сказать), но будьте осторожны, чтобы не указывать технологические решения в прецедентах. Вам лучше указать, что пользователь должен быть идентифицирован для определенного уровня аутентификации, и применить его в качестве предварительного условия и т. Д.
Бизнес-ценность является ключом. Признание ценности бизнеса является частью искусства и науки анализа. Например, то же самое будет верно, если вы не использовали варианты использования для моделирования требований, например Пользовательская история в форме «Как (роль), нуждающаяся в (действии), чтобы (бизнес-ценность)» снова ориентирована на бизнес-ценность. В конечном счете, ценность бизнеса - это фокус любого функционального требования, и четкое определение этого должно быть одним из основных показателей, который ваш анализ приближает к своей цели.
Это на уме - последовательные и функциональные зависимости. Будьте осторожны, чтобы не разбить функциональность системы на блоки, которые не отражают ценность для бизнеса. Часто цитируемый пример банкомата: Check Balance - это вариант использования, Введите PIN - нет (по причинам, указанным выше). Однако вы, возможно, захотите всегда Проверить баланс при выполнении Снятие наличных . Если это так, то вы можете использовать include , чтобы показать, что Снять наличные включает Check Balance , но обратите внимание, что оба варианта использования обеспечивают бизнес-ценность в и самих себя.