Двадцать лет с юзкейсами: выжимаем практический опыт

https://habrahabr.ru/company/qiwi/blog/346438/

Юзкейс — это текст, 

описывающий сценарий (возможно, не один) 

взаимодействия (кого или чего?) с системой, 

приводящий (возможно, не приводящий) 

к значимому (для кого?) результату.

Вообще, при выборе информации для включения в юзкейс главным критерием должна быть легкость восприятия. Ради нее можно пожертвовать правилами, подробностью, иногда даже точностью. Главное — чтобы юзкейс был понятен с ходу. Если его трудно понять с ходу — это плохой юзкейс.

Не старайтесь запихнуть всё в один юзкейс. Разграничивайте их исходя из целей пользователей.

Бизнес-правила

Как сочетать лаконичность юзкейса с множеством деталей, которые обычно нужны, чтобы спроектировать пользовательский интерфейс и разработать код? Для этого я сопровождаю юзкейс списком бизнес-правил, которые должны учитываться при реализации сценариев.

Одно из центральных понятий в теме юзкейсов — это «рассматриваемая система» (SuC, System under Consideration, или SuD, System under Development). Согласно классическому подходу, есть система, которую мы разрабатываем, и у нее есть граница. Всё во Вселенной делится на то, что внутри системы, и то, что вне ее. И мы рассматриваем исключительно такие взаимодействия, которые идут через границу системы. Зная, что на входе и на выходе мы можем решить, как оно должно работать внутри.

Сказуемое без подлежащего

Время от времени в сценариях приходится встречать такие фразы: «данные сохраняются в БД», «пользователю отправляется СМС». Не бывает действий, которые выполняются сами по себе. Их всегда выполняет кто-то или что-то.

Я полностью согласен с рекомендацией Коберна о структуре предложений в сценарии. Каждый шаг юзкейса должен начинаться с подлежащего — кто или что выполняет действие. Затем сказуемое — какое действие. Дальше всё остальное. Сказуемое должно быть в настоящем времени и в действительном залоге. «Пользователь выбирает населенный пункт», «Приложение показывает список товаров». 

Пробежав глазами начальные слова шагов, легко собрать список участников. Я предпочитаю не выписывать отдельно список участников в начале юзкейса, это тормозит читателя и мешает ему скорее перейти к чтению сценария.

Неуспешные сценарии

Иногда в проектах забывают предусмотреть случаи, когда что-то происходит не так. К примеру, клиент совершил покупку, а потом захотел ее вернуть. Если об этом не подумали заранее, то приходится срочно допиливать код после запуска. А в тяжелых случаях — выбросить всё и организовать взаимодействие систем в другом порядке.

Техника юзкейсов помогает (хотя и не гарантированно) избегать подобных осложнений. Написав основной сценарий, подумайте: что может пойти не так на каждом из шагов? Что может случиться в другом месте после того, как здесь всё уже закончилось? Каждый найденный вариант отклонений нужно выписать, для начала хотя бы одной фразой. Потом, если потребуется, проработать по шагам.

Если в проекте описаны только основные сценарии юзкейсов, велик риск, что вы забыли что-то важное.

Модель предметной области

Юзкейсы должны опираться на модель предметной области, которую все участники проекта понимают одинаково. Вспомним первый шаг нашего примера: «Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки)». В одном пункте употреблено пять понятий. Некоторые из них новые, возникли только в этом проекте. 

Самый известный инструмент введения в предметную область — глоссарий. Следует включать в глоссарий только те слова, которые кому-то могут быть непонятны. Если начать объяснять всё, то после первых трех пунктов читателю станет скучно и он закроет глоссарий, не добравшись до важного. 

Можно писать краткие статьи, объясняющие новые понятия. Вот пример — выдержка из документации всё того же проекта:

Еще один классический способ описания модели предметной области — диаграммы «cущность-связь» в формате IDEF1 или статических структурных диаграмм UML.

В одном недавнем проекте я на таких картинках по часу в день, в течение двух недель, излагал команде разработки модель предметной области. В результате у всех разработчиков была единая картина понятий, что нам очень помогло в ходе проекта.

Теперь я могу вам объяснить, почему юзкейс-диаграмма осталась для меня непонятной при первом знакомстве с UML. Дело в том, что все другие диаграммы UML моделируют систему, они показывают ее нам в разных «ракурсах». А юзкейс-диаграмма иллюстрирует не саму систему, а набор функциональных требований к ней. Юзкейс-диаграмма, следовательно, — модель модели. Не так просто было сразу это понять.

Заключение

Юзкейсы — уже довольно старая методология. За 20 лет появились новые подходы, которые потеснили методику юзкейсов в тех областях, в которых она когда-то была лучшей. Например, юзер стори позволяют более эффективно управлять требованиями в Agile-проектах. Методы дизайна пользовательского опыта помогают разрабатывать продукты, успешные на рынке. На мой взгляд, сегодня в сравнении с более современными методами юзкейсы находятся примерно в том же положении, какое в свое время занимали блок-схемы по сравнению с юзкейсами. Старые добрые блок-схемы — теперь диаграммы Activity в UML — используют до сих пор. Но когда-то они считались универсальным способом проектирования и описания программ, а потом их применение сузилось с появлением методик таких как Use Case, UML, BPMN. 

Тем не менее юзкейсы и сейчас остаются хорошим инструментом анализа, особенно для систем, поддерживающих бизнес-процессы. Любой аналитик или проектный менеджер должен знать методику юзкейсов и уметь ее использовать. Об этом, собственно, и мой пост.