Область применимости юзкейсов

“Ни одна модель неверна, по крайней мере в нашем реальном мире, но некоторые модели более полезны, чем другие”

(c) Джордж Бокс.

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

Наиболее интенсивно юзкейсы, как нотация развивались в 90-е годы. Можно сказать, что это был золотой век юзкейсов. В это время создавалось огромное количество учетных систем основанных на архитектурах от файл-сервер до трехзвенки. Для таких систем юзкейсы замечательная штука. Но есть области, где их применение не слишком оправдано. Рассмотрим некоторые из этих областей.

1. Проект не по созданию, а по настройке учетной системы.

Предположим, вам понадобился бактрекер. Если вы будете писать движок аналогичный Jira, Redmine или Trackstudio, юзкейсы - это то, что надо для описания функциональных требований. Но если вы собираетесь просто настроить одну из перечисленных систем под свои нужды, то предпочтительней использовать другие нотации. Диаграмму состояний, EPC-диаграмму, восможно IDEF или BPML. Что касается других систем, таких SAP, Sharepoint  и т.п., то в проектах по их настройке под бизнеспроцессы заказчика, так же предпочтительно использовать отличные от юзкейсов нотации.

2. Большое количество различных интерфейсов пользователя для одной и той же функциональности.

Это требование современности. Возьмем, например оплату коммунальных платежей. Пятнадцать лет назад было достаточно одного интерфейса, через который оператор вводил оплату. Сейчас же такие системы покидают рынок. Одна и та же система для одной и той же функциональности может предоставлять интерфейсы через инфомат, смартофон, ПК, планшетник. Это разные интерфейсы. Можно, конечно описывать юзкейсы для каждого интерфейса отдельно, но часто эффективней описать базовые правила, а для каждого из вариантов конечного устройства обслуживания или задать общие правила (для сенсорных устройств размер кнопки не менее, чем …) или разрабатывать прототипы интерфейсов. Прототипы интерфейсов - тоже модель. Весьма удобная.

3. Разрабатываемое ПО содержит много логики.

Нет смысла описывать игромеханику Word of Warcraft через юзкейсы. Это гораздо проще сделать через описание правил. Хотя для описания создания, удаления персонажа и других подобных действий юзкейсы по прежнему эффективны.

А для компилятора командной строки или для утилиты grep юзкейс будет один. А остальные требования - это куча правил.

Но если продукт будет развиваться дальше, то отсутствие юзкейсов может сослужить плохую службу. Skype - сложная технологическое приложение. Разработать его было явно не просто. И похоже в какой то момент разработчики пренебрегли юзкейсами. Как результат, управлять всего то парой сотен аккаунтов не слишком удобно.

4. Взаимодействие между системами.

Это тоже веяние нашего времени. Часто разрабатываемая система должна общаться с сотнями систем, в том числе и от стороннего производителя. Простой форум может поддерживать RSS, использовать стороннюю аутентификацию, взаимодействовать с твиттером, фейсбуком, почтовыми серверами, … Что касается современных финансовых систем, то там все еще печальней.

Для описания протоколов взаимодействия неплохо зарекомендовали себя диаграммы последовательности и какой либо вариант  описания XML.

5. Продукт, для которого функциональные требования не слишком важны или их очень мало.

В начале двухтысячных был бум примитивных сайтов. Функциональности ноль, зато масса требований к оформлению. Юзкейсы не нужны.

Подводя итоги.

Мой тренер по рукопашке говорил: “Нет плохих приемов. Есть неправильное их применение.” Перефразируя его: “Нет плохих нотаций. Нотация должна выбираться в зависимости от проекта.”

PS. Это одна из вводных статей для моего тренинга по разработке юзкейсов. Я переношу материал в статьи, для того, чтобы на самом тренинге больше времени уделить практике.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.