Сегодня поговорим про системный анализ в ИТ, его место, вопросы, на которые он должен отвечать и т. д. А также об одной методике системного анализа.

Как построен нижеследующий текст: всего 16 разделов, из которых в первых 7 я задаюсь общими вопросами про системный анализ, а в следующих 9 фактически предлагаю ясные ответы на эти вопросы. Ответ на каждый следующий вопрос будет логически вытекать из одного или нескольких предыдущих. И я сразу оговорюсь, что для полновесных ответов на эти вопросы потребуется объем книги, а не поста в блоге. Поэтому некоторых тем я буду касаться поверхностно, а также рассчитываю, что читатель знаком с BABOK, PMBOK, трудами Вигерса, RUP (хотя бы слышал про него) и всей вот этой вот базой современного системного ИТ-анализа.

Так вот.

1. Что такое системный анализ в ИТ?

В общем и целом системный анализ – это процесс обследования существующих информационных систем и проектирования новых/изменения существующих информационных систем. И коль скоро это процесс, то есть, строго говоря – функция, для системного анализа можно выделить ряд входных и выходных «объектов».

«Входными» объектами для системного анализа являются:

1. существующие артефакты системного анализа;
2. бизнес-требования;
3. требования со стороны информационной безопасности;
4. системные/архитектурные ограничения.

«Выходными» объектами системного анализа являются:

1. функциональные/нефункциональные системные требования;
2. другие «артефакты» системного анализа, пока абстрактно.

Я не касаюсь здесь мелких процессных вопросов, типа заведения тикетов в таск-трекере – это зависит от того, как сформулированы Definition-Of-Done’ы в каждой конкретной команде разработки, это частность.

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

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

Ну да это нюансы.

2. Кто является адресатом результатов системного анализа?

Из вышенаписанного прямо следует, что адресатами системного анализа являются, как минимум:

1. архитекторы;
2. UX/UI-дизайнеры;
3. разработчики.

Но этот список далеко не полный, потому что в качестве адресатов можно смело указать специалистов на следующих ролях:

1. Системные аналитики. То есть другие системные аналитики, которые должны понимать, в результате реализации каких требования система такова, какова она есть, а также как она вообще работает.
2. Разработчики. У них та же цель – быстро, а не через ковыряние в коде, получить представление о том, как устроена система.
3. Тестировщики. Потому что тестирование по определению – это проверка соответствия функций системы этим самым системным требованиям.
4. Технические писатели. Потому что технический писатель при написании документации должен иметь источник информации о том, как система должна работать на самом деле, а не как она работает не тестовом стенде.
5. Сотрудник технической поддержки. Он должен, как и технический писатель, иметь достоверный источник знаний о том, как должна работать система, чтобы быстро отвечать на вопрос: «В обращении пользователь жалуется на штатную работу системы или это баг?». И пользовательская документация тут не поможет – она просто не освещает (и не должна) некоторые особенности работы системы.
6. Менеджеры по продажам. И причина все та же: нужен источник знаний, который быстро позволит ответить на каверзный вопрос потенциального покупателя системы во время проведения демо.
7. Внезапно, Заказчик в той или иной ипостаси. Он может совершенно легитимно попросить рассказать ему заранее, как будет выглядеть и работать та система, для которой он породил требования. Особенно, если он не только выдал требования, но и деньги на их реализацию. И тогда придется ему показывать макеты форм и объяснять логику их работы, а также рассказывать про «подкапотные» алгоритмы системы. А это все и есть системный анализ – см. выше.

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

3. Системный анализ: проектная или конструкторская документация?

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

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

Простой пример: можно написать системное требование:

«При сохранении заметки Система должна проверять наличие наименования у заметки. Если наименования заметки нет, Система не должна сохранять заметку, отображая сообщение: «Для сохранения заметки введите название заметки»».

Фактически, требование насколько подробное, что функционально реализовать его можно только одним образом: система будет по нажатию кнопки сохранения проверять, есть ли у заметки название, ругаться, если его нет, и ничего не сохранять. А если есть – сохранять.

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

Обнажается эта дихотомия и при более пристальном рассмотрении потребностей адресатов системного анализа:

• Разработчикам (которые будут разрабатывать функциональность), архитекторам, UI/UX-дизайнерам и тестировщикам результат системного анализа интересен и в форме требований, и форме фактического описания.
• Разработчикам (которым постфактум нужно понять, как система работает), системным аналитикам (которым нужно то же самое), технические писателям, сотрудникам технической поддержки, менеджерам по продажам и заказчику результат системного анализа интересен именно в виде описания того, как будущая система будет устроена, как она будет работать внутри и выглядеть снаружи.

Нужны ли кому-то системные требования в чистом виде? Только системному аналитику и заказчику как формализация ожиданий от будущей фичи или системы. Остальным на самом деле интересно описание готового решения.

Получается, что результаты системного анализа должны существовать как бы в двух видах:

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

4. Каков предмет системного анализа?

Два слова про предмет системного анализа.

Вроде все понятно: предмет системного анализа – системные требования к информационным системам и устройство информационных систем.

При этом любая информационная система в общем смысле занята только двумя вещами: она как-то изменяет параметры своих объектов данных или передает их другой системе. То есть, как минимум, любая информационная система имеет свои внутренние алгоритмы, которые, будучи рассмотренными в качестве функций, имеют входные и выходные параметры. А параметрами этими являются данные, которые система хранит или получает от другой системы. Вот эти внутренние алгоритмы я так и буду называть ниже – «внутренние алгоритмы системы».

Еще есть аспект взаимодействия с пользователем, то есть UI. Через этот самый UI система предоставляет пользователю возможность «дергать» себя, систему, за всякое, то есть как-то себя использовать. Дальше я буду называть это пользовательскими функциями.  И если UI в системе присутствует, то введенные пользователем данные также могут быть входными данными для внутренних алгоритмов системы.

Добавим к этому ролевую модель – двухчастное описание того:

1. к каким пользовательским функциям какая роль имеет доступ;
2. к каким объектам данных какая роль имеет доступ.

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

Системные требования (относятся к проектной документации) описывают именно функциональные и нефункциональные, но достаточно верхнеуровневые требования к системе.

Корпус системного анализа – артефакты системного анализа, они содержат фактическое (плановое, строго говоря) описание того, как система будет реализована в части:

1. объектов данных, которые система передает и хранит;
2. внутренних алгоритмов системы, при помощи которых она изменяет параметры объектов данных;
3. пользовательских функций, через которые система предоставляет пользователю те или иные возможности;
4. ролевой модели, которая описывает доступность объектов данных и пользовательских функций для разных системных ролей.

5. Что такое «хороший системный анализ»?

Про качество требований я не смогу сказать ничего нового, все уже десять раз написано в BABOK, SMART, у Вигерса и т. д. Хорошее требование всегда:

1. Однозначно трактуемо. То есть оно сформулировано так, что понять его можно только один образом.
2. Полно. То есть формулировка содержит всю информацию для реализации и проверки данного требования.
3. Выполнимо. То есть реализуемое как принципиально «в вакууме», так и в реальных рамках сроков, компетенций команды и других условий.
4. Проверяемо. То есть можно найти способ приложить к системе «линейку» так, чтобы объективно проверить, выполнено требование или нет.
5. Трассируемо. То есть имеющее конкретную предпосылку или прямой источник.

Для группы требований основное качество – непротиворечивость.

Тут можно спорить, добавлять, убавлять какие-то качества – не важно, сути это не изменит никак. Просто лично мой опыт работы привел меня к тому, что вот эти свойства являются ключевыми.

Что такое качественные артефакты системного анализа в том виде, в котором они обозначены в предыдущем разделе? А тут почти как с требованиями – описание артефакта должно быть:

1. однозначно трактуемым;
2. полным;
3. реализуемым;
4. проверяемым;
5. трассируемым (описание артефакта должно следовать, должно соответствовать какому-то верхнеуровнему системному требованию).

Если внимательно прочитать на написанное в разделе 4, то становится понятно, что ни один артефакт системного анализа не может «висеть в воздухе», артефакты анализа должны ссылаться друг на друга. Например, в корпусе артефактов не должно быть объектов данных, которые не являются выходными или выходными для какого-либо внутреннего алгоритма – иначе это автоматически будет означать, что система хранит то, что не обрабатывает, а это абсурдно.

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

Но это не всё.

Вернемся к потребностям тех, кто заинтересован в результатах системного анализа (см.раздел 3): одной группе этих ролей интересны именно требования, другим – фактическое описание реализации. Из этого следует еще один критерий (не знаю, как обозвать коротко): системный анализ должен быть написан, структурирован и сохранен в системе знаний (обычно это Confluence и ей подобные) так, чтобы можно было быстро найти ответ на вопрос, как должен работать тот или иной кусок системы. Это «структурность», наверное.

И еще было бы хорошо, чтобы:

1. разработке было просто давать оценки по такому системному анализу. Вэйк в своей INVESTABLE прямо называет это «Estimable».
2. можно было быстро собирать описание системы в единый документ (например, технический проект), если того требуют внешние обстоятельства. «Конвертируемость»?
3. можно было бы получать ответы на кросс-системном уровне. Например, нету ли у соседней системы нужного сервиса, который можно у коллег дернуть и не писать свой, чтобы сократить время разработки? «Метаструктурность»!

6. Обычная практика системного анализа: почему она плоха?

Обычная практика в ИТ-компаниях такова: основным результатом работы системного аналитика по задаче является некая «постановка».

Под «постановкой» имеется в виду, конечно, «постановка задачи на разработку». В подавляющем большинстве случаев это единый документ, в котором содержится всё, что аналитик смог собрать для передачи команде программистов, чтобы та выполнила разработку чего-нибудь. Постановки бывают, условно, первичными и инкрементальными. Одни описывают создание новой функциональности (фичи, модуля и т. д.), другие ссылаются на первичную или предыдущую инкрементальную постановку и описывают только модификации/инкремент.

Из этого следует неприятный факт: чтобы понять, как должна работать фича в системе в текущий момент, надо найти первичную постановку, а потом все инкрементальные постановки. Представим себе, что аналитик был молодец, он проставил все ссылки, он предельно ясно связал постановки по одной фиче между собой так, что цепочку можно «размотать» в обратную сторону, от последних требований к исходным. Но даже в этом случае тяжело представить себе:

• Сколько мозговых усилий может потребоваться для «сборки» в голове финального образа функциональности, если система интенсивно разрабатывается несколько лет. Да даже пусть один год. И приходится последовательно читать 10-15 постановок, пытаясь запомнить, что, где и как изменялось.
• Сколько времени потребуется на описанную выше работу.

Именно поэтому почти всегда системный анализ в компаниях не решает проблему хранения знаний – её решает либо лид разработки, либо условный Вася, который пилит свой модуль с самого зарождения системы и потому просто помнит, как и что там работает. Васе обычно платят достаточно много: его знания не отделимы от него самого, поэтому Васина компания вынуждена мириться с Васиными зарплатными ожиданиями и удовлетворять их в полной мере – Вася незаменим. Но код он пишет медленно, потому что все бегают к нему с вопросами по его модулю, чем постоянно его отвлекают. Плюс, у Васи портится характер, потому что такой Вася являет собой классический пример «выгорающей рок-звезды».

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

Если вы работаете в ИТ, вы сталкивались с этим тысячи и тысячи раз.

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

7. Каков уровень абстракции системного анализа и каковы его связи с другими уровнями абстракции?

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

Итак.

Артефакты системного анализа, выведенные в разделе 4:

1. объекты данных;
2. внутренние алгоритмы системы;
3. пользовательские функции;
4. ролевая модель.

Картинка:

Схема не очень точная по форме, зато понятная:

• Внутренние алгоритмы системы обеспечивают работу пользовательских функций и модифицируют объекты данных.
• Пользовательские функции вызывают внутренние алгоритмы системы.
• Системная роль использует пользовательские функции в соответствии с ролевой моделью.
• Ролевая модель ограничивает доступ системных ролей к пользовательским функциям и объектам данных.

При этом:

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

Это системный уровень абстракции. Не самый нижний – ниже лежат уже объекты, методы, классы и прочее из программного кода, – но достаточный для системного анализа. Если возникает необходимость описать реализацию еще более подробно, то такое описание укладывается в документ типа «технический дизайн».

На системном уровне абстракции у нас существуют системные роли и автоматизированные системы в виде акторов, тут нет должностей, бизнес-ролей и вот этого всего. Есть ли на этом уровне абстракции понятие «бизнес-ценности», прости господи? Категорически нет: системный уровень описывает устройство системы, её атомарные функции, а не ценностные смыслы, которые вкладываются в её, системы, использование. Смыслы должны поступать на вход системному анализу, а системный анализ – это описание реализации, это следствие бизнес-запроса.

Для атомарных функций системы пытаться определить бизнес-ценность невозможно. Банально, имеет ли бизнес-ценность функция авторизации пользователя? Функция смены темы оформления? Функция сортировки? Если вам кажется, что да – почитайте мой magnum opus про это.

Как же тогда сделать этот переход на уровень выше, как связать системный и бизнес-уровни? Очень просто – через понимание того, что ценными являются не отдельные функции системы, а их последовательности. Например, для того, чтобы выгрузить из системы отчет, необходимо:

1. авторизоваться;
2. открыть данные, по которым будет строиться отчет;
3. отфильтровать их;
4. выгрузить их в файл.

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

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

Вот такие последовательности я назвал сценариями. Получается следующая картина:

Через выстраивание пользовательских функций в последовательности мы и делаем этот шаг «наверх», на нижний бизнес-уровень абстракции (дальше я поясню, почему это нижний, и где верхний). На бизнес-уровне у нас есть бизнес-роли/должности, которые как-то соответствуют системным ролям (иногда в отношении «многие ко многим»), тут уже есть модель предметной области, которой также соответствует модель данных (обычно объект предметной области «собирается» из нескольких объектов модели данных). Сценарии можно рассматривать как небольшие процессы, манипулирующие объектами предметной области. Например, сценарий подготовки годового отчета (отчет как объект предметной области может состоять из нескольких файлов, то есть быть комплексным объектом с системной точки зрения). Такой сценарий потребует выполнения множества манипуляций, и, вероятно, не в одной системе, но бизнес-ценность будет именно в полной цепочке действий.

А где же бизнес-процессы?

Еще выше:

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

В целом, моя мысль сводится к тому, что если вам понадобятся бизнес-процессы, то они тут тоже есть. Хотя в 99% случаев для создания информационной системы нет необходимости их рассматривать. Зеленый уровень – это просто декомпозиция фиолетового уровня, хотя с точки зрения абстракции это одно и то же.

8. Методика: общий подход

Описанное ниже, это следствие всех вопросов и ответов, что я дал выше.

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

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

У методики, кстати, нет названия, поэтому дальше я буду называть её просто «методика системного анализа».

Общие положения, которые логически вытекают из всего написанного выше:

1. Методика системного анализа должна решать две проблемы: порождения системных требований и порождения фактического (планового, если быть точным) описания устройства системы. И хранения этого в удобоваримом виде, а как обычно.
2. Результаты системного анализа должны быть употребимы всеми заинтересованными лицами – заказчиком, разработчиками, системными аналитиками и т. д. (см. раздел 2).
3. Требования и артефакты системного анализа должны быть хорошими в смысле того, что написано в раздлеле 5.

Дадим определения базовым сущностям методики.

9. Методика: определения

Базовые понятия:

1. Верхнеуровневые системные требования
   Набор функциональных и нефункциональных требований, которые системный аналитик смог собрать из всех известных источников. Могут быть сформулированы с совершенно произвольной подробностью, но это должны быть хорошие требования в описанном в разделе 5 смысле. Каждое верхнеуровневое системное требование должно иметь источник в виде бизнес-требования.
   
   
2. Внутренний алгоритм системы (далее — ВА)
   Реализованный в системе алгоритм, который создает, удаляет или изменяет свойства хранящихся в системе объектов данных и который не может быть вызван, запущен пользователем напрямую, а только через UI системы. Примеры внутренних алгоритмов системы: проверка наличия связи с интернетом, экспорт данных в файл, передача данных от системы к системе.
   
   
3. Пользовательская функция (далее — ПФ)
   Атомарный элемент UI, который позволяет решить пользователю какую-то задачу. Обычно это либо интерфейсная форма, либо её часть. Примеры пользовательских функций: авторизация в системе, поиск документов, экспорт данных в файл.
   
   
4. Объект данных (далее — ОД)
   Сущность, описанная через свойства и связи. Например, если данные хранятся в реляционной БД – это описание таблицы в БД. Примеры приводить не буду, они очевидны.
   
   
5. Ролевая модель
   Артефакт, описывающий системные роли, а также доступные им пользовательские функции и объекты данных. Часто снабжается дополнительными условиями, также влияющими на доступность того или другого (например, все видят документы, но пользователь – только свои, а администратор – вообще все).
   
   
6. Постановка на разработку
   Документ, содержащий бизнес-требования, верхнеуровневые системные требования и ссылки на создаваемые/модифицируемые артефакты анализа, и (ключевое!) обозначающий связь между ними. Иными словами, для каждого артефакта анализа должен быть указан источник в виде верхнеуровневого системного требования, для которого также должен быть источник в виде бизнес-требования.

10. Методика: выбор артефактов

Системы бывают очень разные, поэтому и скоуп артефактов для разных типов систем будет разным.

Может ли не быть пользовательских функций? Да, это система без UI. То есть это полностью автоматизированная система, настраивающаяся через конфигурационные файлы, например.

Может ли не быть объектов данных? Да, например, мы описываем микросервисный бэк, это прям и есть наша система, она вообще не хранит данные.

Может ли не быть внутренних алгоритмов? Пока такого не видел.

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

11. Методика: принципы декомпозиции

11.1 Внутренние алгоритмы системы

В виде внутренних алгоритмов системы системный аналитик описывает:

1. любой «подкапотный» алгоритм;
2. любой интеграционный алгоритм.

Построение отчета в Excel с описанием, откуда какие данные из недр системы берутся и в какие ячейки кладутся; как наша система преобразует данные при получении их из смежной системы; как производится тот или иной математический расчет; как производится обработка ошибок; как определяется наличие или отсутствие связи с интернетом; как формируются уведомления (поп-апы или электронные письма) – все это внутренние алгоритмы системы.

В 99% случаев внутренние алгоритмы – это логика бэка, которая «дергается» по запросу пользователя.

Оставшийся 1%:

1. Логика обработки данных реализована на фронте. Например, веб-система спроектирована плохо, и фильтрация элементов производится на фронте. И тут выбор за вами: описывать это прямо в пользовательской функции или вынести в описание внутреннего алгоритма. Обычно для выбора подхода необходимо ответить на простой вопрос: объемным ли получится описание и будет ли этот алгоритм модифицироваться? Если есть вероятность, что да, будет модифицироваться, и описание будет объемным – выносим отдельно в описание внутреннего алгоритма. Если нет – включаем в описание пользовательской функции (см. следующий раздел).
2. Внутренний алгоритм вызывается другим внутренним алгоритмом. Например, сработал таймер, и система направила письмо пользователю. Так бывает, это нормально.
3. Внутренний алгоритм вызывает пользовательскую функцию. Классический пример – отображение уведомлений. Система начала взаимодействие с пользователем первой, так сказать. И это тоже нормально.

Отмечу, что часто системный аналитик способен наметить общую канву работы алгоритма, но не способен сформулировать его описание полностью – например, он не хочет «вторгаться на территорию разработки» и принимать некие решения за разработчиков. Тогда предлагается описать не сам алгоритм, а требования к его работе.

11.2 Пользовательские функции

Фактически (см. определение выше), одна пользовательская функция — это одна форма. Но есть нюансы:

1. Нет смысла выносить в отдельные описания формы для подтверждения действий (типа «Вы правда хотите удалить <что-нибудь>?» — «Отмена»/«ОК»).
2. В рамках одной ПФ можно и нужно описывать несколько форм, если в рамках логики использования системы эти формы всегда используются в определенной последовательности и никогда не используются по-отдельности где-то еще. Пример: визард создания какого-нибудь объекта, типа диаграммы или чего-то такого – все формы-шаги визарда можно описать в одной пользовательской функции.
3. В некоторых случаях UХ системы устроен так: есть некая основная форма с кучей областей и элементов (посмотрите на любой почтовый клиент, например). Через основную форму пользователь получает доступ ко всей остальной функциональности. В этом случае стоит не запихивать описание всей этой формы в одну ПФ, а сделать этакую «заглушку», «мэппер», в которой показать функциональные области этой формы и описать их отдельно.

11.3 Объекты данных

Тут мне вообще ничего сказать, кроме того, что в объекты данных не надо пихать описание всей БД (это контент архитектурного артефакта, либо технического дизайна). Не надо описывать, например, вспомогательные таблицы реляционных БД, которые нужны для организации связей типа «многие ко многим».

12. Методика: шаблоны артефактов

12.1 Шаблон описания внутреннего алгоритма системы

1. Источник
Ссылка на постановку.

2. Ссылка на тикет
Ссылка на разработческий тикет в таск-трекере.

3. Назначение
Тут пишем коротко, что делает данный алгоритм.

4. Входные данные
Перечень входных данных, представленных в виде ссылок на объекты данных либо на поля форм, описанных в рамках пользовательских функций.

5. Выходные данные
Аналогично предыдущему пункту.

6. Описание/требования
Тут приводим либо пошаговое описание алгоритма, либо требования к алгоритму, если сразу не можем принять решения, как это будет работать. Если вы описываете интеграционную функцию, то именно тут найдется место для диаграмм последовательностей, джейсонок и вот этого всего.

12.2 Шаблон описания пользовательской функции

1. Источник
Ссылка на постановку.

2. Ссылка на тикет
Ссылка на разработческий тикет в таск-трекере.

3. Назначение
Тут пишем коротко, какую возможность предоставляет система пользователю при помощи данной функции.

4. Описание

Первое – это скриншот, которым должна сопровождаться любая ПФ по определению. Откуда берется скриншот: иногда макет рисует аналитик, специалист по UI/UX дорабатывает; иногда сразу рисует дизайнер.

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

1. Наименование
   Для кнопки – надпись на кнопке, для иконки – просто сама иконка, для поля ввода – текст рядом, тут все более-менее понятно.
2. Тип элемента
   Можно указывать прям четко, типа «радио-кнопка», а можно писать по сути: «поле ввода», «бинарный выбор», «выбор из списка» и т. д. Какой конкретно это будет элемент – решение на стороне UX/UI, вообще говоря.
3. Тип заполнения
   Ручной/автоматический. Если «автоматически» – в столбце комментария можно дать ссылку на внутренний алгоритм, который это значение формирует.
4. Источник
   Тут указываем прям конкретику: табличку и её поле в реляционной БД, запрос, который заполнит список и т. д. Если для элемента можно указать источник – не поленитесь, дайте ссылку на описание объекта, из которого нужное значение берется, в столбце комментария.
5. Допустимые значения
   Если что-то можно вводить пользователю, то какие есть ограничения.
6. Условие доступности
   Например, кнопка «Дальше» доступна только после выставления флага о принятии пользовательского соглашения.
7. Значение по умолчанию
8. Комментарий
   Любые другие интимные подробности, которые не уместились в предыдущие пункты.

Естественно, не все эти столбики всегда нужны.

Естественно, в части случаев некоторые свойства будут заполняться прочерками: у кнопок обычно нет источника или допустимых значений.

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

12.3 Шаблон описания объекта данных

1. Источник
Ссылка на постановку.

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

Мне приходилось писать вот такой текст: «В объекте хранится информация о работе флокуляционно-коагуляционной установки (ФСУ). ФСУ отделяет твердую фазу от жидкости в буровом растворе, который уже был использован и далее был отправлен на утилизацию. Твердая фаза собирается в контейнеры и захоранивается в специально отведенные места. Вода возвращается обратно в технологический цикл и используется для приготовления новых объемов бурового раствора.» Потому что нормальный человек не обязан знать, что такое флокуляционно-коагуляционная установка.

2. Таблица в БД
Приводим наименование таблицы в БД, если работаем с реляционной БД. Для других типов БД это будет что-то другое, но лично я имел дело в основном с PostgreSQL.

3. Описание
Для реляционной БД  – табличка со столбиками:

1. Наименование атрибута
   Человекочитаемое название.
2. Наименование в БД
3. Тип
4. Комментарий
   Тут, опять же, описываем, например, как трактуются значения атрибута в том или ином случае, какими значениями наполняются перечисления и т. д.

12.4 Шаблон описания ролевой модели

1. Перечень системных ролей

Наименование роли	Системное наименование	Описание
Роль 1
Роль 2
Роль n

2. Доступность пользовательских функций

ПФ	Роль 1	Роль 2	Роль n
ПФ1
ПФ2
ПФn

3. Доступность данных

ОД	Роль 1	Роль 2	Роль n
ОД1
ОД2
ОДn

12.5 Шаблон постановки

1. Термины и сокращения

2. Ссылка на <источник>
Конкретика сильно завязана на процессы внутри компании, но тут должна быть ссылка на источник, из которого берется данная постановка: план разработки, письмо заказчика, вижн, роадмэп и т. д. Главное, чтобы в этом источнике были сформулированы бизнес-требования, которые являются входной информацией для этой постановки.

3. Функциональные требования

Бизнес-требование	Верхнеуровневое системное требование	Соответствующие артефакты анализа

В каждой строке таблицы указывается:

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

4. Нефункциональные требования
Аналогично предыдущему пункту.

Еще в данный раздел можно добавить отметки о согласовании – в разделе 15 я поясню, откуда они берутся.

13. Методика: наименование и хранение артефактов

Наименования всех артефактов являются сквозными для системы и формируются по одной и той же схеме:

1. Код системы/проекта
   Можно взять из таск-трекера или придумать, не суть.
   Например, «REPORTS».
2. Тип артефакта сокращенно
   ПФ, ВА или ОД, соответственно.
3. Порядковый номер артефакта
   В рамках типа.
4. Наименование артефакта

Пишем это все через точку.

Получается что-то типа:

• REPORTS.ПФ1.Авторизация
• REPORTS.ОД1.Пользователь (user) (для объектов данных можно сразу указывать наименования таблиц, например)
• REPORTS.ВА1.Экспорт отчета в файл

Как хранить артефакты – в соответствующих разделах системы хранения знаний. Буквально:

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

Можно подписывать к названиям постановок и артефактов префиксы 🔍 и ✅, например, которые будут обозначать, что над статьей идет работа, или же работа закончена.

Можно группировать пользовательские возможности в рамках функциональной области, например «Работа с отчетами», «Работа с заявками».

Можно группировать внутренние алгоритмы по типам, например сложить под один «корень» все интеграционные алгоритмы.

Конкретика не так важна, как общее понимание, что можно сделать еще удобнее. Но как конкретно – зависит от ситуации, системы, проекта и т. д.

14. Методика: дополнительные артефакты

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

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

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

Диаграмму артефактов анализа
Единая «карта» описания системы в рамках предложенных артефактов. Пример:

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

Если по вышеописанному принципу делается системный анализ не для одного, а для группы проектов, все становится еще интереснее.

Кросс-системные перечни артефактов анализа.
Например, на странице «Объекты данных» автоматически собираем все дочерние страницы, а потом на одной странице вставляем инклуды страниц «Объекты данных» из раздела системного анализа разных систем.  И вот уже у нас есть полный перечень объектов, которые хранятся в нескольких системах, на одной странице. Предстоят интеграции, надо быстро сориентироваться, как в разных системах представлен один и тот же объект, – такая страница становится бесценной.

(верхнеуровневые) Интеграционные схемы
Схемы с указаниями систем приемников и источников, а также со ссылками на артефакты типа «внутренний алгоритм», в которым описаны интеграции. На примере двух систем:

Схема бесценна вообще для всех (из перечисленных в разделе 2).

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

15. Методика: процессная часть

Артефакты не отделимы от процессов, поэтому я просто обязан сказать несколько слов про процесс, который связан с вот так устроенным системным анализом.

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

Поэтому на первом этапе системный аналитик берет шаблон постановки, переносит в раздел 3 шаблона постановки полученные бизнес-требования и формализует их до верхнеуровневых системных требований. Обычно этот процесс укладывается в несколько итераций: системный аналитик предлагает варианты, заказчик/владелец продукта думает, что-то нравится, что-то обсуждается, и так несколько раз. В конце концов, верхнеуровневые системные требования согласуются (и вот именно поэтому я говорил о возможности добавления отметок о согласовании в шаблон постановки).

Далее наступает черед описания артефактов анализа. В процессе их формирования системный аналитик советуется и показывает промежуточные результаты команде разработки. Ну, чтобы потом не выяснилось, что аналитик напридумывал откровенную хрень. Когда работа над артефактами анализа закончена и получен апрув в части реализуемости со стороны разработки (обычно, лидов бэка и фронта), можно показать артефакты заказчику, чтобы тот четко понимал, что получится в итоге. Обычно заказчик оценивает будущую функциональность через визуальную составляющую, то есть показывать ему надо прежде всего артефакты типа «Пользовательская функция». И не надо пытаться сразу привлекать дизайнера для рисования красивых картинок – может оказаться, что их надо сильно изменить, что значительно быстрее сделать на wireframe-макете, чем в фигме. Так или иначе, описание артефактов анализа заказчик согласует.

Ну этом месте основная часть системного анализа закончена, а согласование артефактов анализа тоже можно как-то отметить в самой постановке.

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

Ключевое: системный анализ – требования и артефакты – формируются поэтапно и связно. Про каждое требование и артефакт системный аналитик должен быть способен ответить на вопрос: откуда оно взялось, какое бизнес-требование ему предшествовало, кто и когда его согласовал.

16. Методика: FAQ

16.1 Как поддерживать версионность артефактов анализа АА (артефактов анализа)?

Малый объем модификаций АА – необходимо отобразить единичное изменение в описании одного АА. Рекомендуется просто скорректировать описание существующего АА, выделить новое фиолетовым (если что-то удалили – зачеркиваем и выделяем фиолетовым).

Средний объем модификаций АА – необходимо отразить в описании АА небольшой объем модификаций, что приведет к созданию новых версий небольшого количества АА. В этом случае рекомендуется:

1. Создать дочернюю страницу с указанием версии в префиксе названия.
2. Перенести описание с корневой страницы на новую дочернюю (сохранить текущую версию АА).
3. Скопировать дочернюю страницу на том же уровне, увеличить номер версии в названии.
   
   Удалить содержимое корневой страницы и вставить на ней инклуд с новой версии (созданной на предыдущем шаге).
   
   Иными словами, при необходимости создания версий описания АА страницы с различными версиями должны являться дочерними, а корневая страница описания АА является инклудом с последней актуальной версии. В версии N+1 описания АА отметить фиолетовым (если что-то удалили – зачеркиваем) изменения относительно предыдущей версии.

В постановке, если у АА есть версии, дается ссылка на конкретную версию, а не на корневую страницу.

Большой объем модификаций АА – необходимо отразить в описании АА большой объем модификаций, что приведет к созданию новых версий большого количества АА. Например, начинается новый этап проекта. В этом случае рекомендуется целиком скопировать структуру описаний всех АА и поместить её в новую папку (например, «Этап 2») и проводить все дальнейшие модификации описаний АА в этой структуре.

16.2 А есть примеры?

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

16.3 А не до фига ли времени будет занимать подготовка такого системного анализа?

До фига. И самое интересное, что это нормально. Для многих открытием является тот факт, что непосредственно написание программного кода в цикле разработки программного обеспечения внезапно не занимает большую часть времени. Нормально сделанный системный анализ, фактически, заставляет вовремя задать и решить все вопросы. Заставляет думать прежде, чем делать. Поэтому да, такой анализ будет занимать довольно много времени, зато сроки разработки сократятся, снизится количество ошибок, количество случаев, когда заказчик хотел одно, а вы сделали другое. И тестировщикам будет сильно легче, и вообще всем остальным интересантам (см. раздел 2). Анализа станет по проценту занятого времени больше, а темп и качество разработки вырастут. Говорю как пробовавший и наблюдавший этот эффект вживую.

И вот только давайте не будем спорить про Agile и «Working software over comprehensive documentation». Есть очень и очень мало людей, которые понимают, как надо применять Agile, где этот самый Agile нужен (особенно на российском «рынке» курпных корпоративных систем), и сколько стоит применение Agile на самом деле.

16.4 Все понятно, но как начать? Система уже есть, а вот такого анализа по ней нет. Это ж сколько времени надо потратить для его написания!

Знакомая ситуация, из которой есть два выхода:

1. Вы тратите время на создание полного системного анализа как бы постфактум. Можно прямо взять на это время, сделать задачу, можно размазать это время тонким слоем по оценкам задач на следующие несколько месяцев. И сделать.
2. Вы не пытаетесь объять необъятное и используете, как говорил один мой коллега, «стратегию маленьких побед». Просто при подготовке анализа по новым фичам вы начинаете работать по методике. Например, надо описать приращение пользовательской функциональности: теперь можно не просто смотреть на отчет, а экспортировать его в файл. Опишите только ту часть артефактов, которая нужна: форму просмотра (в виде ПФ), алгоритм выгрузки (в виде ВА), нужные этому алгоритму объекты (в виде ОД). Через некоторое время по ходу выполнения модификаций системы во получите полный корпус анализа.

В качестве заключения

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

Как видно из описанной методики, она позволяет породить хороший системный анализ. Предложенная методика уделяет большое внимание не только, и даже не столько требованиям, сколько созданию описания того, как система будет работать, а также хранению и модификации этого описания. Что, в свою очередь, позволяет не только поддерживать постоянно актуальное описание системы – её пользовательских функций, внутренних алгоритмов и объектов, – но также и не терять связь этого описания с требованиями, в результате которых система и приросла описанной функциональностью. Отдельным плюсом является и быстрое погружение нового специалиста (любого профиля) в проект, потому что найти информацию о системе становится очень и очень просто, особенно если поддерживаются дополнительные артефакты.

У меня нет никаких иллюзий на тему того, что эта методика подойдет для любой компании – нет, скорее всего, потребуются небольшие модификации. Моя практика показывает, что в большинстве компаний нет вообще никакой методологии в части анализа, большинство компаний либо не дошли до этого уровня зрелости, либо не имеют на это времени и/или компетенций. Эти компании, уверен, проживут недолго по сравнению с теми другими, которые вовремя осозн́ают важность выработки какого-то консолидированного подхода к анализу.

Такие дела.