Сценарии использования: идеальный мост между требованиями и дизайном?

Представьте, что вам нужно объяснить, как должен работать ваш продукт, но без запутанных технических деталей и длинных списков функций. Именно эту задачу решил решить Ивар Якобсон в 1980-х годах, когда ввел концепцию "сценариев использования", или use cases. Вместо того чтобы углубляться в то, как система работает изнутри, он предложил описывать её снаружи, как будто это "черный ящик", акцентируя внимание на том, что она делает для людей и систем, которые с ней взаимодействуют. Это позволило разработчикам более четко и последовательно фиксировать требования, что стало основой для тех историй использования, которые мы используем сегодня.

Первоначально Якобсон назвал свои сценарии использованием "användningsfall", что в переводе с шведского означает "случай использования". Но это название не звучало удобно на английском, поэтому он сократил его до "use case". Эта методология быстро завоевала популярность в сообществе разработчиков программного обеспечения и стала доминирующим способом описания систем до тех пор, пока Agile не стал популярным в начале 2000-х.

Сценарии использования состоят из двух частей: диаграмм и нарративов. Диаграммы показывают общую картину взаимодействия "актеров" — пользователей или систем, которые взаимодействуют с вашей системой. Нарративы же описывают, как происходит это взаимодействие. Важно отметить, что в традиционной разработке программного обеспечения роли, такие как "Клиент" или "Менеджер", не всегда дают представление о потребностях и поведении пользователей.

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

Что касается нарративов, то они не имеют строгого формата, но Якобсон выделял несколько ключевых элементов: название сценария, актеров, цель, предшествующие условия, основной поток взаимодействий, альтернативные потоки и постусловия. Например, сценарий "Забронировать место онлайн" может описывать, как пассажир входит на платформу бронирования, выбирает место и получает подтверждение. Предшествующие условия — это то, что должно быть выполнено до начала сценария, а постусловия — это состояние системы после завершения сценария.

Важно помнить, что уровень деталей в сценариях использования должен соответствовать этапу процесса разработки. На ранних стадиях не следует углубляться в детали интерфейса, чтобы не ограничивать себя. Например, лучше написать "Сандра предоставляет дату вылета", чем "Сандра выбирает дату вылета из всплывающего календаря". Излишние детали на раннем этапе могут привести к "преждевременному дизайну", когда вы теряете гибкость и креативность.

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

Источник: https://www.interaction-design.org/literature/article/uses-cases-diagrams-narratives