Продолжая обучение начинающих бизнес-аналитиков, сегодня рассмотрим 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
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Что такое пользовательская история и чем она хороша
Обычно user story создаются по шаблонам возможности или ограничения:
- <Роль> должен иметь возможность <возможность> в <показатель производительности> с <момент отсчета> в <условия эксплуатации>, чтобы <ценность>. Например, Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
- <Система> должна <выполняемая функция> <объект> каждые <производительность> <единица измерения>, чтобы <ценность>. Например, CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.
Таким образом, формулировка исходных требований стейкхолдеров в виде пользовательских историй соответствует BDD-походу к разработке (Behavior-driven development), позволяя описать ожидания пользователей от проектируемой системы на понятном им языке и определить поведенческие сценарии тестирования для приемочных испытаний. User stories особенно распространены в продуктовой аналитике, но не заменяют собой формальное ТЗ по ГОСТ’ам с перечислением функций системы, о чем мы уже упоминали здесь и здесь. На практике такое представление требований часто встречается в Agile-проектах, особенно на начальном этапе бизнес-анализа при выяснении и уточнении потребностей заинтересованных сторон. Подробнее о том, как разные модели и методологии разработки ПО реализуют принципы Agile и движение по этапам SDLC, читайте в нашей отдельной статье.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 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-схемой, а также включает текстовое описание по следующей структуре:
- Имя, в формате глагол-существительное, которое описывает достижимую цель и объяснять смысл сценария.
- Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
- Актор — действующее лицо, кто-то или что-то вне системы, влияющий на нее или находящийся под её влиянием (человек, устройство, другая система или подсистема).
- Предусловия, которые должны быть истиной для выполнения сценария.
- Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение сценария.
- Результат (постусловие) – новый объект или изменение состояния существующего объекта, который показывает, что актор достиг своей цели.
- Порядок Событий (основной поток) — типичный ход событий как ряд пронумерованных шагов.
- Альтернативные пути и дополнения use case’а могут содержать вторичные пути или другие сценарии на шаги основного.
- Бизнес-правила для определения результата в зависимости от конкретного запроса к системе, например, входных данных: «Изменение деталей или удаление возможно только для будущих посещений, дата и время которых еще не настали на момент просмотра записи».
Обычно сценарий использования по такой структуре оформляется в виде таблицы. В этом случае UML-диаграмма прецедентов (Use Case) является краткой наглядной схемой текстового представления основных функциональных возможностей взаимодействия с проектируемой системой, без детализации их выполнения. Бизнес-логика каждого прецедента описывается в пунктах сценария «Поток Событий»(Основной поток) и «Альтернативный поток». Как это сделать на практике, рассмотрим в следующей статье.
DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 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, а также научиться описывать требования по этим схемам представления вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
