Масштабируемая структура требований
#что_почитать

В выходные было время почитать и встретилась статья, которой хочу поделиться. Это обзор статьи, оригинал по ссылке Splitting Requirements at Scale.

Анализ подразумевает разбивку сложных проблем на более простые, но иногда такая структура выглядит как клубок взаимных зависимостей между ее элементами. По мере расширения процесса такие структуры становятся все сложнее. Как разбить отдельные требования для сложных процессов? В статье приведены примеры подходов к структуре требований.

Пример он-лайн магазина. Шаги процесса могут иметь разные правила в зависимости от категорий товаров: для заказа одежды нужно выбрать размер и цвет, для заказа продуктов нужно указать вес, для заказа напитков нужно указать объем и количество. Так в трех направлениях могут быть разбиты требования. Если предположить, что магазин решит развивать и В2В, и В2С продажи, то вариантов правил для каждого вида заказов становится больше, в каждой категории товаров добавляется два вида сделок, по одному для каждого сегмента клиентов. Структура требований усложнится. А какие еще можно рассмотреть варианты?

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

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

Иерархия требований. Этот подход автор описал как предпочтительный. Требования разбираются на уровни абстракции и образуют иерархию. Например: Уровень процесса, уровень пользователя и уровень системы. Каждый уровень должен представлять проблему или ценность на заданном уровне детализации. Верхние уровни задают контекст для нижних, а нижние детализируют родительские. Пример на картинке ниже. При этом сами требования можно нарезать по структуре организации или решения, а можно по логике процесса end-to-end, что предпочтительнее. Детальные шаги при этом оказываются на самом нижнем уровне

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