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

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

Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 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), которые кратко формулируют, какие возможности она предоставляет конкретной роли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

управление требованиями, User Story, Use Case, функциональные требования
User Story, Use Case и функциональные требования

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

 

Комментировать