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

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

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

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

Здесь кроется главный парадокс системного анализа: как разделить на части то, чего ещё не существует? Ведь системы ещё нет. Даже если аналитик отвечает за доработку уже существующей системы, то этой доработки ещё не существует в природе, что же делить на части?

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

Что такое требования? Существует несколько определений этого термина.

В стандарте IEEE 610.12–1990: IEEE Standard Glossary of Software Engineering Terminology даются такие определения:

1. Условие или возможность, требуемая пользователем для решения задач или достижения целей.
2. Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующих документов.
3. Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в 1 и 2.

В книге Software Requirements (Developer Best Practices) by Karl Wiegers, Joy Beatty: «Требования — это спецификация того, что должно быть реализовано. Это описание того, как должна себя вести система, описание свойства или атрибута системы. Они могут выступать в качестве ограничений для процесса разработки системы».
В классическом жизненном цикле разработки ПО анализ требований является первым этапом. Проектирование ― следующий после анализа требований этап.

Требований и их источников много:

• бизнес-требования ― у Заказчика;
• требования к интеграции ― у владельцев смежных систем;
• требования к безопасности ― у служб безопасности;
• требования к соблюдению законодательства ― у юридической службы и так далее.

Задача аналитика ― выявить все эти требования у источников, систематизировать и собрать вместе в один всеобъемлющий документ требований. Далее на этапе проектирования на основе этих требований должно быть получено некое проектное решение, которое бы в точности описывало, какой будет система.

Вот что обычно выявляет и систематизирует аналитик в процессе анализа требований к системе:

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

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

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

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

• Вот несколько примеров, когда аналитик в процессе анализа требований может незаметно для себя принять проектное решение.

Почему так происходит?

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

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

Часто для того, чтобы обеспечить критерии качества требований, аналитики незаметно для себя придумывают проектное решение. Упомянули тип системы, какую-то технологию, внутреннее устройство системы, поведение пользователя ― значит сделали проектное решение.

Если грань между требованием и проектным решением так легко переступить, возникает вопрос: а существуют ли они вообще, эти требования к системе?

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

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

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

Рисунок ―  цитата из статьи Пола Ральфа ― канадско-австралийского учёного из сферы инженерии требований (то есть, системного анализа). Пол Ральф глубоко изучает проблемы инженерии требований и пишет много статей на тему работы с требованиями.

D1, D2, D3 на рисунке ― варианты реализации одной и той же функциональности системы. И требования формируются именно на пересечении различных проектных решений. Приведём пример: аналитик пишет требования к выводу данных для пользователя. Вариантов реализации может быть множество: печатная форма, отчёт, таблица, чат-бот и так далее. И требования к функциональности зависят от выбранного способа реализации, например, при выводе данных в таблицу аналитик включит в требования правила сортировки, фильтрации, изменения размера полей и так далее.

Общие для разных вариантов реализации пункты действительно являются требованиями, всё остальное ― аспекты конкретного варианта реализации. В примере требование может звучать так: «Система должна обеспечивать доступ пользователя к данным» или «Система должна предоставлять пользователю данные».

Таким образом в документы требований попадают не всегда обоснованные проектные решения, завуалированные под требования. То есть, произошла скрытая работа по проектированию, результаты которой ушли в разработку.

Некоторые другие тезисы Пола Ральфа:

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

На основе опыта с успешными проектами, с системами, обладающими хорошим дизайном и архитектурой, Пол Ральф даёт такие рекомендации по работе с требованиями.

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

Статьи Пола Ральфа:

1. The Illusion of Requirements in Software Development
2. Иллюзия требований при разработке программного обеспечения. Перевод статьи от Systems Education.
3. Is Requirements Engineering Inherently Counterproductive?
4. How Templated Requirements Specifications Inhibit Creativity in Software Engineering

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

Обычно аналитики проектируют:

• UX ― взаимодействие пользователя с системой;
• структуру хранения данных;
• интеграции ― взаимодействие с внешними системами;
• архитектуру ― внутреннее устройство системы.

В современных проектах становится нормальным, что проектированием всего этого занимается аналитик. Можно сказать, что аналитик, проектируя в этих плоскостях, объединяет обязанности четырёх разных специалистов.

Разберём подробнее каждую из этих плоскостей проектирования систем.

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

Аналитику необходимо ответить на вопросы:

• какая задача стоит у пользователя?
• какие шаги человек проходит в процессе без системы?
• какие решения должен принять пользователь?
• какая информация нужна для принятия этих решения?
• какая информация критически важна, а какая является дополнительной?
• что пользователь должен увидеть, ввести?
• какими объектами реального мира управляет пользователь?

Дополнительные материалы для изучения:

1. Джоел Сполски «Руководство по UI дизайну для программистов».
2. Дэн Браун «8 принципов информационной архитектуры».
3. Стандарты: ГОСТ Р ИСО 9241-210-2016, ГОСТ Р ИСО 14915-1-2016, ГОСТ Р ИСО 14915-3-2016. Стандарты ― это концентрированные знания. Их может быть неинтересно читать, но стандарты четко и без воды описывают основные принципы.
4. Jeff Gothelf, Josh Seiden «Lean UX, 3rd Edition».
5. Курс «Дизайн интерфейсов для недизайнеров» Алексея Копылова.

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

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

Аналитику при проектировании структур хранения данных нужно ответить на такие вопросы:

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

Что нужно изучить аналитику, чтобы успешно проектировать хранение данных:

• индексы, ключи, деревья, шардирование, профайлинг запросов;
• типы данных и языки валидации;
• регулярные выражения и их использование;
• распределение данных по узлам, CAP-теорема;
• транзакции, уровни изоляции, ACID, Saga-паттерн;
• способы хранения данных, виды баз данных и СУБД (реляционные, нереляционные, документоориентированные, базы ключ-значение, графовые базы и т.д.).

Дополнительные материалы для изучения:

1. DAMA DMBoK2: Data Management Body of Knowledge. Всеобъемлющий свод знаний о данных. Книга охватывает большинство аспектов данных и их хранения.
2. Alex Xu. «System Design Interview». Хороший учебник про проектирование современных систем, в том числе про данные, интеграции и архитектуру.
3. Каталог ссылок на тему баз данных и анализа данных.

Проектирование интеграций ― одно из основных требований, которые работодатели предъявляют современным системным аналитикам.

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

• паттерны интеграций;
• разновидности технологий программных интерфейсов, принципы создания и спецификации API: REST / SOAP / GraphQL / gRPC / OpenAPI / AsyncAPI / RAML / шины / брокеры / очереди (message oriented middleware).
• трансформация и валидация данных: XSLT, регулярные выражения;
• сетевые протоколы и форматы: http(s), http/3, xml, json, protobuf, avro, flatbuffers;
• безопасность: OAuth, SSL, OWASP;
• особенности конкретных продуктов: Kafka, Rabbit, KeyCloak и т.д.

Дополнительные материалы для изучения:

1. Хоп Грегор, Вульф Бобби. «Шаблоны интеграции корпоративных приложений».
2. Alex Xu. «System Design Interview».
3. Каталог ссылок на тему интеграций.

Есть два важных аспекта, которые нужно учитывать при проектировании архитектуры системы.

1. Структура команд разработки и коммуникации между ними. Архитектура системы чаще всего повторяет структуру команды, которая разрабатывает систему. Это называется «Закон Конвея».
2. Как система будет развертываться? Кажется, что аналитика такие вопросы не касаются, но на самом деле при проектировании архитектуры важно задуматься о том, можно ли поставлять части системы независимо друг от друга, можно ли их развивать независимо друг от друга?

Что нужно изучить аналитику, чтобы успешно проектировать архитектуру систем:

• кодовая база и распределение задач по командам, Закон Конвея;
• архитектурные стили: монолиты, пайплайны, микросеврисы, EDA;
• сценарии развертывания: DevOps, CI/CD;
• DDD, ограниченные контексты, Event Storming;
• паттерны: Saga, CQRS, SideCar, API Gateway, CircuitBreaker, Event Sourcing, CDC и т.д.;
• нефункциональные требования. Это одна из самых недооценённых тем, которую аналитики изучают меньше всего, несмотря на то, что нефункциональные требования очень сильно влияют на архитектуру системы.

Дополнительные материалы для изучения:

1. Каталог ссылок по теме архитектуры и микросервисов.
2. A pattern language for microservices.

На фоне трансформации профессии аналитика возникает вопрос, а какую же роль выполнять аналитику? Переквалифицироваться в проектировщики или в архитекторы? Или аналитик вообще не нужен?

Вспомним рекомендации Пола Ральфа о том, что процессы структурирования задачи и проектирования решения нужно рассматривать как единое целое. Поэтому аналитикам нужно изучать новые техники проектирования, такие как Event Storming, User Story Mapping, Design Sprint. Эти практики позволяют организовать совместную выработку решений бизнесом и разработкой. В таких практиках аналитик может выступать организатором и фасилитатором ― собрать вместе бизнес и разработку с целью получения наиболее подходящего проектного решения.