Сегодня — про скоуп (solution scope, project scope), границы решения (что это, как выглядит и что полезного стоит помнить). Аналитики понимают это как высокоуровневое (”общими мазками”, “с высоты полета птички”) наполнение решения. Т. е. как ответ на вопрос “А что там вообще будет в решении?”, причем не в виде спеки на 300 страниц.
Скоуп полезно формировать и держать в фокусе как 1) на старте проекта (в контексте стратегического анализа/discovery), т. е. когда мы укрупненно прорабатываем, чем будет наполнено решение, так и 2) на протяжении всего проекта, т. к. команде нужно по каким-то единичкам структурировать работу (планировать, отслеживать, итеративно прорабатывать).

Дабы попилить решение на эти самые единички, есть ряд известных техник:

1. Фичи (Features). Фича — это логический кусок решения. Степень абстракции фич и количество уровней в их картине — на наше усмотрение и должны лишь служить цели иметь скоуп кратеньким, наглядным и полным (об этом ниже). Примеры фич и подфич, которые их детализируют, для Telegram: Работа с сообщениями (Текстовые сообщения, Аудиосообщения, …), Управление контактами (Добавление контакта, Удаление контакта…), Настройки (Картинка профиля, Базовые данные профиля, …).

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

Визуализация — сила, а потому для фич в этом плане можно использовать Feature tree.

2. В Agile-разработке для цели “порубить систему на куски” есть пользовательские истории (User Stories). Если US для этого слишком мелки (а им стоит таковыми быть для удобства разработки), вводят новые уровни структуризации: эпики, темы инициативы, стримы и т. п. Общесистемные нефункциональные аспекты с помощью US также вполне себе можно донести.

US можно визуализировать с помощью User Story Map. И не только визуализировать: эта техника еще и позволяет их планомерно идентифицировать, отталкиваясь от конечных пользователей, когда на входе понимания скоупа нет.

3. Варианты использования (Use Cases). С рядом ограничений, но тоже подходят для целей скоупа. UC акцентируют, что полезного с системой может сделать пользователь. И в этом и есть их ограничение в контексте данной задачи: представьте, если в системе у нас всего одна полезная операция для юзера. Едва ли скоуп из одного элемента будет нагляден. Да и нефункциональные характеристики в виде UC мы не очертим.

Визуализация также в наличии — Use Case Diagram.

Общая рекомендация: использовать 2 для agile-проектов; если же user stories не по душе и нет ни опыта, ни желания постигать их дзен, использовать 1 или 1 и 3 в связке. Go-to подход по умолчанию может быть разным, в зависимости от того, какая среда воспитала в нас аналитика. Для меня, например, это 1, плюс дополнить пунктом 3, если хочется ещё и юзерам поэмпатировать.