Анна Вичугова и Анна Гасраталиева
Алгоритм описания функциональных требований к системе в формате UC
Введение
Существуют разные формы представления функциональных требований: пользовательская история (user story), каноническая форма с привязкой к CRUDL-операциям и модели данных (классический формат описания требований), а также описание сценариев использования (Use Case).
Use Case до сих пор является одной из самых популярных форм представления функциональных требований как среди российских компаний, так и за рубежом. Поэтому именно о них и пойдет речь в нашей статье.
В официальной литературе на русский язык Use Case принято переводить как вариант использования (сокращённо ВИ), хотя в разговорной речи и проектных документах достаточно часто употребляется ещё и транслитерация термина Use Case, то есть говорят и пишут юскейс.
В связке с понятием варианта использования идёт термин Use case scenario, который переводится как сценарий варианта использования или пользовательский сценарий.
Use Case до сих пор является одной из самых популярных форм представления функциональных требований как среди российских компаний, так и за рубежом. Поэтому именно о них и пойдет речь в нашей статье.
В официальной литературе на русский язык Use Case принято переводить как вариант использования (сокращённо ВИ), хотя в разговорной речи и проектных документах достаточно часто употребляется ещё и транслитерация термина Use Case, то есть говорят и пишут юскейс.
В связке с понятием варианта использования идёт термин Use case scenario, который переводится как сценарий варианта использования или пользовательский сценарий.
Технически, разница есть, то есть Use case это не тоже самое, что Use case scenario. Например, «Купить Товар» — Use case, и у него есть Use case scenario (пошаговое описание того, как именно купить товар: 1. Выбрать товар, 2. Добавить в корзину, 3. Оплатить).
Однако в литературе и документации вы достаточно часто будете сталкиваться с тем, что и пошаговый сценарий тоже называют юскейсом. Так происходит потому, что сам по себе, без описания сценария, юскейс, как правило, мало кого интересует.
В этой статье мы будем придерживаться термина UC, иногда заменяя его на другие, чтобы упростить восприятие статьи читателем.
Однако в литературе и документации вы достаточно часто будете сталкиваться с тем, что и пошаговый сценарий тоже называют юскейсом. Так происходит потому, что сам по себе, без описания сценария, юскейс, как правило, мало кого интересует.
В этой статье мы будем придерживаться термина UC, иногда заменяя его на другие, чтобы упростить восприятие статьи читателем.
Итак, Use case (UC) — это популярная форма представления функциональных требований к ПО в виде пошагового сценария взаимодействия актора (пользователя или внешнего сервиса) с проектируемой системой, включая описание метаданных этого взаимодействия: области применения, предусловия, триггеры, постусловия, релевантные бизнес-правила и пр.
Давайте рассмотрим на примере, как описать UC и избежать ошибок в работе с этим методом.
Давайте рассмотрим на примере, как описать UC и избежать ошибок в работе с этим методом.
Алгоритм описания функциональных требований к системе
Типовую последовательность разработки функциональных требований в форме UC можно представить следующим образом:
Теперь давайте рассмотрим каждый шаг поподробнее.
- Определить Акторов — тех, кто взаимодействует с системой
- Выявить и составить список UC — задач, которые стейкхолдеры смогут решить с помощью системы
- Для каждого юскейса определить приоритет — важность UC по отношению к другим вариантам использования
- Для каждого важного юскейса определить контекст применения, конечную цель и результат
- Описать основной поток каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
- Дополнить основной поток расширениями, исключениями и циклами
- Собрать воедино результаты шагов 4-6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой
Теперь давайте рассмотрим каждый шаг поподробнее.
1. Определить акторов, которые взаимодействуют с системой
Актором может быть несколько разных пользовательских ролей и/или внешние сервисы, которые будут интегрироваться с проектируемой системой, то есть получать из неё данные или вносить их в неё.
Например, если рассматривать мобильный телефон как систему, то актором будет человек — пользователь мобильного телефона. Результат этого шага можно оформить в виде таблицы или диаграммы ролей.
Актором может быть несколько разных пользовательских ролей и/или внешние сервисы, которые будут интегрироваться с проектируемой системой, то есть получать из неё данные или вносить их в неё.
Например, если рассматривать мобильный телефон как систему, то актором будет человек — пользователь мобильного телефона. Результат этого шага можно оформить в виде таблицы или диаграммы ролей.
2. Для каждого актора составить список задач, которые он сможет решить с помощью системы
Мы советуем делать это в виде реестра юскейсов — единой таблицы, показывающей распределение юскейсов по акторам.
Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.
Из названия вариант использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее.
Мы советуем делать это в виде реестра юскейсов — единой таблицы, показывающей распределение юскейсов по акторам.
Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.
Из названия вариант использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее.
Обычно для продуктов и проектов в сфере B2C исходные данные для этого извлекаются из изучения интересов, потребностей и пользовательского опыта людей (клиентов, экспертов предметной области) и конкурентного анализа, а также CJM-карты.
Для B2B-продуктов и проектов исходными данными для юскейсов, как правило, являются отраслевые и корпоративные регламенты, описание бизнес-процессов и запросы стейкхолдеров.
Давайте сформируем реестр юскейсов. Например, ранее для пользователя мобильного телефона мы определи функциональные возможности «Сделать звоноки» и «Отправить СМС». Они реализуют единую пользовательскую потребность: «Связаться с другим человеком», поэтому их можно объединить в один юскейс.
Юскейсы «Поиграть в казуальную Игру» и «Посмотреть фотографии» относятся к потребности «Скоротать время».
Таким образом, для данного примера с мобильным телефоном реестр юскейсов может выглядеть следующим образом:
Юскейсы «Поиграть в казуальную Игру» и «Посмотреть фотографии» относятся к потребности «Скоротать время».
Таким образом, для данного примера с мобильным телефоном реестр юскейсов может выглядеть следующим образом:
3. Для каждого UC определить его приоритет
Реализация юскейсов в коде — трудоёмкая работа, поэтому надо понимать, с каких лучше начать в первую очередь, а до каких очередь может не дойти никогда.
Реестр юскейсов может использоваться для приоритизации пользовательских функциональных требований с целью их ранжирования по степени важности, которая определяет порядок реализации.
Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW. Он получил своё название не в честь российской столицы, а как сокращение следующих 4 категорий:
Реализация юскейсов в коде — трудоёмкая работа, поэтому надо понимать, с каких лучше начать в первую очередь, а до каких очередь может не дойти никогда.
Реестр юскейсов может использоваться для приоритизации пользовательских функциональных требований с целью их ранжирования по степени важности, которая определяет порядок реализации.
Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW. Он получил своё название не в честь российской столицы, а как сокращение следующих 4 категорий:
- Must — то, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям. Чаще всего этот приоритет называется 1-я очередь и обозначается цифрой 1
- Should — требования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must. Это приоритет номер 2
- Could — желательные требования, которые можно сделать, если останется время и будут ресурсы. Это приоритет номер 3
- Would — требования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта. Это приоритет номер 4
Справедливости ради стоит отметить, что метод MoSCoW в качестве базиса приоритизации выбирает менеджерскую точку зрения, то есть не учитывает технические зависимости между требованиями, которые определяются при трассировке требований, то есть. их связей друг с другом.
Впрочем, тема трассировки и приоритизации требований достаточно обширна и заслуживает отдельной статьи.
4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат
Это можно оформить в виде списка или таблицы, например в Notion:
Впрочем, тема трассировки и приоритизации требований достаточно обширна и заслуживает отдельной статьи.
4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат
Это можно оформить в виде списка или таблицы, например в Notion:
5. Раскрыть содержание основного потока каждого юскейса высокого приоритета в виде пользовательского сценария
Напомним, что пользовательский сценарий — это последовательность шагов, которая приведёт к достижению конечной цели юскейса, получению нужного актору результата.
Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.
Напомним, что пользовательский сценарий — это последовательность шагов, которая приведёт к достижению конечной цели юскейса, получению нужного актору результата.
Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.
Как может выглядеть черновик сценария основного потока юскейса:
- Запросить номер телефона вызываемого абонента
- Убедиться в корректности указанного номера телефона
- Вызвать абонента с указанным номером телефона
- Передать голос собеседников в ходе разговора
Пример простой схемы
Последовательность шагов в виде BPMN-диаграммы
Как может выглядеть черновик сценария основного потока юскейса:
- Запросить номер телефона вызываемого абонента
- Убедиться в корректности указанного номера телефона
- Вызвать абонента с указанным номером телефона
- Передать голос собеседников в ходе разговора
На практике подавляющая часть сценариев описывается только текстовым описанием. Пример такого описания мы разберём с вами ниже.
6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами
На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.
Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).
6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами
На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.
Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).
Расширенная BPMN-диаграмма юскейса с исключениями и альтернативными потоками
7. Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой
На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:
На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:
- Имя
- Приоритет
- Область действия
- Контекст
- Актор
- Цель
- Предусловия
- Результат (постусловие)
- Основной поток
- Расширения или альтернативные потоки
- Бизнес-правила
Полная структура юскейса
Давайте разберем каждый элемент этой структуры поподробнее.
Эту структуру можно представить в текстовом виде или, для наглядности, в виде таблицы. Давайте завершим описание этого юскейса так, как мы делаем это на реальных проектах, то есть полностью опишем happy path и альтернативные сценарии.
Пример 1. UC «Сделать Звонок»
При описании юскейсов на реальном проекте мы рекомендуем в первую очередь учитывать текущие нужды и предпочтения ваших стейкхолдеров (заказчика, разработчиков, тестировщиков и так далее).
Главная задача любого юскейса состоит в том, чтобы создать общее понимание взаимодействия у пользователя системы, у заказчика и у всей проектной команды. Поэтому зацикливаться на «правильном» формате будет неэффективно, гораздо лучше ориентироваться на нужды потребителей вашей документации, а значит, нужно поговорить с ними, показать наработки и согласовать удобный всем формат.
Главная задача любого юскейса состоит в том, чтобы создать общее понимание взаимодействия у пользователя системы, у заказчика и у всей проектной команды. Поэтому зацикливаться на «правильном» формате будет неэффективно, гораздо лучше ориентироваться на нужды потребителей вашей документации, а значит, нужно поговорить с ними, показать наработки и согласовать удобный всем формат.
Как структурировать UC из набора
исходных ФТ
исходных ФТ
Задача:
Рассмотрим пример информационной системы, которая позволяет клиенту выбрать один или несколько обучающих курсов, заключить договор на участие в них и оплатить сумму через онлайн-оплату.
Если у клиента есть промо-код на скидку по конкретному курсу, сумма в договоре будет снижена на размер скидки.
Таким образом, мы имеем следующий базовый, стартовый набор функциональных требований к информационной системе управления договорами на обучение:
Рассмотрим пример информационной системы, которая позволяет клиенту выбрать один или несколько обучающих курсов, заключить договор на участие в них и оплатить сумму через онлайн-оплату.
Если у клиента есть промо-код на скидку по конкретному курсу, сумма в договоре будет снижена на размер скидки.
Таким образом, мы имеем следующий базовый, стартовый набор функциональных требований к информационной системе управления договорами на обучение:
- FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
- FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
- FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора
- FRQ4 Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключенному договору через шлюз онлайн-оплаты
- FRQ5 Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку
Шаг 1. Определяем акторов. Судя по требованиям, с системой взаимодействует клиент и шлюз оплаты.
Шаг 2. Сформируем реестр юскейсов. Для этого мы можем, например, представить имеющийся набор функциональных требований в виде UML-диаграммы вариантов использования (UML Use case diagram).
Исходная UML-диаграмма use case
Чтобы составить реестр юскейсов, давайте выделим из ранее представленных юскейсов именно те, что имеют бизнес-ценность для пользователя без привязки к системе.
Упрощённая UML-диаграмма use case
Давайте также сопоставим получившиеся юскейсы и функциональные требования в таблице ниже.
При формировании реестра юскейсов для пользователя мобильного телефона мы можем выделить такие функциональные возможности как «Сделать Звонок» и «Отправить СМС». Оба этих юскейса отражают непосредственное взаимодействие актора с системой, направленное на достижение определённой бизнес-цели, это системный юскейс.
Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.
Реестр вариантов использования:
Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.
Реестр вариантов использования:
Шаг 3. Определить приоритеты системных юскейсов
Поскольку юскейсы в рассматриваемой части системы тесно связаны между собой, ранее рассмотренный метод приоритизации MoSCow не совсем подходит для этого случая. Здесь целесообразнее расставить приоритеты с точки зрения технических зависимостей данных юскейсов между собой: сперва должны быть реализованы требования относительно возможности заключить договор, чтобы потом проводить оплату по заключённому договору.
Шаги 4-7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см.ниже). По аналогии будет описан и UC «Заключить Договор».
Поскольку юскейсы в рассматриваемой части системы тесно связаны между собой, ранее рассмотренный метод приоритизации MoSCow не совсем подходит для этого случая. Здесь целесообразнее расставить приоритеты с точки зрения технических зависимостей данных юскейсов между собой: сперва должны быть реализованы требования относительно возможности заключить договор, чтобы потом проводить оплату по заключённому договору.
Шаги 4-7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см.ниже). По аналогии будет описан и UC «Заключить Договор».
Пример 2. UC «Оплатить Договор»
Для нашего примера вариант использования «Оплатить Договор» может выглядеть так:
У нас получилось представление варианта использования в виде подробного описания взаимодействия актора с проектируемой системой по заданному шаблону, включая последовательность шагов основного потока, приводящего к достижению пользовательской цели в заданном бизнес-контексте, альтернативные поток, пред- и постусловия.
Такой формат хорошо подходит для реализации, если в юскейсе описана конкретная привязка к модели данных, указаны сущности и атрибуты, над которыми выполняются операции.
Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.
Кроме того, у нас получилось слишком много шагов в юскейсе, что является сигналом к его разделению на несколько. В данном случае можно было бы, например, вынести в отдельный юскейс работу с промо-кодами.
Такой формат хорошо подходит для реализации, если в юскейсе описана конкретная привязка к модели данных, указаны сущности и атрибуты, над которыми выполняются операции.
Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.
Кроме того, у нас получилось слишком много шагов в юскейсе, что является сигналом к его разделению на несколько. В данном случае можно было бы, например, вынести в отдельный юскейс работу с промо-кодами.
Пример 3. UC «Обновить Анкету»
На курсе «Системный анализ и разработка требований в ИТ-проектах» мы предлагаем представлять вариант использования в табличной форме по следующему шаблону:
Достоинства и недостатки UC как формы представления требований
Основными преимуществами UC являются следующие:
- Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
- Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ;
- Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
- Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
- UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось
- Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
- Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
- На детальную проработку каждого UC уходит много времени. Например, у меня это занимает в среднем от 30 минут; добиться существенного повышения скорости работы можно за счёт повторного использования типовых юскейсов (опытный аналитик или отдел могут создать библиотеку своих юскейсов )
- Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)
Откуда взялся такой формат как Use Case
Разумеется, не мы изобрели юскейсы как формат описания требований. Существуют общепризнанные мировые эксперты в этой области, а также книги-первоисточники, к которым стоит обращаться в случае возникновения споров и недопонимания. Скажем о них пару слов, чтобы вы знали, куда обратиться при необходимости.
Исторически функциональные требования, представляющие поведение системы, описывались в виде отдельных функций. Например, так:
Исторически функциональные требования, представляющие поведение системы, описывались в виде отдельных функций. Например, так:
- FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
- FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
В 1986 году Ивар Якобсон (шведский учёный, который вместе с Гради Бучем и Джеймсом Рамбо стоял у истоков ООП и UML) предложил альтернативную форму представления функциональных возможностей системы. Вместо описания функциональных требований к системе в виде отдельных функций Якобсон предложил объединить их по контексту, а затем превратить в набор вариантов использования (ВИ), который будет обеспечивать полноту и неизбыточность требований.
Якобсон обнаружил, что отдельные системные ФТ обычно не представляют большой самостоятельной ценности для заказчика, менеджера, пользователя, так как являются слишком мелкими единицами функциональности. Подход Якобсона позволил вместо сотен-тысяч системных функций применять единицы-десятки юскейсов, что гораздо удобнее в целях управления, планирования и сдачи ИТ-продукта/системы. Кроме того, он хорошо стыкуется с задачами тестирования и создания пользовательской документации. Подробнее об этом см в статье.
Якобсон обнаружил, что отдельные системные ФТ обычно не представляют большой самостоятельной ценности для заказчика, менеджера, пользователя, так как являются слишком мелкими единицами функциональности. Подход Якобсона позволил вместо сотен-тысяч системных функций применять единицы-десятки юскейсов, что гораздо удобнее в целях управления, планирования и сдачи ИТ-продукта/системы. Кроме того, он хорошо стыкуется с задачами тестирования и создания пользовательской документации. Подробнее об этом см в статье.
В 2001 году Алистер Коберн, эксперт в разработке ПО, расширил и уточнил идеи Якобсона, выпустив книгу «Современные методы описания функциональных требований к системам» (Writing Effective Use Cases). Книга получилась достаточно подробной, содержащей множество примеров. Помимо техник описания самих UC, работа Коберна включает также связанные вопросы о контексте, границах и основных компонентах проектируемой системы, то есть так называемый scope системы.
Эти и другие аспекты работы с требованиями были изложены в книге ещё одного автора, широко известного в системном и бизнес-анализе. В 2003 году Карл Вигерс (Karl Wiegers) написал 2-е издание своей книги «Разработка требований к программному обеспечению» (Software Requirements), где рассмотрены не только техники разработки требований, но и вопросы управления ими, включая сбор, документирование, трассировку, работу с изменениями и анализ рисков. Эта книга почти вдвое объёмнее труда Коберна и больше подходит для начинающих аналитиков.
Эти и другие аспекты работы с требованиями были изложены в книге ещё одного автора, широко известного в системном и бизнес-анализе. В 2003 году Карл Вигерс (Karl Wiegers) написал 2-е издание своей книги «Разработка требований к программному обеспечению» (Software Requirements), где рассмотрены не только техники разработки требований, но и вопросы управления ими, включая сбор, документирование, трассировку, работу с изменениями и анализ рисков. Эта книга почти вдвое объёмнее труда Коберна и больше подходит для начинающих аналитиков.
Заключение
UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: ЧТО система должна сделать, чтобы актор достиг своей цели, а НЕ КАК это должно быть сделано.
Благодаря отсутствию привязки к элементам пользовательского интерфейса, ВИ становятся повторно используемыми требованиями, которые остаются актуальными при изменении платформы или других особенностей реализации.
Несмотря на повсеместное распространение гибких методологий разработки ПО, UC как подход к описанию функциональных требований очень активно применяется на практике. В отличие от пользовательских историй (User Story), другой популярной формы представления требований, UC охотно принимают в реализацию — в основном благодаря структурированному формату и детальной проработке бизнес-логики с привязкой к модели данных.
Благодаря отсутствию привязки к элементам пользовательского интерфейса, ВИ становятся повторно используемыми требованиями, которые остаются актуальными при изменении платформы или других особенностей реализации.
Несмотря на повсеместное распространение гибких методологий разработки ПО, UC как подход к описанию функциональных требований очень активно применяется на практике. В отличие от пользовательских историй (User Story), другой популярной формы представления требований, UC охотно принимают в реализацию — в основном благодаря структурированному формату и детальной проработке бизнес-логики с привязкой к модели данных.
Полный реестр UC и структурированное описание каждого из них позволяет разработчикам воплотить описанные структуры данных и алгоритмы их обработки. Таким образом, большая трудоемкость при разработке вариантов использования на этапе анализа и спецификации требований окупается сокращением времени на этапе реализации и тестирования. Кроме того, реестр юскейсов можно использовать для оценки трудоёмкости проекта — менеджеры проектов часто приходят к аналитикам и тимлидам с этим вопросом.
В завершение статьи хотелось бы напомнить: если ваш юскейс решает проблемы разработки ПО, то есть создаёт общее понимание требований у заказчика и всей проектной команды, то вы написали хороший юскейс. Следование формату само по себе не самоценно.
Получить навыки уверенного написания юскейсов вы можете только на опыте. На курсе «Системный анализ и разработка требований в ИТ-проектах» мы предлагаем вам получить этот опыт быстрее и удобнее: в концентрированной форме, под руководством опытных инструкторов.
В завершение статьи хотелось бы напомнить: если ваш юскейс решает проблемы разработки ПО, то есть создаёт общее понимание требований у заказчика и всей проектной команды, то вы написали хороший юскейс. Следование формату само по себе не самоценно.
Получить навыки уверенного написания юскейсов вы можете только на опыте. На курсе «Системный анализ и разработка требований в ИТ-проектах» мы предлагаем вам получить этот опыт быстрее и удобнее: в концентрированной форме, под руководством опытных инструкторов.
Анна Вичугова
Бизнес-аналитик, CBAP, к.т.н., тренер Systems.Education,
основатель и тренер Школы прикладного бизнес-анализа
основатель и тренер Школы прикладного бизнес-анализа
Вичугова Анна Александровна
Бизнес-аналитик, CBAP, к.т.н., тренер Systems.Education,
основатель и тренер Школы прикладного бизнес-анализа
Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.
Бизнес-аналитик, CBAP, к.т.н., тренер Systems.Education,
основатель и тренер Школы прикладного бизнес-анализа
- Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
- Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
- Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
- Сертифицированный специалист и администратор СЭД Directum (2011
Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.
Анна Гасраталиева
Системный аналитик, выпускающий редактор Systems.Education
Гасраталиева Анна Константиновна
Системный аналитик, выпускающий редактор Systems.Education
Профессиональные интересы: телекоммуникации, интеграции, управление задачами, управление людьми, обучения
Системный аналитик, выпускающий редактор Systems.Education
Профессиональные интересы: телекоммуникации, интеграции, управление задачами, управление людьми, обучения
