Use case
ЧТО система должна сделать, чтобы актор достиг цели
Use case представляет собой детальное описание взаимодействия между актерами (пользователями) и системой. Он описывает конкретную ситуацию, в которой актер взаимодействует с системой для достижения определенной цели.
Use case включает шаги, актеров, предусловия, основные действия и ожидаемые результаты. Use case помогает понять, как система будет использоваться и как она должна взаимодействовать с пользователями.
Алгоритм описания Use case (UC)
Типовую последовательность разработки функциональных требований в форме UC можно представить следующим образом:
Определить Акторов — тех, кто взаимодействует с системой
Выявить и составить список UC — задач, которые стейкхолдеры смогут решить с помощью системы
Для каждого юскейса определить приоритет — важность UC по отношению к другим вариантам использования
Для каждого важного юскейса определить контекст применения, конечную цель и результат
Описать основной поток каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
Дополнить основной поток расширениями, исключениями и циклами
Собрать воедино результаты шагов 4−6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой
Теперь давайте рассмотрим каждый шаг поподробнее.
Шаг 1. Определить Акторов
Актором может быть несколько разных пользовательских ролей и/или внешние сервисы, которые будут интегрироваться с проектируемой системой, то есть получать из неё данные или вносить их в неё.
Например, если рассматривать мобильный телефон как систему, то актором будет человек — пользователь мобильного телефона. Результат этого шага можно оформить в виде таблицы или диаграммы ролей.
Шаг 2. Составить список UC
Мы советуем делать это в виде реестра юскейсов — единой таблицы, показывающей распределение юскейсов по акторам. Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы. Из названия варианта использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее. Для повышения наглядности можно сделать это в табличном виде или UML-диаграммы вариантов использования (она же Use case diagram, диаграмма прецедентов).
Шаг 3. Определить приоритет
Реализация юскейсов в коде — трудоёмкая работа, поэтому надо понимать, с каких лучше начать в первую очередь, а до каких очередь может не дойти никогда. Реестр юскейсов может использоваться для приоритизации пользовательских функциональных требований с целью их ранжирования по степени важности, которая определяет порядок реализации. Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW.
Шаг 4. Определить контекст/цель/результат для Must have
Контекст = описание проблематики
Цель = итог Use Case
Результат = постусловия
Шаг 5. Описать основной поток для Must have
Пользовательский сценарий — это последовательность шагов, которая приведёт к достижению конечной цели юскейса, получению нужного актору результата.
Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.
Шаг 6. Дополнить основной поток расширениями, исключениями и циклами
На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.
Шаг 7. Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой
На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:
Имя
Приоритет
Область действия
Контекст
Актор
Цель
Предусловия
Результат (постусловие)
Основной поток
Расширения или альтернативные потоки
Бизнес-правила
Преимущества UC
Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ
Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось
Недостатки UC
Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
На детальную проработку каждого UC уходит много времени
Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)
Источник: https://systems.education/functional_requirements_in_usecases
Last updated