Решил попробовать с помощью use cases описать требования к сайту, создаваемому на платформе CMS Drupal. Drupal - это типичный фрисофт модульной конструкции. То есть есть компактное ядро, к которому друпалеры разрабатывают модули для реализации конкретного функционала и выкладывают в общий доступ. Постепенно в сообществе накапливаются сотни модулей на все случаи жизни. Несколько десятков из этих модулей настолько популярны, что их функционал и поведение известны всем разработчикам, и они являются de facto стандартными.
  Естейственно, при разработке хотя бы чуть-чуть специфического сайта возникает необходимость кастомизации (модификации поведения) некоторых модулей. Технически это не вызывает никаких проблем, т.к. все модули в комментированных исходниках, надо просто переписать соответствующие места в шаблонах PHP или переопределить функции javaScript.
На начальном этапе все выглядело неплохо: я написал пользовательские истории (пользовательские use cases), они на ура были согласованы с заказчиком; специалист по Друпалу подобрал состав модулей, наиболее близко обеспечивающих нужное поведение.
 
  Далее возникло следующее противоречие.
  С одной стороны, детальное описание юз кейзов, реализуемых системой, достаточно бессмысленно. Все равно 95% поведения системы определено стандартными модулями, и совершенно нецелесообразно как что-то в этом поведении менять, так и документировать его. Документировать стандартное поведение представляется нецелесообразным, т.к. эта документация не нужна ни разработчикам (уже все разработано), ни тестировщикам (уже протестировано), ни пользователям (они считают стандартное поведение само самим разумеющимся). НО! Надо описать, в чем должны состоять ОТЛИЧИЯ требуемого поведения ОТ СТАНДАРТНОГО. То есть напрашивается некая диаграмм вариантов использования с зависимостями не типа <<include>>, а что то вроде <<replace>>.
То есть описание может выглядеть как-то так: "При просмотре новостей пользователь работает с сайтом в соответствии со стандартным сценарием просмотра новостей с использованием модуля view, за исключеним того, что в главном потоке ВМЕСТО стандартной последовательности действий системы при щелчке по заголовку новости  в списке новостей делается то-то и то-то...

  С другой стороны, стандартное поведение модулей Drupal все же не так известно людям, как стандартное поведение компонентов UI Windows. И если я с чистой совестью могу при описании Windows-приложения сослаться на то, что поведение компонентов должно соответствовать  UX Interactions Guidelines, то при ссылке на стандартное поведение модулей Drupal я рискую получить полное непонимание некоторых читателей документации (уже получаю).

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

  Нет ли у кого опыта применения use cases в такой ситуации?
  Может быть лучше и не пытаться их здесь использовать?

По моему мнению, в данном случае, оптимальнее ограничиться функциональными требованиями. В которых и описать именно ту функциональность, что отличается и ее требуется создать. А use cases оставить в покое

Возможен вариант, который написал 474. Это минимизирует трудозатраты Аналитика и увеличит понимание разработчиков. Но в данном случае будет не понятен бизнес-пользователям.

С другой стороны Вы ИМХО путаете понятие Пользовательских требований и постановка задачам разработчикам. Это две разные вещи. Пользовательские требования должны включать все ВИ, которые хочет пользователь. Постановка задачи может включать в себя, только то, что нужно доработать.

Возможен вариант, который написал 474. Это минимизирует трудозатраты Аналитика и увеличит понимание разработчиков. Но в данном случае будет не понятен бизнес-пользователям.

  Это и наблюдается сейчас.

С другой стороны Вы ИМХО путаете понятие Пользовательских требований и постановка задачам разработчикам. Это две разные вещи. Пользовательские требования должны включать все ВИ, которые хочет пользователь. Постановка задачи может включать в себя, только то, что нужно доработать.

   Так и есть, пользовательские ВИ прошли на ура, сильно помогли при согласовании с заказчиком. Теперь хочется написать что-то такое, чтобы программист не просто получил перечень необходимых изменений, но и представлял, как с этим будет работать пользователь. А то у веб программистов сплошь и рядом встречается, что в принципе весь функционал реализован, но переходы от функции к функции очень неудобные - оказывается, они при разработке по другому представляли себе последовательность работы пользователя.
  Я пока что склюняюсь к варианту "система вместо того чтобы сделать А, делает Б". К тому же программисту в таком случае легко найти в коде то место, где делается А.
  Если далее будут разрабатываться другие сайты на основе этого же набора модулей, я сохраняю все стандартные юз кейзы, и вношу изменения только в модифицирующие. "Вместо того, чтобы сделать А сделать C" и т.д.

Может быть вам нужно описать низкоуровневое взаимодействие пользователя и системы? Без описания контекста.

div,

Реальный пример приведите, а то не совсем понятно.

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

...
15. Фоторедактор перемещает и масштабирует карту так, чтобы в окне находился нужный ему район.
16. По завершении перемещения/масштабирования Система отрисовывает попадающие в окно фототочки и группы, раскрывает/формирует группы согласно правилу 4 (Отображение групп), перезапрашивает в качестве изображения фото для ленты те фото, точки которых попадают в окно ^*.
17...
..
___сноска________
^* <Вместо стандартного> Модуль gmaps перезапрашивает для ленты фото текущей коллекции, находящиеся в раскрытых группах.