В книге описан один метод написания части постановки задачи, а именно метод use case.

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

Пример use case

Как выглядит сценарий, на примере авторизации на сайте через email:

(Системный) Авторизоваться на сайте для доступа в личный кабинет. ~~ (уровень моря)

Контекст: Не авторизованный клиент авторизуется на сайте, чтобы сайт его узнал и показывал персональную для него информацию: историю просмотров, покупок, текущее количество бонусных баллов и пр, используя email как логин. 
Уровень: цель пользователя
Основное действующее лицо: клиент (посетитель нашего интернет-магазина)
Область действия: Взаимодействие клиента с сайтом интернет-магазина
Заинтересованные лица и интересы:

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

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

Основной сценарий:

1. Клиент запускает авторизацию.
2. Система подтверждает, что клиент не авторизован и не превышение количества неуспешных попыток авторизации с данной сессии (поиск слабого пароля у множества аккаунтов) по «Правилу безопасности №23».
3. Система увеличивает счетчик количества попыток авторизации.
4. Система отображает клиенту форму авторизации.
5. Клиент вводит email и пароль.
6. Система подтверждает наличие клиента с таким email в системе и совпадение пароля и не превышение количества попыток входа в данный аккаунт по «Правилу безопасности №24».
7. Система авторизует клиента, добавляет историю просмотра и корзину данного сеанса с последним сеансом этого аккаунта клиента.
8. Система отображает сообщение успешности авторизации и переходит на шаг сценария, из которого клиент прервался на авторизацию. При этом данные на странице перегружаются с учетом персональных данных аккаунта.

Расширения:
2.а. Клиент уже авторизован:
 2.а.1. Система уведомляет клиента о факте осуществленной ранее авторизации и предлагает либо прервать сценарий, либо перейти к шагу 4, при этом если шаг 6 успешно пройден, то 7 шаг выполняется с уточнением:
 2.а.7. Система деакторизует клиента под старым аккаунтом, авторизует клиента под новым аккаунтом, при этом история просмотра и корзина данного сеанса взаимодействия остается в старом аккаунте, в новый не переходит. Далее переход к шагу 8.
2.б Количество попыток авторизации превысило порог по «Правилу безопасности №23»:
 2.б.1 Переход к шагу 4, на форме авторизации дополнительно отображается капча
 2.б.6 Система подтверждает корректный ввод капчи
    2.б.6.1 Капча введена неправильно:
      2.б.6.1.1. система увеличивает счетчик неуспешных попыток авторизации и под данный аккаунт
      2.б.6.1.2. система отображает сообщение о неуспешности и возвращается к шагу 2
6.а. Аккаунта с данным email не обнаружено:
 6.а.1 Система показывает сообщение о неуспешности и предлагает на выбор, либо переходод к шагу 2, либо переход к сценарию «Регистрация пользователя» с сохранением введенного email,
6.б. Пароль от аккаунта с данным email не совпадает с введенным:
 6.б.1 Система увеличивает счетчик неуспешных попыток входа в данный аккаунт.
 6.б.2 Система отображает сообщение о неуспешности и предлагает на выбор, либо переход к сценарию «Восстановление пароля» либо переход к шагу 2.
6.в: Счетчик попыток входа в данный аккаунт превысило порог по «Правилу безопастности №24».
 6.в.1 Система отображает сообщение о блокировке входа в аккаунт в течении X минут и переходит к шагу 2.

Что здорово

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

Работа с системой типа черный ящик позволяет разделить выработку и согласование с заказчиком того, а что же будет автоматизировано от способов реализации.

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

Очень радует в описании место, где выявляются исключения каждого шага взаимодействия. Целостная ИТ система должна предусматривать ту или иную обработку исключений, часть в ручном режиме, часть в автоматическом (как в примере выше).

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

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

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

Дополнение к методу из практики

Use case не является независимо приоритизируемой частью постановки, в отличии от user story.

В указанном сценарии, рассмотрим исключение “6.а. Аккаунта с данным email не обнаружено.” и следующий шаг “6.а.1 Система показывает сообщение о неуспешности и переходит к шагу 2”. Что из негативного осталось за кадром? Для клиента любой возврат равносильно тому, что весь труд который он проделал вводя данных выкидывается на свалку. (В сценарии этого просто так не видно!) Что можно сделать? Перестроить сценарий так, чтобы этого не возникало. Можно ли так сделать? Можно — как пример, посмотрите на сценарий авторизации в Google.

Оптимизация сценария

Книга рассказывает про формализацию, но мало рассказывает про методы оптимизации таких сценариев.

Но возможно усилить метод с помощью оптимизации сценариев и способ формализации use case позволяет это сделать. Конкретно, над каждым возникающим исключением нужно подумать, определить причину и перестроить сценарий так, чтобы избавиться от исключения или минимизировать путь клиента.

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

Если просто описывать сценарий взаимодействия на стадии оформления, то можно записать “сообщить клиенту о невозможности доставки и предложить изменить город или состав корзины” (и многие начинающие аналитики на этом останавливаются). Но если таких случаев достаточно много, то можно оптимизировать сценарий.

Первое что нужно сделать — нужно давать выбрать только тот город, куда мы можем сделать доставку. Когда это делать? Перед моментом выбора товара на сайте (автоопределение города через ip с уточнением).

Второе — нужно давать выбор только того товара, который мы можем доставить клиенту. Когда это делать? В момент выбора — на плитке товаров и карточке товара.

Эти два изменения значительно практически избавляют от этого исключения.

Требования на измерения и метрики

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

Но увы. Опыт показал, что требований на отчетность к сценариям в таким виде недостаточно, нужно рассматривать требования в отчетности на процессы, которые описываются в основном не в виде use case.

Выход на Usability

В нашей практике мы расширили форму описания use case описанием конкретных атрибутов сущностей и данных для принятия решения клиентом, что усиливает последующее юзабилити.

Для проектирования юзабилити мы добавили входной раздел — отображаемые данные.

В сценарии с авторизацией — это факт авторизации клиента в системе. Если клиент предварительно авторизован, то отображать предупреждение о переключении истории навигации и корзины на новый аккаунт после успешности авторизации.

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

В примере с авторизацией клиента, если выделить вводимую информацию на логин и пароль, то стоит изменить сценария авторизации с выделением этапов ввода отдельно логина и отдельно пароля (и это сделано в Yandex, Google, но не сделано в большинстве интернет-магазинов).

Выход на требуемые преобразования данных

Из сценария так же можно вытащить требования к алгоритмам преобразования данных.

Примеры:

• Клиенту для принятия решения о покупке товара в интернет-магазине на карточке товара нужно знать возможность, стоимость, сроки доставки в его город данного товара (которые вычисляются алгоритмом по факту наличия товара на складах и параметров цепочек поставок).
• При вводе фразы в поисковую строку клиенту по алгоритму показываются поисковые подсказки (которые формируются алгоритмом ...).

Итого

В целом, после прочтения книги, к сожалению, не понятно как пройти весь путь аналитика от бизнес-проблем до формализованного ТЗ для разработчика. В книге рассказывается только часть процесса с неясно сформулированными входящими и неясно показанными дальнейшими шагами. Сам по себе use case полной постановкой для разработчика чаще всего не является.

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

Книга обязательна для прочтения аналитиками, чтобы они начали писать проверяемые постановки.