Описание функциональных требований в форме юзкейсов (Use Case) используется при разработке ИТ-систем уже более 30 лет для описания взаимодействия продуктов с пользователями и другими системами. Ниже мы расскажем, как менеджеры продуктов и аналитики могут использовать эту методологию и для оценки трудоемкости разработки.
Что такое Use Case
В 1987 году сотрудник исследовательской лаборатории шведской компании Ericsson Ивар Якобсон сформулировал методику описания требований к программному обеспечению, которую в коллективе называли Användningsfall — «сценарии использования» (по-шведски). Якобсон готовил доклад об этой методике для международной конференции OOPSLA-87. Не подобрав адекватного термина на английском, швед использовал довольно корявое для англоязычного слушателя словосочетание «Use Case». Тем не менее, благодаря успеху методики, это название быстро распространилось по всему миру.
Говоря по-простому, Use Case — это описание того, как актор (пользователь-человек или другая система) взаимодействует с разрабатываемой системой для достижения своих целей. Основные моменты составления юзкейсов:
- описание в виде сценария из последовательности чередующихся шагов, как в шахматах;
- определение основного успешного сценария, при полном прохождении которого пользователь достигает своей цели;
- дополнительное описание альтернативных сценариев, когда что-то пошло не так;
- определение пред- и постусловий: что требуется для выполнения сценария и что гарантируется, когда он уже реализован.
Перед проектированием юзкейсов следует собрать максимально возможную информацию о системе, решаемой проблеме и имеющихся ограничениях.
Начинать разбиение функций системы на юзкейсы рекомендуется с составления списка всех акторов, то есть людей и других взаимодействующих с ней систем. У каждого участника (и не только у актора-человека) могут быть свои интересы, которые должны удовлетворяться при работе системы. Они должны быть выявлены, и каждый должен появиться в постусловиях хотя бы одного юзкейса.
При всей простоте концепции хорошо описанный Use Case полезен всем участникам разработки:
- заказчик примерит сценарии «на себе» и поймет, чего не хватает проекту;
- тестировщик может написать тест-кейсы, прямо имитирующие каждый сценарий Use Case;
- UX-дизайнер нарисует эскизы экранов для каждого шага сценариев;
- разработчик поймет, как программа должна реагировать на внешние сигналы;
- менеджер проекта оценит трудоемкость работы и сможет спланировать дальнейшие шаги разработки.
Составлению UC помогут следующие источники:
- учебник Алистера Коберна «Современные методы описания функциональных требований»
- бесплатный учебник Ивара Якобсона «Use Case 2.0 Essentials Practice»
- книга Алана Купера «Психбольница в руках пациентов»
- статья руководителя сообщества аналитиков Санкт-Петербурга Анны Абрамовой «Use Cases — что это такое и зачем они нужны»
Оцениваем трудозатраты
Предположим, что команда реализовала предыдущий проект за четыре недели с полным набор требований в десяти Use Case. Новый проект насчитывает уже двадцать сценариев. В этом случае кажется разумным предположить, что он будет выполнен этой же командой в два раза дольше, то есть за восемь недель.
Такая простая на вид методика дает небольшую погрешность оценки, но только при соблюдении нескольких важных условий:
- разбиение функционала системы на отдельные UС в обоих проектах должен делать один и тот же сотрудник. Количество юзкейсов для одной и той же системы может отличаться в
1,5-2 раз, если они были составлены разными аналитиками; - архитектурная сложность обоих проектов одинакова. Оценка по числу UC показывает разницу только в функционале системы, но не дает подход к оценке трудозатрат на решение проблем интеграции компонентов и т. п.;
- нефункциональные требования к обеим системам близки. Появление в новом проекте других требований по производительности, надежности, безопасности и пр. при неизменном функционале может сделать его выполнение в разы дороже;
- средства разработки, тестирования и документирования в проектах одни и те же. Использование разных инструментов может привести к разному времени исполнения задач.
Если менеджер проекта собирается оценивать трудозатраты с помощью подсчета UC, важно убедиться в том, что аналитик выявил все кейсы разрабатываемой системы. Для этого можно применять трассировку UC на операции бизнес-процесса. Автоматизируемый процесс должен проходиться с начала и до конца с использованием только UC, входящих в данный проект или уже реализованных ранее.
При трассировке и оценке трудозатрат удобно иметь под рукой UC-диаграмму всей системы, напечатанную на листе большого формата. Общая рекомендация при работе с диаграммами — располагать на одной не более десятка элементов, чтобы не затруднять их сопровождение. Если число UC больше, надо разносить разные группы кейсов на разные диаграммы, группируя их, например, по бизнес-процессам.
Но не в рассматриваемом случае. Для оценки трудозатрат нужно не вчитываться в детали каждого отдельного UC, а поместить все на одну общую диаграмму. Важным становится полнота картины и обзор всех связей между объектами диаграммы — акторами и сценариями использования системы. Грубо говоря, при оценке важнее точно знать общее число первых и вторых (например, с 53 кейсами связано 18 акторов). Поэтому перед оценкой и планированием следует подготовить общую UC-диаграмму на весь проект.
Небольшой совет: используйте разные цвета для маркировки различных бизнес-процессов на диаграмме. Например, красным — забытые UC. К моменту сдачи проекта вы сможете посчитать их количество и определить насколько был качественно выполнен предпроектный анализ.
Создавать UC-диаграммы можно в Microsoft Visio, Sparx Enterprise Architect, плагином draw.io в Confluence и в других аналогах.
Как составить плохой Use Case
На всех стадиях при описании UC-взаимодействия аналитик может сделать ряд ошибок, которые после приведут к непониманию задач у команды, трате ресурсов и плохому результату. При составлении UC важно не допустить наиболее распространенные ошибки:
- пропуск шагов пользователя или системы. Например, если в сценарии из пяти шагов, четыре — пользовательские, то читатель не получит четкого представления о состояниях системы после каждого шага;
- интересы участников UC не выявлены, не обсуждены и не специфицированы. В результате функционал реализуется так, что у пользователей не возникает интереса его выполнять;
- не выявлены все возможные шаги, на которых события могут начать развиваться незапланированно. В результате разработчики делают обработку исключительных ситуаций так, как им удобнее;
- пред- и постусловия не специфицированы. Их правильное понимание позволяет связать UC в цепочки, где постусловие одного юзкейса является предусловием другого. Если такой связи нет, фактически это означает, что между этими двумя сценариями возникает нигде не описанный третий, связывающий их.
