Что такое юзер кейс

Как и зачем писать Use Cases

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.

Кому и в каких случаях нужны сценарии

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

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс 🙂

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

А также другим участникам процесса.

В каких случаях они нужны:

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

— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

Пример 2. Авторизация пользователя:

Успешный сценарий:

Важные моменты

— Очевидно, что если Пример 1 можно было безболезненно описать простым текстом, то Пример 2 намного лучше воспринимается в виде сценария. Но если у вас вся функциональность описана в виде юзкейсов, то лучше описывать юзкейсами даже очень простые сценарии, из пары шагов. Пусть ваша спецификация будет в едином стиле.

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

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

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

— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Источник

Что такое use case? Теория и примеры

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

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

В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

Как написать use case?

Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:

Пример use case

В этом юзкейсе изложен сценарий входа пользователя в школьную систему.

Юзкейс-диаграммы

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

Пример диаграммы для юзкейсов входа в школьную систему:

Зачем нужны use case?

Давайте рассмотрим, в чем ценность юзкейсов для участников проекта разработки ПО.

В юзкейсе отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования в системе очевидна даже для нетехнического специалиста. Наличие готового use case позволяет заказчику своевременно дать старт дальнейшей работе тестировщиков и разработчиков.

В сценарии использования указываются основной и альтернативные потоки событий. Вся информация в нем подается максимально структурированно и понятно, в привязке к конечному результату. Это удобно для понимания запутанных требований. Если сценарий поведения пользователя в системе сложный, use case просто необходим.

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки, которые сложно найти, например, при юнит-тестировании.

Источник

Юзеркейсы: что это такое и как их писать, чтобы вам поверили

Практика показывает, что продать текстом финансовые услуги гораздо сложнее, чем швабры. Но правильно составленный юзеркейс может и то, и другое. Наш автор Саша Ежова (признанный мастер юзеркейсов) составила подробный гайд для внутренней редакции агентства, как писать достоверные пользовательские истории. Здесь публикуем его в сокращенном виде и с примерами.

Это история от первого лица, герой которой рассказывает о своем опыте покупки и использования каких угодно продуктов или услуг – начиная от кредитных карт, заканчивая онлайн-кинотеатрами и квартирой от конкретного застройщика. Что делать, если у вас нет такого опыта? Это не проблема и нет, обманывать никого не придется. Для убедительного и честного текста нужно будет только собрать «жирную» фактуру.

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

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

Важно: опыт людей не обязательно будет на 100 % совпадать с темой материала. Это значит, что фактуру придется еще доработать с учетом информации из брифа.

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

Нырните во всевозможные форумы и читайте отзывы пользователей. Это особенно помогает при изучении каких-то сложных продуктов. Однажды я писала для застройщика, и герой должен был описать плюсы и минусы одного из ЖК. Вот, например, один из плюсов, на который меня вдохновил отзыв с форума:

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

Позвоните в компанию под видом клиента. У того же ЖК на сайте указана возможность онлайн-бронирования квартир: описано, как это сделать, ниже – форма, но непонятно, что именно это дает покупателю (то есть нашему читателю). Такие детали обязательно стоит уточнять и объяснять в тексте.

Вот как это подали мы в статье от лица Паши, руководителя отдела разработки в одной крупной IT-компании:

Не забывайте подписывать картинки и скриншоты — да, вообще все, даже самые, казалось бы, очевидные. Это дополнительный и важный способ коммуникации с читателем.

Объясняйте, почему герой принимает то или иное решение. Здесь я говорю о сторонних вещах, которые тоже нужно пояснить. Помните, я искала плюсы ЖК? Так вот, нашелся еще один на очередном форуме по недвижимости.

Вот так было бы плохо:

А вот так уже хорошо:

Пишите практически так же, как говорили бы вслух (в рамках разумного) или писали в социальных сетях. Да, даже в самых серьезных юзеркейсах допустимы такие слова и словосочетания, как «ноут», «капец», «я в шоке», «я психую», «смотрю киношку» и так далее.

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

Здесь я упростила слова и добавила боли в мире читателя – про тот же мусорный бак и удаленку.

Старайтесь сохранять примерно одинаковую стилистику всего текста. Перевоплотитесь в героя и представьте, как он говорит в жизни. Вы ведь, когда смотрите сериал, не ожидаете, что доктор Хаус в следующей серии вдруг станет вежливым и больше не будет остроумно шутить? Вот-вот.

Подумайте над акцентом в начале. Можно сделать автора центральным героем, а можно пойти от проблемы читателя и только потом представить героя. Если вы ставите автора в центре повествования в какой-то серьезной теме, сначала нужно подкрепить его авторитет. Например, вот так мы начали один из юзеркейсов для сервиса Финолог:

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

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

Придумывайте заголовок после того, как написали текст. Не пытайтесь глядя на пустой белый экран сразу придумать привлекательный заголовок — получится «без жизни» и, скорее всего, без важной конкретики. Сначала напишите разные УТП, потом приплюсуйте к ним эмоциональные акценты и интригу. Вообще лучше максимально уходить от метафорических заголовков, которые без контекста не понятны. Заголовок типа «Занимательная история» при беглом просмотре читателю ничего не говорит — он в интернете за день видит примерно 5–10 занимательных историй. Почему именно эта должна его заинтересовать?

Вот неплохие варианты заголовков:

Здесь многое зависит от специфики текста, но если есть возможность и желание сделать юзеркейс более качественным, то вот, что можно сделать:

Фотографируйте детали в мире читателя, но не перебарщивайте. Подумайте, какие возможности сервиса клиенту интересно увидеть. Можно фоткать телефон или ноутбук со стороны, если в распоряжении есть другой смартфон или камера. Например, вот одна из фоток для приложения по фитнесу. Специально публикую в связке с текстом:

Или вот условия, в которых 90 % людей занимаются спортом дома. При этом у меня есть свободная большая комната, где можно сделать более приличные фото:

Будьте героем сами. Здесь поможет муж, жена, штатив, коллега или собственная вытянутая рука.

Нам важно, чтобы читатель себя узнал. Не забывайте, что это юзеркейс, а не продуктовая статья. Фотки не должны быть правильные, вылизанные, но и в трешак скатываться не стоит. Я просто прогоняю их через фильтры VSCO, убираю лишние детали в Snapseed.

Кстати, вот что значит скатываться в трешак:

Мы закрыли лицо картинкой — нам лишь важно показать, как делать не надо. В таком случае вы зря тратите прежде всего свое время. Что здесь не так:

фото сделаны при плохом освещении, все в шумах;

А вот хорошие примеры нескольких самостоятельных фото для этого же юзеркейса, но уже от лица девушки (меня).

Источник

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

У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.

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

Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.

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

Дело в том, что автоматизация бизнес-процессов там была реализована на изолированных десктопных приложениях с изолированными же базами данных. Вплоть до того, что учет абонентов-физлиц и расчетов с ними был в одной БД, а учет корпоративных абонентов — в другой. И нигде не было, например, пула свободных телефонных номеров. Стояла задача всё это объединить в единую учетную систему для всех услуг. То, что сейчас называют «биллинг».

Я не знал, как начать формулировать требования к такой большой системе, и стал искать подходящий способ. Наткнулся на спецификацию UML версии 0.9, которая тогда только что вышла. В полном восторге, с горящими глазами, прочитал ее от корки до корки. Мне всё дико понравилось, я понял все схемы UML и как ими пользоваться. Кроме одной: диаграммы Use Case. Было непонятно, что это, зачем она и как ее применять. Ниже объясню, почему так произошло.

Проблему биллинга в конце концов решили — купили у стороннего вендора, потом несколько лет внедряли. Но я к тому времени уже был далеко. Юзкейсы писать тогда так и не научился и, в общем, не ощущал особого дискомфорта.

В 2004 году я пришел работать системным аналитиком в одну из больших аутсорсинговых компаний, где состоялось мое настоящее знакомство с юзкейсами. Стандартом разработки там был Rational Unified Process, все функциональные требования во всех проектах полагалось формулировать только в виде юзкейсов. Это, конечно, радикальный подход, мне он и тогда казался странным, а теперь я точно знаю, что так нельзя. Но тем не менее, прослушав пару тренингов и прочитав Коберна, я разобрался в методике и стал ее применять. С тех пор юзкейсы — мой любимый инструмент анализа и разработки требований.

Что такое юзкейс?

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

А вот определение из глоссария UML (перевод мой).

Юзкейс — это описание набора последовательностей действий системы, в том числе вариантов таких последовательностей, в результате которых получается наблюдаемый результат, который обладает некой ценностью для кого-то из участников процесса.

Какое определение я сам стараюсь держать в голове, когда пишу юзкейс? Оно должно мне подсказывать, что я должен сделать, о чем мне надо не забыть написать:

Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.

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

Юзкейс — это текст,
описывающий сценарий (возможно, не один)
взаимодействия (кого или чего?) с системой,
приводящий (возможно, не приводящий)
к значимому (для кого?) результату.

Такое определение говорит мне, что из описания юзкейса должны быть понятны:

Установка курсов для пользователей QIWI Кошелька

Что не нужно в юзкейсе

Коберн не скрывает, что его любимый формат юзкейса — Fully Dressed (как это по-русски, расфуфыренный?). Помимо основного и альтернативных сценариев в него включаются разделы:

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

Вы скажете: ну как же, вот у тебя написано, что директор получает уведомление по электронной почте. А почему не по SMS или каким-то другим способом? Потому что мы с пользователями на тот момент уже согласовали вариант с e-mail-ом. Если бы я написал абстрактно, то у них возникло бы недоумение: как так, разве мы не решили, что это будет e-mail? Что-то изменилось? Описав пользовательский интерфейс чуть более детально, чем полагается по методике, я позаботился о читателе, чтобы он не споткнулся, читая юзкейс.

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

Что еще отсутствует в приведенном примере? В нем нет ничего о том, как курсы передаются из АБС в процессинговую систему QIWI Кошелька. Потому что это предмет другого взаимодействия и другого юзкейса. Если из-за какого-нибудь сбоя курсы не дойдут до процессинга — это не забота трейдера. Для него результат достигнут: курсы назначены и утверждены.

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

Условные конструкции

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

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

Сценарий установки курсов

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

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

Вот какие бизнес-правила были приложены к юзкейсу из примера.

Следует всегда внимательно оценивать, какие детали стоит включить в сценарии, а какие — вынести в список бизнес-правил.

Когда систем несколько

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

Этот подход можно назвать «одноклеточным». Мы сосредотачиваемся на том, что происходит в клеточной мембране, и игнорируем до поры до времени всё остальное.

Но в реальности мы живем в многоклеточном организме. У компании много систем, они взаимодействуют между собой и совместно реализуют множество функций бизнеса. Почти в каждом проекте мы должны удовлетворить очередную потребность компании через внесение изменений, по возможности минимальных, в несколько систем.

У Коберна такое предусматривается, там есть вариант «организация — прозрачный ящик». Но у него об этом как-то вскользь. В основном рассказ идет о том, как описать единственную рассматриваемую систему в виде черного ящика.

Я предпочитаю в своих юзкейсах не делать различий между системами, к которым мы ставим требования, и внешними акторами. Каждая из систем, которые мы модифицируем, считается таким же участником взаимодействия, как и все остальные. С точки зрения классической методики так нельзя: система — то что внутри, акторы — то что снаружи.

Зато мой подход позволяет извлечь набор функциональных требований к каждой системе по отдельности. Берем все шаги юзкейсов, в которых участвует данная система. Смотрим, существующая ли это функциональность или новая, или существующая, но с какими-то изменениями. Шаги, в которых нет изменений, выкидываем. То, что остается — передаем команде разработчиков системы для детальной технической проработки. Повторяем для каждой из систем, участвующих в юзкейсах проекта.

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

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

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

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

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

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

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

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

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

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

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

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

Имеется список поддерживаемых валют. Этот список делится на две части:

Для каждой валюты также известно, котируется ли она к рублю или к доллару США. «Котируется» в данном случае означает «курс задается Казначейством».

(Считаем, что доллар котируется к рублю, но не рубль к доллару, так как курс доллара задается в рублях, а не наоборот).

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

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

Перечень юзкейсов

Если требования описаны в форме юзкейсов, то их список становится полезным инструментом управления проектом. Например, в списке юзкейсов можно расставлять приоритеты реализации, можно измерять прогресс по количеству реализованных юзкейсов. Перечень юзкейсов может существовать в форме собственно перечня (Use Case Survey) или в виде диаграммы юзкейсов.

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

Здесь информации больше: мы видим участников взаимодействия и в каких юзкейсах они участвуют. Вопреки Коберну, в качестве участников показаны системы, к которым мы ставим требования (расчетная система, АБС), а также внешние неизменяемые системы (биржевой терминал, система бухучета) и пользователи.

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

Заключение

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

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

Источник