Инженерия требований

Три уровня целей по Коберну

Коротко Любой вариант использования (use case) написан на каком-то уровне цели, и смешение уровней — самая частая причина того, что варианты использования получаются то слишком расплывчатыми, то слишком подробными. Алистер Коберн дал уровням названия, цвета и значки, чтобы авторы и читатели могли явно сказать, на каком уровне они работают.

По материалам: А. Коберн, «Современные методы описания функциональных требований к системам», гл. 2 и 5.

На этой странице

Главные идеи#

У целей есть высота#

Коберн представляет цели как местность с рельефом. Точка отсчёта — уровень моря: цель пользователя. Всё остальное лежит выше или ниже.

  • Обобщённые цели (summary goals) — белый цвет, значок воздушного змея, а для самого высокого уровня — облако. Они объединяют несколько целей пользователя и показывают их контекст и жизненный цикл. Если значки недоступны, Коберн ставит после названия «+».
  • Цели пользователя (user goals) — голубой цвет, уровень моря, значок волны. Это то, что основное действующее лицо действительно хочет сделать за один присест: обычно от нескольких минут до двадцати. При необходимости помечаются «!». Это самый важный уровень.
  • Подфункции (subfunctions) — индиго, под водой, значок рыбы. Шаги, нужные для достижения целей пользователя; их повторно используют несколько вариантов использования. Помечаются «-».
  • Слишком низкий уровень — чёрный цвет, значок моллюска. Это слишком мелко, чтобы вообще быть вариантом использования; встройте такой шаг в вариант использования, который его вызывает.

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

Как проверить уровень моря#

Уровень цели пользователя соответствует элементарному бизнес-процессу. Тесты Коберна:

  • Уйдёт ли основное действующее лицо удовлетворённым, сделав это?
  • Тест перерыва на кофе: закончив это, сделаю ли я перерыв?

«Войти в систему» тест не проходит: никто не входит в систему ради самого входа. «Купить лот на онлайн-аукционе» тоже не проходит: покупка растягивается на дни и множество сеансов, значит, это обобщённая цель.

Изредка один вариант использования уровня цели пользователя вызывает другой посреди своего сценария. Например, чтобы взять видеофильм напрокат, может понадобиться сначала зарегистрировать нового клиента. Оба варианта на уровне моря; так бывает нечасто, но это допустимо.

Вверх и вниз: «почему?» и «как?»#

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

Длина как проверка уровня#

У варианта использования на правильном уровне основной успешный сценарий (main success scenario) содержит примерно от 3 до 10 шагов. Коберн пишет, что более длинные сценарии почти всегда выигрывают от сокращения: лишние шаги обычно означают, что в сценарий пробрались детали интерфейса или шаги более низкого уровня.

Как найти самые внешние варианты использования#

Чтобы увидеть границу работы, Коберн предлагает:

  1. Начните с цели пользователя.
  2. Спросите, какому внешнему действующему лицу эта цель в конечном счёте служит.
  3. Найдите самую внешнюю область проектирования, для которой это действующее лицо всё ещё остаётся внешним: обычно это компания, набор интегрированных систем или создаваемая система.
  4. Перечислите все цели пользователя, для которых это действующее лицо — основное.
  5. Сформулируйте обобщённую цель действующего лица по отношению к этой области.
  6. Напишите для неё обобщённый вариант использования, который свяжет все варианты использования уровня моря.

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

У каждого сценария два исхода#

Образ «полосатых брюк» у Коберна (гл. 2) изображает каждый сценарий полосой, которая ведёт в одну из двух штанин: цель либо достигнута, либо нет. Любой сценарий, а не только основной, — лишь один из путей к одному из этих двух исходов. Так обработка неудач с самого начала остаётся в поле зрения.

Как применять#

  1. Перечислите цели каждого основного действующего лица за один заход, не оценивая уровни.
  2. Проведите тест перерыва на кофе для каждой цели и отметьте её как обобщённую, цель пользователя или подфункцию.
  3. Спросите «почему?» о каждой цели пользователя, чтобы найти обобщённые цели; спросите «как?», чтобы найти подфункции, которые стоит сделать общими.
  4. Сначала напишите варианты использования уровня моря. В них содержится бо́льшая часть функциональных требований.
  5. Посчитайте шаги. Если их больше десяти, вынесите детали в подфункции или уберите подробности интерфейса.
  6. Обобщённые варианты использования добавьте в последнюю очередь, чтобы связать варианты уровня моря и показать внешнюю границу.
  7. Пометьте каждое название знаком или значком уровня, чтобы рецензенты знали, чего ожидать.

Пример#

Для «Мастерской» (вымышленной сети веломастерских), где основное действующее лицо — клиент:

Уровень Вариант использования Почему он на этом уровне
Обобщённый (+) Отремонтировать мой велосипед Охватывает бронирование, сдачу велосипеда, ожидание и получение на протяжении нескольких дней
Цель пользователя (!) Забронировать время ремонта Делается за один присест; после этого клиент удовлетворён
Цель пользователя (!) Узнать статус ремонта Короткое законченное обращение
Подфункция (-) Найти свободное время в мастерской Нужна и при бронировании, и при переносе
Слишком низкий Ввести номер телефона Один шаг внутри бронирования

Вопрос «почему клиент бронирует время?» ведёт вверх, к цели «отремонтировать мой велосипед». Вопрос «как?», заданный о бронировании, ведёт вниз, к «найти свободное время» и «идентифицировать клиента».

Подводные камни#

  • «Войти в систему» или «Ввести данные» в роли вариантов использования. Это шаги или подфункции; встройте их.
  • Обобщённые варианты использования, перегруженные деталями. Держите их короткой последовательностью целей уровня моря.
  • Сценарии из двадцати шагов. Вынесите повторяющиеся части в подфункции и уберите формулировки уровня экранов.
  • Уровни без пометок. Тогда рецензенты спорят о детализации, хотя на самом деле расходятся в уровне.

Источники и что почитать#

  • A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000. Рус. изд.: А. Коберн. Современные методы описания функциональных требований к системам. Гл. 2 (вариант использования как контракт о поведении; сценарии успеха и неудачи) и гл. 5 (три именованных уровня целей).