В работе аналитика функциональная декомпозиция выглядит чем-то очень базовым и от этого еще интереснее о ней порассуждать.
Строго говоря, декомпозировать можно не только функции, но и процессы, цели, задачи, роли, компоненты ИТ-архитектуры, источники и результаты работы системы. Аналитики чаще всего имеют дело с функциями. С них обычно начинается любой разговор о будущей системе: "Нам нужно, чтобы система умела....."
Вот такая рекомендация есть в книге "Принципы работы с требованиями к программному обеспечению" Дина Леффингуэлла и Дона Уидрига
Количество функций, которое мы позволяем себе рассматривать, будет существенно влиять на уровень абстракции определения. Для того чтобы справиться со сложностью разрабатываемой системы, мы рекомендуем описывать возможности каждой новой системы или дополнения к уже существующей системе как можно более абстрактно, чтобы в результате получить не более 25-99 функций, причем желательно, чтобы их число не превышало 50.
Как не запутаться в таком количестве функций? Постепенно двигаться от высокого уровня абстракции к более детальному, то есть разбирая каждую функцию на составляющие до того уровня, которым будет проще управлять. Количество уровней зависит от объема и сложности задачи. Для небольших задач достаточно глубины в 2-3 уровня, для сложных потребуется больше.
Как это поможет? Разбирая сложное на небольшие измеримые части можно добраться до детального понимания, отследить как связаны между собой эти части и найти точки улучшения.
📍Это помогает выявлять и документировать требования по четкой структуре, соответственно декомпозиции.
📍Обозримая упорядоченная структура помогает понять объем задачи или изменений. Так проще заметить разрастание объема и не потерять фокус на основных целях.
📍Измеримым под-функциям проще определить приоритет и запланировать затраты на разработку.
📍При обсуждениях проще выстроить общее понимание сложной системы, если разделить составляющие на более простые части.
Было бы нечестно промолчать про ограничения:
1. За декомпозиций функций можно упустить другие важные вещи: потоки данных или взаимодействие пользователей. Узкий взгляд именно на функции приводит к потере других важных составляющих системы. Я здесь под "системой" имею в виду именно совокупность взаимодействующих объектов, не обязательно автоматизацию.
2. Декомпозиция часто основана на предположениях о процессах и связях между функциями. Предположения могут быть ошибочными, в результате вместо прозрачности и упрощения привести к путанице и непониманию.
3. При функциональной декомпозиции остаются без внимания нефункциональные требования, о которых важно не забыть.
Каждый сложный объект допускает несколько альтернативных декомпозиций. Исследование всех альтернатив может быть сложной и трудоемкой задачей, тогда как выбор единственной альтернативы может игнорировать важные возможности и привести к неоптимальному решению (Из BABOK 3.0)
4. Для сложных систем иерархия функций может оказаться многоуровневой и содержать непростые зависимости между разными уровнями. Обратите внимание, на картинке дерево функций (Feature tree) из статьи К. Вигерса Using Feature Trees To Depict Scope. Здесь всего три уровня, но выглядит ли картина простой?
Сама по себе функциональная декомпозиция не приведет к пониманию всех связей между элементами системы, но задаст ход мысли от общего к частному и поможет подсветить, где искать эти элементы и связи.