User story vs Use Case: разбираемся со схемами представления требований

обучение бизнес-аналитиков, обучение бизнес-анализу, курсы для аналитиков, курсы по бизнес-анализу, бизнес-аналитик обучение, разработка требований обучение, управление требованиями, оптимизация бизнес-процессов, Agile, User Story, Use Case, UML

Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 2 популярные схемы описания требований в Agile-проектах. Читайте далее, чем User story отличается от Use Case, а также как они связаны с UML-диаграммой прецедентов, а также функциональными и нефункциональными требованиями к решению, которые входят в ТЗ по ГОСТ.

От потребности к решению: виды требований и способы их описания

Напомним, руководство к профессиональному своду знаний по бизнес анализу BABOK®Guide выделяет 3 основных вида требований (бизнес, стейкхолдеров и к решению), а также переходные, актуальные на момент трансформации от текущего состояния (as-is) к желаемому (as-to-be). Подробнее об этом мы говорили в отдельной статье. Аналитик плотно работает со всеми видами требований, последовательно трассируя потребности, проблемы и возможности в требования к решению через бизнес-требования и требования заинтересованных сторон (стейкхолдеров).

Если решением является информационная система или программно-аппаратный комплекс, как это бывает в большинстве случаев, то в техническое задание (ТЗ) на его разработку попадают именно требования к решению: функциональные и нефункциональные. Для этого выделяются соответствующие пункты в стандартах по разработке (ISO/IEC/IEEE 29148:2018, ГОСТ 34.602-89, ГОСТ 19.201-78) и спецификации требований к программному обеспечению (Software Requirements specification, SRS) на основе IEEE/ISO/IEC 29148-2011. На практике формирование такого комплексного ТЗ по всем правилам является длительным и итеративным процессом со множеством циклов согласования между Заказчиком и командой реализации. Поэтому, чтобы лучше понять потребности стейкхолдеров и быстрее начать работу над программным продуктом, бизнес-аналитик описывает требования к системе в виде пользовательских историй (user story), которые кратко формулируют, какие возможности она предоставляет конкретной роли.

Основы бизнес-анализа: вход в профессию для начинающих

Код курса
INTRO
Ближайшая дата курса
17 февраля, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.

Что такое пользовательская история и чем она хороша

Обычно user story создаются по шаблонам возможности или ограничения:

  • <Роль> должен иметь возможность <возможность> в <показатель производительности> с <момент отсчета> в <условия эксплуатации>, чтобы <ценность>. Например, Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
  • <Система> должна <выполняемая функция> <объект> каждые <производительность> <единица измерения>, чтобы <ценность>. Например, CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.

Таким образом, формулировка исходных требований стейкхолдеров в виде пользовательских историй соответствует BDD-походу к разработке (Behavior-driven development), позволяя описать ожидания пользователей от проектируемой системы на понятном им языке и определить поведенческие сценарии тестирования для приемочных испытаний. User stories особенно распространены в продуктовой аналитике, но не заменяют собой формальное ТЗ по ГОСТ’ам с перечислением функций системы, о чем мы уже упоминали здесь и здесь. На практике такое представление требований часто встречается в Agile-проектах, особенно на начальном этапе бизнес-анализа при выяснении и уточнении потребностей заинтересованных сторон. Подробнее о том, как разные модели и методологии разработки ПО реализуют принципы Agile и движение по этапам SDLC, читайте в нашей отдельной статье.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
25 февраля, 2025
Продолжительность
22 ак.часов
Стоимость обучения
48 000 руб.

Сценарий использования и UML-диаграмма Use Case

Однако, user story – далеко не единственная схема представления требований, хотя именно она больше всего подходит к описанию требований стейкхолдеров. Также для описания функциональных требований, описывающих поведение проектируемой системы в едином смысловом контексте, применяется инструмент сценариев или вариантов ее использования (Use Case). В этом случае функциональные требования к системе представляются в виде набора функций, объединенных по контексту. Например, Use Case «Запланировать посещение клиента в клинику» может включать следующие функции:

  • Просмотреть историю посещений (данные о прошлых и запланированных визитах);
  • Добавить новое посещение;
  • Выбрать посещение;
  • Просмотреть детали (дата, время, место, врач) посещения;
  • Изменить детали будущего посещения;
  • Удалить будущее посещение.

Все эти функции представляют собой прецеденты UML-диаграммы вариантов использования (Use Case), которые связаны различными видами отношений. При этом направленную ассоциацию от актора проведем только к тем прецедентам, которые имеют смысл с пользовательской (бизнесовой) точки зрения. Таким здесь являются «Просмотреть историю посещений», «Добавить новое посещение» и «Просмотреть детали». А то, что для просмотра деталей конкретного посещения его надо выбрать из всего списка (просмотрев историю) — это системный use case. Поэтому целевой пользовательский UC «Просмотреть детали» ссылается на «Выбрать посещение» связью include. Это означает, что в реализации «Просмотреть детали» не может быть выполнен без выполнения «Выбрать посещение». В текстовой форме представления требований в виде Use Case это было бы прописано в графе «Предусловие, что мы рассмотрим далее. О том, как разрабатывать UML-диаграмму Use Case, мы поговорим в другой раз. А проверить свое знание основ UML вы можете, пройдя бесплатный интерактивный тест прямо на нашем сайте.

UML, Use Case пример, UML для бизнес-аналитиков
UML-диаграмма Use Case пример

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

  • Имя, в формате глагол-существительное, которое описывает достижимую цель и объяснять смысл сценария.
  • Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
  • Актор — действующее лицо, кто-то или что-то вне системы, влияющий на нее или находящийся под её влиянием (человек, устройство, другая система или подсистема).
  • Предусловия, которые должны быть истиной для выполнения сценария.
  • Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение сценария.
  • Результат (постусловие) – новый объект или изменение состояния существующего объекта, который показывает, что актор достиг своей цели.
  • Порядок Событий (основной поток) — типичный ход событий как ряд пронумерованных шагов.
  • Альтернативные пути и дополнения use case’а могут содержать вторичные пути или другие сценарии на шаги основного.
  • Бизнес-правила для определения результата в зависимости от конкретного запроса к системе, например, входных данных: «Изменение деталей или удаление возможно только для будущих посещений, дата и время которых еще не настали на момент просмотра записи».

Обычно сценарий использования по такой структуре оформляется в виде таблицы. В этом случае UML-диаграмма прецедентов (Use Case) является краткой наглядной схемой текстового представления основных функциональных возможностей взаимодействия с проектируемой системой, без детализации их выполнения. Бизнес-логика каждого прецедента описывается в пунктах сценария «Поток Событий»(Основной поток) и «Альтернативный поток». Как это сделать на практике, рассмотрим в следующей статье.

DDD, ООП и UML для аналитика

Код курса
BUML
Ближайшая дата курса
31 марта, 2025
Продолжительность
22 ак.часов
Стоимость обучения
48 000 руб.

Чем User Story отличается от Use case

Подводя итог описанию рассмотренных схем представления требований, подчеркнем сходства и отличия User Story и Use case:

  • обе этих схемы представления требований подходят для описания требований стейкхолдеров;
  • обе схемы активно используются в ИТ-проектах, позволяя начать реализацию системы  и создать прототип, демонстрирующий ключевые функциональные возможности;
  • UML-диаграмма вариантов использования (Use Case) может использоваться с обеими схемами представления требований, наглядно показывая основные функциональные возможности взаимодействия стейкхолдера с проектируемой системой, без детализации их выполнения. Однако, неподготовленному читателю такая диаграмма покажется сложной и непонятной, в отличие от простых формулировок User Story и текстового (табличного) представления Use Case.
  • User Story более легковесная техника, она требует меньше времени на формулирование, а потому она активно применяется в Agile-проектах, тогда как Use Case требует больше времени на разработку и потому более подходит для проектов, где нужна высокая степень формализации подробно задокументированных требований;
  • пользовательские истории требуют дальнейшей детализации для описания подробностей выполнения процессов, взаимодействия пользователя с системой, данных и бизнес-логики, тогда как Uase Case является самодостаточным;
  • User Story отлично подходит для разработки поведенческих сценариев тестирования, программы и методики приемочных испытаний;
  • сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно, предоставляя всю необходимую информацию о взаимодействии актора с системой, включая цель, пред- и пост-условия, триггеры, основные и альтернативные потоки, а также бизнес-правила;
  • User Story позволяет указать нефункциональные требования с точным заданием значений нужных показателей, например, время отклика на событие, наработку на отказ и пр.;
  • Use Сase объединяет функциональные требования по контексту.

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

Подробнее узнать о сходствах, отличиях, достоинствах и недостатках, примерах применения Use Case и User Story, а также научиться описывать требования по этим схемам представления вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий