Школа
системного анализа
и проектирования

Профессия «Системный аналитик информационных систем для бизнеса»

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

Профессия «Системный аналитик информационных систем для бизнеса»

Раздел II. Анализ информационных систем для бизнеса

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

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

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

Глава 11 — «Ах, вот почему все ругают требования!» — покажет, что вы не один.

В 12-й главе анализируется, зачем нам моделирование «до уровня UML» и почему Domain-Driven Design спасает, когда UML-модели перестают быть полезными.

Если же вы застряли в вопросах интерфейсов или пользовательских сценариев, загляните в главу 13 — проектирование использования, UI/UX. Надо разобраться с концептуальным дизайном?

Глава 14 расскажет, как разложить систему на части ещё до детальной проработки.

И наконец, в 15-й главе — внутрисистемный анализ с разработкой функциональных требований, выявлением технических ограничений и критериев качества.

Возможные инсайты с Вашей стороны: «Подождите, то есть сценарии использования — не просто красивый текст, а инструмент для реального UX?» и «М-да, если бы мы если бы мы сделали концептуальное проектирование в прошлом проекте, не пришлось бы потом переделывать половину интеграций».

Глава 9. Бизнес-анализ, бизнес-моделирование и бизнес-проектирование

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

В этой главе мы рассмотрим, как аналитик исследует и понимает бизнес, выявляет потребности и формирует бизнес-требования, а также как обосновывает и защищает концепцию решения.
9.1. Исследование и понимание бизнеса
Рис.9.1.1. — Этапы исследования бизнеса
Первый шаг в любом проекте автоматизации бизнеса — понять, что представляет собой организация (или рынок, если речь идёт о внешнем продукте), и какие у неё цели:

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

2. Анализ стратегии и ключевых показателей
  • Какие высокоуровневые цели ставит топ-менеджмент? Рост выручки, выход на новые рынки, снижение издержек, повышение клиентской удовлетворённости?
  • Какие KPI (ключевые показатели эффективности) отслеживаются?

3. Сбор исходных данных
  • Изучение внутренней документации: отчёты, регламенты, инструкции.
  • Проведение интервью с топ-менеджментом, руководителями отделов.
  • Анализ метрик и статистических отчётов, если уже ведётся учёт показателей.

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

9.2. Моделирование процессов
Рис.9.2.1. — Этапы моделирования бизнес-процессов
Один из центральных инструментов бизнес-анализа — это описание и анализ бизнес-процессов. Процессы отражают, как организация производит продукт, оказывает услугу или выполняет внутренние функции (бухгалтерия, закупки, кадры).

Ключевые моменты при моделировании процессов
1. Выбор нотации
  • BPMN (Business Process Model and Notation) — стандарт де-факто для визуализации процессов.
  • UML Activity Diagram — упрощённый вариант, но тоже популярен в ИТ.
  • EPC, IDEF0 — альтернативные методологии, применяемые в некоторых отраслях.

2. Сбор информации о шагах процесса
  • Как начинается процесс, какие есть входные данные, кто (какая роль) отвечает за каждый шаг, какие документы или системы используются?
  • Важно фиксировать реальные шаги, а не «как должно быть по инструкции». Часто реальность расходится с формальными регламентами.

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

4. Формирование текущей (AS-IS) и целевой (TO-BE) модели
  • Текущая модель показывает, как процесс устроен сейчас.
  • Целевая модель описывает, как будет выглядеть процесс после внедрения изменений или новой ИС.

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


Рис.9.2.2. — Пример процесса утоления голода в нотации BPMN
Читайте наши статьи по теме:
9.3. Структурное моделирование бизнеса
Рис.9.3.1. — Структурное моделирование бизнеса
Помимо процессов, важно понимать организационную и информационную структуру бизнеса:

1. Оргструктура
  • Какие подразделения (отделы, департаменты) существуют, как они связаны?
  • Какие роли и зоны ответственности закреплены за каждым подразделением?

2. Роли и иерархии
  • Кто принимает стратегические решения?
  • Какова схема подчинения (линейная, матричная, проектная)?

3. Анализ данных
  • Какие основные сущности (клиенты, заказы, товары, контракты)?
  • Как данные хранятся и кто отвечает за их актуальность?

4. Взаимосвязь бизнес-процессов
  • Один процесс может зависеть от результатов другого (например, оформление заказа зависит от статуса склада, финансов, согласования договора).
  • Выявление «пересечений» процессов помогает понять, где нужна интеграция в рамках информационной системы.

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

9.4. Выявление и моделирование потребностей
Рис.9.4.1. — Выявление и моделирование потребностей
Как только аналитик имеет общее представление о бизнесе и его процессах, наступает очередь выявления потребностей (Needs):

1. Выявление «болей»
  • Где бизнес несёт наибольшие затраты или теряет клиентов из-за ручных процессов или задержек?
  • Какие «узкие места» мешают компании масштабироваться или повышать качество?

2. Формулирование целей
  • Цели могут быть количественными (сократить время обработки заказа на 30%, повысить конверсию с сайта на 15%) или качественными (улучшить удобство пользования системой для операторов колл-центра).
  • Важно договариваться со стейкхолдерами о конкретных метриках, которые позволят понять, достигнута ли цель.

3. Приоритизация
  • Потребности стоит распределять по степени важности и срочности.
  • Варианты методик приоритизации: MoSCoW (Must, Should, Could, Won’t), Kano, Weighted Shortest Job First (SAFe) и т. п.

4. Моделирование потребностей
  • Можно использовать Use Case (сценарии) или User Story (формат «Как [роль], я хочу [действие], чтобы [результат]»), дополняя их бизнес-контекстом.
  • Создание Customer Journey Maps для понимания пути клиента или сотрудника при взаимодействии с системой.
9.5. Анализ бизнес-проблем
Рис.9.5.1. — Диаграмма Исикавы по анализу корневых причин неэффективности бизнес-процессов
Часто в ходе работы выясняется, что корень проблемы не всегда в отсутствии функционала. Возможно:
  • Неверные KPI: компания измеряет показатели, которые искажают мотивацию сотрудников.
  • Сложная оргструктура: слишком много «горизонтальных» или «вертикальных» согласований.
  • Нехватка компетенций: сотрудники не умеют эффективно пользоваться существующими системами.
  • Недостаточно данных для принятия решений (отсутствие аналитической надстройки над базовыми операциями).

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

9.6. Бизнес-требования
Рис.9.6.1. — Составные части бизнес-требований
Бизнес-требования — это высокоуровневые заявления о том, каких целей хочет достичь организация и какие ограничения существуют. Они задают «рамку» для будущего решения.

1. Формат бизнес-требований
  • Документ Vision & Scope (видение и границы проекта), где описываются ключевые цели, целевая аудитория, ключевые возможности и ограничения.
  • Краткие «epic»-уровневые описания, которые далее декомпозируются в более детальные требования.

2. Соответствие стратегии
  • Бизнес-требования должны согласовываться со стратегическими целями и принципами компании.
  • Например, если стратегия — «максимально ориентироваться на клиента», то система должна обеспечивать быструю обратную связь, хранение истории взаимодействий и т. д.

3. Связь с финансами
  • Часто в бизнес-требованиях присутствует указание на бюджет, ROI (окупаемость инвестиций), рентабельность или сроки выхода продукта на рынок.
  • Эти финансовые аспекты тоже нужно учитывать при дальнейшей детализации.
Рис.9.6.2. — Пример дробного описания бизнес-требования
Читайте наши статьи по теме:
9.7. Экономический анализ и моделирование
Рис.9.7.1. — Оценка стоимости проекта
Крупные проекты требуют экономического обоснования. Системный аналитик вместе с бизнес-аналитиком или финансовым подразделением может участвовать в:

1. Оценке стоимости проекта
  • Затраты на разработку/внедрение, инфраструктуру, лицензии, обучение персонала.
  • Дополнительные скрытые затраты (сопротивление изменениям, временный спад производительности в период перехода и т. д.).

2. Расчёте выгод
  • Сокращение времени цикла процессов, уменьшение ручного труда, снижение количества ошибок и возвратов.
  • Увеличение конверсии продаж, повышение среднего чека, выход на новые рынки.

3. Построении моделей ROI, TCO
  • ROI (Return on Investment) показывает, когда проект окупится и какую прибыль принесёт в перспективе.
  • TCO (Total Cost of Ownership) учитывает полные затраты владения системой (включая поддержку, обновления, масштабирование).

4. Сценарном анализе
  • Оптимистический, пессимистический и средний сценарии реализации.
  • Учёт рисков (например, возможные задержки, изменение курса валют, уход ключевых сотрудников).
9.8. Постановка бизнес-целей и бизнес-ограничений проекта автоматизации
Рис.9.8.1. — Определение бизнес-целей и ограничений проекта автоматизации
На основе проведённого анализа формируются конкретные бизнес-цели (Business Objectives) и ограничения (Constraints) проекта автоматизации:

Пример целей и ограничений проекта:

1. Цели
  • «Увеличить продажи в онлайн-магазине на 20% за год».
  • «Сократить время выпуска финансового отчёта с двух недель до трёх дней».
  • «Повысить удовлетворённость клиентов до N баллов по опросу NPS».

2. Ограничения
  • Сроки (например, релиз к конкретной дате или событию).
  • Бюджет (строгий лимит на разработку/лицензии).
  • Регуляторика (соответствие стандартам безопасности, защите персональных данных).
  • Технологические (необходимость использовать определённые платформы, совместимость с существующими системами).

У системного аналитика должно быть чёткое представление о том, как ограничение может влиять на архитектурные или процессные решения.
9.9. Разработка вариантов решения бизнес-задачи
Рис.9.9.1. — Подходы к внедрению программного обеспечения
После того как определены потребности, цели и ограничения, следует рассмотреть возможные варианты решения. Это может быть:

1. Закупка готового продукта (COTS — Commercial Off-The-Shelf)
  • Например, известная ERP-система или CRM-платформа.
  • Плюсы: проверенный функционал, поддержка производителя, быстрее «с нуля». Минусы: может потребоваться сложная кастомизация, дорогостоящие лицензии.

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

3. Разработка с нуля
  • Полная свобода проектирования под нужды бизнеса.
  • Однако более длинные сроки и риски, требующие высокой компетенции команды разработки.

4. Комбинированный подход
  • Например, использовать готовую платформу, но интегрировать её с внутренними модулями и микросервисами для специфических задач.
9.10. Оценка, сравнение и выбор вариантов решения бизнес-задачи
Рис.9.10.1. — Выбор вариантов решения
Для того чтобы выбрать оптимальный вариант, аналитик вместе со стейкхолдерами проводит сравнение альтернатив:

1. Критерии оценки
  • Финансовые: стоимость, ROI, срок окупаемости.
  • Технологические: соответствие IT-ландшафту, масштабируемость, надёжность.
  • Организационные: сложность внедрения, обучаемость сотрудников, поддержка менеджмента.
  • Сроки и риски.

2. Методы сравнения
  • Табличное сравнение (matrix), где каждая альтернатива оценивается по ряду параметров.
  • Взвешенное голосование (Weighted Scoring), когда каждому критерию присваивается «вес», а затем суммарный балл указывает на предпочтительный вариант.

3. Принятие решения
  • Итоги сравнения презентуются руководству, ключевым заказчикам.
  • Иногда решение принимается коллегиально, иногда — единолично спонсором проекта.
  • Важно документировать, почему выбран один путь и отклонён другой.
9.11. Обоснование, оформление и защита концепции решения
Рис.9.10.1. — Подготовка и защита концепции решения
Когда вариант решения выбран, системный аналитик готовит концепцию решения (Solution Concept), которая служит базой для дальнейших этапов — детального проектирования, технической реализации:

1. Содержание концепции
  • Описание бизнес-проблемы, которую решаем.
  • Бизнес-цели и ограничения.
  • Краткое описание целевых бизнес-процессов (TO-BE).
  • Выбранный вариант решения и его основные характеристики (архитектура, ключевой функционал).
  • Ожидаемые выгоды и метрики успеха.

2. Формат защиты
  • Презентация концепции стейкхолдерам (менеджмент, ключевые пользователи, спонсоры, технические специалисты).
  • Ответы на вопросы и возражения, демонстрация макетов или пилотного прототипа.
  • Согласование плана реализации: сроки, бюджет, этапы, возможные риски и резервы.

3. Фиксация решений
  • Протокол совещания, утверждённый документ Vision & Scope, решение совета директоров (в зависимости от масштаба и культуры компании).
  • Все заинтересованные стороны должны иметь доступ к финальным материалам и понимать, какие компромиссы были заложены.
Вывод по главе 9
Рис.9.10.2. — Процесс бизнес-анализа
Бизнес-анализ, бизнес-моделирование и бизнес-проектирование — это фундамент, на котором строится дальнейшая работа по созданию или улучшению информационной системы. Системный аналитик в этой области:
  1. Исследует и понимает бизнес, его цели, процессы, проблемы и ограничения.
  2. Выявляет и описывает потребности, формирует бизнес-требования.
  3. Моделирует текущие и целевые процессы, структуру данных и организацию.
  4. Оценивает варианты решений с точки зрения экономики, технологии и стратегических задач.
  5. Оформляет и защищает концепцию решения перед руководством и стейкхолдерами, обосновывая её ценность и реализуемость.

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

Глава 10. Надсистемный анализ и проектирование

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

В этой главе мы рассмотрим инструменты «надсистемного» анализа, позволяющие взглянуть на проектируемую систему с более высокого уровня: определить границы, описать окружение и смоделировать «чёрный ящик» системы.
10.1. Выделение границ системы
Рис.10.1.1. — Определение границ системы
Первый шаг к любому архитектурному проектированию — понять, что включается в создаваемую систему, а что остаётся вне её рамок. Это помогает расставить приоритеты и избежать «раздувания» функционала.

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

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

3. Учет интеграций
  • Если часть функционала уже реализована во внешней системе (например, система бухгалтерского учёта), возможно, есть смысл оставить её «за границами» и лишь наладить обмен данными.
  • Это сохраняет ресурсы и снижает риск дублирования.

4. Документирование границ
  • Часто границы фиксируют в виде контекстной диаграммы (Context Diagram) или в разделе «Scope» спецификации.
  • Важно, чтобы все стейкхолдеры понимали и соглашались, где заканчивается зона ответственности проектируемой системы.
10.2. Описание окружения системы
Рис.10.2.1. — Описание окружения системы
После того, как границы определены, системный аналитик описывает окружение, то есть внешние объекты, с которыми система будет взаимодействовать.

1. Внешние системы
  • Это может быть ERP, CRM, платёжные сервисы, государственные порталы и т. д.
  • Нужно описать, какие данные туда передаются и какие данные получаются.
  • Уточнить форматы, протоколы и регламенты взаимодействия (например, REST API, SOAP, файлы, очереди сообщений).

2. Пользователи и роли
  • Часто к окружению относят и человеческих пользователей, которые взаимодействуют с системой через интерфейс.
  • Важно определить роли (администратор, оператор, менеджер, клиент) и каналы доступа (веб, мобильное приложение, терминал).

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

4. Инфраструктурные ограничения
  • Какие сетевые, аппаратные или облачные окружения будут задействованы.
  • Нужно понимать, есть ли особые требования к безопасности, пропускной способности, доступности (SLA), резервированию.

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

10.3. Моделирование «чёрного ящика»
Рис. 10.3.1. — Модель чёрного ящика в системном анализе
Модель «чёрного ящика» показывает систему как единый блок со входами и выходами, не раскрывая при этом её внутреннее устройство. Такой подход полезен, чтобы стейкхолдеры и аналитики:

1. Сосредоточились на внешнем поведении
  • Что система принимает на вход (данные, команды, запросы) и что отдаёт на выход (результаты, ответы, сообщения)?
  • Не нужно обсуждать внутренние алгоритмы на этом этапе — важно согласовать интерфейсы и логику взаимодействия.

2. Упростили общение с бизнесом
  • Бизнес-пользователям не всегда интересно, какова структура БД или из чего состоит API. Им важно, какие функции выполняет система и какие результаты они могут получить.
  • Модель «чёрного ящика» даёт им понятную диаграмму, где видно, какие внешние факторы влияют на систему и какие выгоды (outputs) она генерирует.

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

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

Пример использования
  • Нарисуйте прямоугольник, обозначающий систему.
  • Вокруг него расположите «акторы» (внешних пользователей, системы) и отразите стрелками, какие данные или команды поступают внутрь, и что возвращается наружу.
  • Это может быть как простая схема (2–3 стрелки и пара акторов), так и более детальная (множество интеграционных точек, различные роли).
Вывод по главе 10

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

Надсистемный анализ и проектирование — это важный этап, позволяющий системному аналитику и команде:
  • Определить, что включается в будущую систему, а что остаётся за её границами (scope).
  • Описать окружение, выделив все внешние системы и пользователей, с которыми придётся взаимодействовать.
  • Смоделировать «чёрный ящик», фиксируя основные входы, выходы и поведение системы «снаружи» без детализации внутренней структуры.
Такой подход даёт всем стейкхолдерам единую «макрокартину» проекта. Когда становится понятно, как новая (или изменённая) система впишется в IT-ландшафт, с кем и как она будет «разговаривать», какие внешние факторы влияют на её работу, можно переходить к детальной проработке функционала, архитектуры и требований.

Глава 11. Инженерия требований и её кризис

Инженерия требований (Requirements Engineering) — это дисциплина, которая исследует, каким образом правильно определять, документировать и согласовывать требования к будущей системе. Сюда же относится управление изменениями требований на протяжении всего жизненного цикла проекта. Казалось бы, тема хорошо изучена: существуют методологии, стандарты, рекомендации. Однако на практике именно требования часто становятся «ахиллесовой пятой» проектов. Несогласованные или неполные требования приводят к конфликтам, срывам сроков, перерасходу бюджета и, в итоге, к недовольству заказчиков.

В данной главе мы рассмотрим основные положения инженерии требований, разницу между бизнес-требованиями и «пользовательскими», а также обсудим, почему в реальности «всё не так гладко», как описано в учебниках, и какую научную критику предъявляют к классической парадигме требований, в частности Paul Ralph.
11.1. Основные положения инженерии требований
Рис. 11.1.1. — Модель чёрного ящика в системном анализе
В классическом понимании инженерия требований состоит из следующих этапов:

1. Сбор (elicitation)
  • Определение источников (стейкхолдеры, документы, законы и стандарты).
  • Проведение интервью, воркшопов, анкетирования, анализа существующих систем.

2. Анализ
  • Уточнение и приоритизация полученной информации.
  • Проверка на противоречивость, полноту, реалистичность.

3. Документирование (specification)
  • Формальное или полуформальное описание требований.
  • Использование различных форматов: User Stories, Use Cases, SRS (Software Requirements Specification), диаграммы (UML, BPMN), прототипы интерфейсов.

4. Валидация и согласование
  • Проверка требований вместе с бизнес-заказчиками, пользователями, командой разработки и другими стейкхолдерами.
  • Утверждение окончательного списка требований (baseline).

5. Управление изменениями (change management)
  • Отслеживание версий и истории правок.
  • Оценка влияния новых или изменённых требований на сроки, бюджет, архитектуру.
  • Согласование изменений со стейкхолдерами.

В идеальном мире, когда все эти шаги выполняются корректно, проект должен получить чёткое, полное и реалистичное описание того, что и как нужно реализовать. На практике же возникает множество сложностей: требования могут постоянно меняться, заказчики не всегда знают, чего хотят, а разработчики — не всегда понимают язык бизнеса.
11.2. Бизнес-требования в проектах автоматизации
Рис. 11.2.1. — Классификация бизнес-требований
В контексте проектов автоматизации бизнес-требования проекта обычно отражают стратегические цели и ценность для организации, ради которых запускается проект. Обычно они сформулированы на высоком уровне абстракции:
  • Повысить продажи на 20% за год.
  • Сократить время обработки заявок с двух дней до четырёх часов.
  • Улучшить качество обслуживания клиентов (увеличить NPS до 70).
  • Соблюдать новые нормы законодательства (например, GDPR, стандарты бухучёта).

Бизнес-требования отвечают на вопрос: зачем компании нужна та или иная система или её доработка? Они могут описываться в документах типа Vision & Scope, где говорится о том, какие выгоды проект должен принести и какие существуют ограничения (бюджет, сроки, ресурсы).

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

NB: Стоит отметить, что бизнес-требования существуют не только для проекта, но и для организации — например, общие требования к организации, требования к отдельным подразделениям, процессам и бизнес-ролям. Такие бизнес-требования выявляются, создаются и развиваются не в проектах автоматизации, а в проектах организационного развития в целом:
  • Организация должна оказывать услуги доставки частным лицам
  • Организация должна сдавать налоговую отчётность
  • Организация должна обеспечивать проекты необходимым количеством персонала
  • и т.д.
11.3. «Пользовательские» требования
Рис. 11.3.1. — Цели разработки бизнес-требований и пользовательских требований
Очень часто считают, что «пользовательские» требования (user requirements) описывают, что конкретно хотят конечные пользователи или заинтересованные группы (stakeholders) от системы.

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

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

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

1. User Stories
  • Формат: «Как [роль пользователя], я хочу [действие], чтобы [бизнес-ценность или результат]».
  • Пример: «Как менеджер по продажам, я хочу иметь возможность создавать персонализированные коммерческие предложения из CRM в один клик, чтобы сократить время подготовки документа».

2. Use Cases (сценарии использования)
  • Более формальное описание: актор, прецедент (взаимодействие), потоки событий, альтернативные ветки.
  • Пример: «Прецедент: «Сформировать коммерческое предложение». Основной поток: (1) Пользователь открывает карточку клиента, (2) нажимает «Создать КП», (3) система подтягивает реквизиты…»

3. Формальные требования
  • Список пунктов, структурированных по шаблону: «Требование №, Описание, Приоритет, Критерий приёмки».
  • Удобно, если нужна детальная спецификация (например, для Fixed Price контрактов или сложных интеграций).

Почему важно отделять бизнес-требования от пользовательских?
  • Бизнес-требования позволяют держать фокус на ценности, которую получит организация.
  • Пользовательские требования помогают понять, как именно эта ценность достигается через конкретные функции системы.
  • Когда они противоречат друг другу, нужно возвращаться к целям проекта и искать компромисс (например, не все пожелания пользователей могут быть целесообразны с точки зрения ROI).
Читайте наши статьи по теме:
11.4. Трассировка требований
Рис. 11.4.1. — Связь требований
Трассировка (traceability) — это связь между различными уровнями и видами требований, а также между требованиями и другими артефактами проекта (тест-кейсами, задачами разработки, архитектурными решениями).

1. Зачем нужна трассировка?
  • Для того чтобы убедиться, что каждое требование имеет корреляцию с бизнес-целями и не появляется «само по себе».
  • Для того чтобы в процессе разработки и тестирования не терять из виду ни одного важного требования.
  • Для того чтобы понимать влияние изменений: если меняется бизнес-требование, какие пользовательские требования (и какой код) придётся переписывать?

2. Инструменты
  • Системы управления требованиями (Jama, Polarion, Rational DOORS).
  • Создание таблиц трассировки в Excel или Confluence, где каждому требованию присваивается уникальный идентификатор и указываются связанные элементы.

3. Уровни трассировки
  • Бизнес-требования ↔ Пользовательские требования ↔ Системные требования.
  • Требования ↔ Тестовые сценарии.
  • Требования ↔ Архитектурные компоненты (или задачи разработки).
Без трассировки на больших проектах легко запутаться, кто и зачем просил ту или иную функцию, и как она связана с более глобальной целью.
11.5. Качество требований
Рис. 11.5.1. — Обеспечение качественных требований
Требования считаются качественными, если они отвечают ряду критериев:

1. Полнота
  • Достаточны для понимания того, что нужно делать; не пропущены критические аспекты.
  • Необязательно, что все мелкие детали зафиксированы в начале проекта, но крупные области должны быть отражены.

2. Однозначность
  • Исключение двусмысленных формулировок («быстро», «удобно», «безопасно» — это всё субъективно, лучше указывать конкретные параметры).
  • Избегание терминов, которые могут трактоваться по-разному.

3. Проверяемость
  • Можно ли объективно проверить, выполнено требование или нет (есть чёткие критерии приёмки)?
  • «Время отклика не более 2 секунд при 100 одновременных пользователях» проверяемо, а «система должна работать быстро» — нет.

4. Согласованность
  • Нет внутренних противоречий (одно требование не говорит «Отправлять отчёт по email каждый день», а другое — «Отправлять отчёт по email один раз в месяц»).
  • Термины и названия сущностей используются единообразно.

5. Реализуемость
  • Учитываются реальные технические, ресурсные, временные ограничения.
  • Если требование «обрабатывать миллион транзакций в секунду», нужно убедиться, что инфраструктура и бюджет позволяют.

6. Необходимость и ценность
  • Требование должно приносить бизнес-пользу или быть обусловленным регуляторными нормами, а не просто «хотелкой».
11.6. Что не так с требованиями: повседневная практика и научная критика
Рис. 11.6.1. — Как лучше подходить к управлению требованиями в проектах ИТ?
Несмотря на обилие методик и инструментов, «кризис требований» остаётся распространённой проблемой. Почему?

1. Заказчики не знают, чего хотят
  • Часто бизнес понимает проблему, но не всегда ясно представляет, какое именно решение поможет.
  • Когда «видение» туманно, формулировать чёткие требования сложно, они могут постоянно меняться.

2. Слишком формальная документация
  • Некоторые команды тратят много времени на создание громоздких документов (сотни страниц), которые никто толком не читает.
  • В итоге фактические требования «живут» в устных обсуждениях и чатах, а документ быстро устаревает.

3. Чрезмерная гибкость (Agile-заблуждение)
  • Есть мнение, что в Agile можно вообще не писать требования и «просто общаться».
  • На практике без хотя бы минимальной фиксации (user stories, acceptance criteria) команда начинает путаться, что и как делать.

4. Отсутствие управления изменениями
  • Требования меняются в ходе проекта, это нормально. Но если нет процесса согласования и оценки влияния, команда оказывается в хаосе.
  • Сроки срываются, бюджет растёт, разработчики устают от постоянных переделок.

5. Недостаток взаимодействия бизнеса и IT
  • Если аналитик «отрывается» от бизнеса и не получает регулярный фидбэк от пользователей, требования могут уйти в неверном направлении.
  • Нужны постоянные встречи, ревью, демо, чтобы поддерживать «живой» контакт.

Научная критика от Paul Ralph

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

1. Проектирование как творческая деятельность
  • Ralph утверждает, что процесс создания ПО — это не просто сбор уже «готовых» требований, а творческое проектирование (design). Требования не всегда «открываются», а зачастую создаются и эволюционируют параллельно с архитектурой и дизайном.

2. Размытая грань между «требованиями» и «решениями»
  • С традиционной точки зрения, мы сначала собираем требования (что нужно), а потом предлагаем решение (как это сделать).
  • По мнению Ralph, в реальных проектах «что» и «как» смешиваются с самого начала: заказчики могут предлагать готовое техническое решение, а команда может формировать «требования», исходя из своих идей о дизайне.

3. «Requirements» vs. «Desiderata»
  • Ralph предлагает заменять привычные «requirements» более гибким термином — «desiderata» (от лат. «желаемое»), указывая, что в проектном процессе мы имеем дело не столько с жёсткими требованиями, сколько с списком пожеланий, приоритетов и компромиссов.
  • Список desiderata может меняться и подлежит переосмыслению, когда появляются новые технологические возможности или меняются бизнес-условия.

4. Комплексный и эволюционный характер
  • Современные IT-проекты живут в условиях высокой неопределённости. Бизнес может менять стратегию, рынок может диктовать новые требования к скорости разработки.
  • По мнению Ralph, классическая инженерия требований, которая подразумевает стабильный набор «неизменных» входных данных, неадекватно описывает реальность в условиях постоянных изменений.

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

Вывод по главе 11
Рис. 11.6.2. — Балансировка гибкости и структуры в инженерии требований
Инженерия требований по-прежнему является одной из самых сложных и ответственных частей IT-проекта. Несмотря на то что существует множество методик и стандартов, на практике именно работа с требованиями часто приводит к кризисам: меняются запросы бизнеса, заказчик не всегда знает, чего хочет, а команда разработки не успевает подстраиваться под новые условия. Это порождает путаницу, перерасход бюджета и нарушение сроков.

При этом, как подчёркивает научная критика (например, позиция Paul Ralph), требования – это не статичный список, который можно выявить один раз и навсегда; они скорее «desiderata» (пожелания, совместно формируемые бизнесом и командой), которые эволюционируют вместе с пониманием задачи. Системному аналитику нужно постоянно балансировать между формальной стороной (документация, спецификации, трассировка) и живым процессом проектирования, где «что» и «как» тесно переплетены.

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

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

Глава 12. Моделе-ориентированное проектирование и его кризис

В процессе анализа и проектирования информационных систем аналитики и архитекторы часто используют различные виды моделей: диаграммы, схемы, описания на формальном языке (UML, BPMN и др.). Идея «моделе-ориентированного проектирования» (Model-Driven Design / Model-Driven Engineering) предполагает, что такие модели могут стать основой для автоматической (или полуавтоматической) генерации исходного кода и максимально облегчат процесс разработки.

Однако история массового применения UML и других формальных нотаций показывает, что практика далеко не всегда оправдывает теорию. В этой главе мы рассмотрим, почему модель-ориентированное проектирование изначально казалось «серебряной пулей», и почему в реальности оно пережило определённый кризис. Кроме того, мы поговорим о концепции Domain-Driven Design (DDD), которая стала ответом на чрезмерное увлечение формальными моделями в отрыве от реального бизнеса.
12.1. Взлёт и падение UML
Рис. 12.1.1. — Нотация UML для моделирования систем
UML (Unified Modeling Language) в конце 1990-х — начале 2000-х годов позиционировался как универсальный язык для визуального моделирования систем. Предполагалось, что разработчики, аналитики и архитекторы смогут:
  1. Единообразно описывать структуру, поведение и взаимодействие компонентов системы, используя множество типов диаграмм (Class, Sequence, Use Case, Activity и т. д.).
  2. Автоматизировать часть разработки, преобразуя UML-модель в готовый каркас кода (Model-Driven Architecture, MDA).
  3. Улучшить коммуникацию между бизнесом и IT, так как диаграммы должны быть понятны «не-техническим» стейкхолдерам.

Почему UML стал популярным

  • Стандартизированный подход: до UML существовало множество разрозненных методологий (OMT, Booch, Jacobson). UML объединил лучшие идеи под эгидой OMG (Object Management Group).
  • Богатый набор диаграмм: позволял формализовать практически любой аспект системы (от требований и процессов до программных классов и развёртывания).
  • Поддержка в инструментах: начали появляться популярные средства (Rational Rose, Enterprise Architect, Visual Paradigm), позволяющие рисовать диаграммы и генерировать код.

«Падение» UML и кризис формальных моделей

Со временем обнаружилось, что создание детализированных UML-моделей для всего проекта требует колоссальных ресурсов и почти не даёт экономии в написании кода.
  • Сложность актуализации: при изменении требования или архитектуры нужно было править множество диаграмм, иначе модель «стареет» и перестаёт отражать действительность.
  • Избыточность: многие команды сочли, что для уточнения логики им достаточно пары «легковесных» диаграмм (например, Sequence или BPMN) и простого описания, чем вести полный UML-пакет, который почти никто не читает.
  • Недостаток инструментальной поддержки на практике: автоматическая генерация качественного кода из UML-моделей (и обратно) оказалась менее популярной, чем думали изначально; большинство проектов предпочитали писать код «вручную» и делать документацию «под код».

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

12.2. Domain-Driven Design
Рис. 12.2.1. — Проектирование, ориентированное на домен (DDD)
На рубеже 2000-х появился подход Domain-Driven Design (DDD), предложенный Эриком Эвансом. Он сосредоточен на том, чтобы:
  1. Глубже понять предметную область (домен), а не механически рисовать UML-диаграммы.
  2. Создать единый язык (Ubiquitous Language), которым пользуются и разработчики, и бизнес-эксперты.
  3. Сосредоточиться на модели домена, отражающей сущности, агрегаты, значения, а не распыляться на все аспекты кода или инфраструктуры.
Ключевые идеи DDD
  • Общая терминология (Ubiquitous Language): все участники проекта (аналитики, архитекторы, бизнес) договариваются об одинаковых названиях сущностей, процессов и атрибутов.
  • Bounded Context: крупный бизнес-домен делится на отдельные «контексты», где термины имеют точное значение, и эти контексты «стыкуются» друг с другом при помощи чётко определённых моделей интеграции.
  • Модель предметной области: в центре внимания — бизнес-правила, которые кодируются в ядре приложения (Core Domain). Важна правильная проектировка сущностей, сервисов, репозиториев, чтобы они точно отражали бизнес-логику.
Как DDD решает проблемы «классического» модель-ориентированного подхода
  • Фокус на смысл, а не на формальную нотацию: DDD позволяет выбрать любые диаграммы или вовсе обойтись без них, если все участники понимают язык домена.
  • Гибкость и итеративность: модель домена может эволюционировать вместе с бизнес-пониманием. Это соответствует Agile-принципам, где изменения являются нормой.
  • Прикладное применение: DDD концентрируется на том, чтобы код действительно отражал бизнес-логику, а не просто «превращал нарисованные квадратики в классы».

Вместо попытки описать «всё и сразу» с помощью UML, DDD стимулирует команду работать тесно с экспертами предметной области, многократно уточнять и развивать модель. При этом можно использовать легковесные диаграммы (Context Map, Domain Model диаграммы), но их цель — уточнять совместное понимание домена, а не выполнять генерацию кода.

Вывод по главе 12
Рис. 12.2.2. — Выберите лучший подход к проектированию систем для гибкости и согласования с бизнесом
Идея модель-ориентированного проектирования (MDA, UML) имела впечатляющий старт, когда казалось, что единая формальная модель станет основой автоматизированной разработки и снизит сложность проектов. Но на практике:
  • Полный охват UML оказался слишком затратным и громоздким,
  • Инструментальная поддержка не оправдала ожиданий,
  • Команды предпочли «точечное» использование диаграмм или вовсе отказались от обширной формальной моделировки в пользу более гибких и понятных методов.

Domain-Driven Design частично «заместил» классический подход к моделированию, сместив акцент на смысл и бизнес-логику (домен), а не на формальное описание каждой детали системы. DDD предлагает более гибкий и эволюционный путь, где модели постоянно уточняются при тесном сотрудничестве бизнеса и разработчиков, сохраняя при этом логику предметной области в центре внимания.

Таким образом, «кризис» модель-ориентированного проектирования не означает, что UML или другие нотации совсем не нужны. Это означает лишь, что использовать их стоит осознанно, учитывая реальное «вписывание» в процессы разработки и реальные потребности команды. А подходы вроде DDD показывают, как можно проектировать систему, уделяя больше внимания богатству доменной модели и качеству кода, чем стремлению к формальной стопроцентной описательной нотации.

Читайте наши статьи по теме:

Глава 13. Проектирование использования и пользовательских интерфейсов

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

В этой главе мы рассмотрим основные принципы проектирования использования (Use Case, User Stories) и концепции UI/UX (пользовательский интерфейс и опыт взаимодействия), а также важность сценариев и прототипирования.
13.1. Сценарии использования
Рис. 13.1.1. — Компоненты сценария использования
Сценарий использования (Use Case) описывает последовательность шагов, которую выполняют пользователь или система, чтобы достичь конкретной цели. Это один из ключевых инструментов, помогающих понять, как пользователи будут взаимодействовать с системой.

Зачем нужны сценарии использования
  1. Фокус на потребностях: вместо абстрактного списка функций сценарии показывают реальную задачу пользователя («Сформировать заказ», «Провести платёж»).
  2. Проще анализировать исключительные и альтернативные ветки: что, если пользователь ошибся при вводе, или система не смогла подтвердить данные?
  3. Основа для тестирования: тестировщики могут создавать тест-кейсы, опираясь на эти сценарии; сразу видны основные пути и ответвления.

Как описывается Use Case
  • Название: коротко отражающее цель (например, «Создать счёт»).
  • Актор(ы): роли пользователей или внешние системы, которые участвуют в сценарии.
  • Предусловия: что должно быть выполнено до начала сценария (например, пользователь залогинен, у него есть права).
  • Основной поток: пошаговое описание действия акторов и реакции системы.
  • Альтернативные потоки (опционально): что произойдёт, если в ходе основного потока случится ошибка или выбор другого пути.
  • Постусловия: результат, которого мы добиваемся (например, счёт создан, уведомление отправлено).
Пример сценария использования:
13.2. Истории пользователей
Рис. 13.2.1. — Описание потребности в виде User Story
В Agile-подходах, таких как Scrum или Kanban, популярны User Stories — краткие формулировки потребностей пользователей:
«Как [роль], я хочу [действие], чтобы [бизнес-ценность].»

Преимущества User Stories
  1. Простота и гибкость: короткая формулировка легко корректируется, при этом содержит ключевые элементы (кто, что, зачем).
  2. Уточнение в диалоге: подробности проясняются в процессе общения с пользователями и командой разработки.
  3. Возможность итеративной приоритизации: истории можно упорядочивать по важности, добавлять, убирать, разбивать на более мелкие задачи.
Критерии приёмки (Acceptance Criteria) дополняют историю, описывая, что именно должно быть сделано, чтобы считать её выполненной. Например:
  • «Как менеджер, я хочу видеть список всех заказов за неделю, чтобы контролировать продажи.»
Acceptance Criteria:
  • Список включает дату и сумму заказа, статус, контактные данные клиента;
  • Можно фильтровать по статусу («Новый», «Оплачен», «Отменён»);
  • Доступен экспорт в Excel.

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

Читайте наши статьи по теме:
13.3. Виды и особенности пользовательских интерфейсов
Рис. 13.3.1. — Виды пользовательских интерфейсов
Пользовательский интерфейс (UI) — это среда, в которой пользователь и система обмениваются информацией и командами. Интерфейсы бывают:

1. Web-интерфейсы
  • Доступны через браузер (Chrome, Safari, Firefox и т. д.).
  • Нужно учитывать кросс-браузерную совместимость, адаптивность (desktop, планшет, мобильный).
  • Часто используется протокольное взаимодействие HTTP/HTTPS, а визуал может работать на фреймворках типа React, Vue, Angular.

2. Desktop-приложения
  • Устанавливаются на компьютер (Windows, macOS, Linux).
  • Позволяют более глубокий доступ к ресурсам ОС, но требуют сложной дистрибуции и обновлений.

3. Мобильные приложения
  • Запускаются на смартфонах и планшетах (iOS, Android).
  • Ограниченные размеры экрана, сенсорное управление, доступ к функциям устройства (камера, GPS).

4. Терминальные интерфейсы
  • Специфические решения для банкоматов, киосков самообслуживания, промышленного оборудования.
  • Главное — стабильность, простота, высокая защита от ошибок.

5. Голосовые и чат-интерфейсы
  • Ассистенты типа Alexa, Google Assistant, чат-боты в мессенджерах.
  • Акцент на распознавание речи и естественный язык.

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

13.4. Моделирование навигации по пользовательскому интерфейсу
Рис. 13.4.1. — Инструменты проектирования пользовательского интерфейса
Часто недостаточно описать только отдельные экраны или функции. Важно понять, как пользователь будет переходить между экранами, какие действия доступны на каждом шаге. Для этого:

1. User Flow (карта потока пользователей)
  • Графическая схема, показывающая, какие экраны есть и как пользователь может из одного экрана попасть в другой.
  • Отражает точки входа в систему, альтернативные ветки, возвращение назад, всплывающие окна и т. д.

2. Wireframes (макеты), прототипы
  • Прикидочные наброски расположения элементов (кнопки, поля ввода, меню) без детальной графики.
  • Помогают рано проверить логику и удобство перед тем, как вкладываться в детальный UI-дизайн.

3. Information Architecture (IA)
  • Структура меню, разделов, каталогов, тегов.
  • Старайтесь сделать путь пользователя к цели минимально сложным: меньше кликов, простые и говорящие названия элементов.

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

13.5. Принципы проектирования пользовательских интерфейсов
Рис. 13.5.1. — Ключевые принципы создания эффективного UI/UX Интерфейса
Современные продукты и системы должны быть интуитивными, эффективными и приятными. Основные принципы UI/UX:

1. Консистентность
  • Единый стиль оформления, одинаковое поведение похожих элементов.
  • Если кнопка «Сохранить» всегда справа внизу, пользователь не запутается.

2. Простота
  • Минимизируйте количество кликов и экранов, не перегружайте интерфейс деталями.
  • Используйте понятные иконки и лаконичные тексты.

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

4. Гибкость
  • Дайте возможность настроить интерфейс под себя, если у пользователей разные сценарии и частоты использования.

5. Доступность (Accessibility)
  • Учёт людей с ограниченными возможностями (цветовая палитра для дальтоников, озвучка, масштабирование текста).
  • Юридические аспекты: в некоторых странах это регулировано законом.

6. Тестирование с реальными пользователями
  • Чем раньше проведёте юзабилити-тесты и соберёте обратную связь, тем лучше поймёте, что нужно доработать.
Читайте наши статьи по теме:
Вывод по главе 13
Проектирование использования (Use Cases, User Stories, сценарии) и проектирование пользовательских интерфейсов — два неотделимых аспекта системного анализа. Успешное решение не только закрывает бизнес-потребности, но и обеспечивает удобство и эффективность для конечных пользователей.

  1. Сценарии использования дают понимание, что и как пользователь будет делать в системе, какие шаги проходят в типичной и альтернативной ветке.
  2. User Stories позволяют описать элементарные пользовательские потребности с точки зрения реальной ценности, а критерии приёмки — проверить, что требуемая функциональность действительно сделана.
  3. Детальный UI/UX-дизайн и принципы удобного интерфейса помогают превратить функциональные сценарии в понятный, приятный и продуктивный опыт работы с системой.
  4. Прототипирование и тестирование макетов — критический этап, позволяющий вовремя скорректировать логику, пока она не воплощена в коде.
Именно такой комплексный подход к проектированию использования и интерфейса обеспечивает, что разрабатываемая система станет не только «правильной» с точки зрения архитектуры, но и востребованной, комфортной для тех, кто ей будет пользоваться.

Глава 14. Концептуальное проектирование

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

В данной главе мы рассмотрим, какие задачи решает концептуальное проектирование, почему важно «моделировать и проектировать состав» будущей системы, и как это влияет на согласование интересов бизнеса и технических команд.
14.1. Моделирование и проектирование состава
Рис. 14.1.1. — Эффективная структура системы для интеграции и моделирования
«Состав» системы (или компонентная структура) показывает, из каких крупных частей (субсистем, модулей, сервисов) состоит решение и как эти части взаимодействуют друг с другом. Это может включать описание:
  • Основных функциональных блоков (например, «Модуль управления заказами», «Модуль расчёта тарифов», «Модуль аналитики»);
  • Сервисов или микросервисов, если используется сервис-ориентированная или микросервисная архитектура;
  • Подсистем, связанных с разными бизнес-направлениями (закупки, логистика, продажи, маркетинг и т. д.);
  • Интеграционных шлюзов (ESB, API Gateways, message brokers), через которые система связывается с внешними решениями.

Почему «состав» важен?
  • Упрощение понимания: заинтересованные стороны (бизнес, руководство, разработчики) видят, как решение «разбито» на крупные части и почему именно такое деление выбрано.
  • Распределение ответственности: каждая подсистема или модуль может иметь своего владельца/команду. В крупных компаниях так проще контролировать развитие каждого направления.
  • Определение границ: уже на концептуальном уровне понятно, где заканчивается функциональность одного модуля и начинается функциональность другого. Это позволяет избежать конфликтов, дублирования и пересечений.
  • Подготовка к интеграции: если известно, что в системе есть, к примеру, отдельный «Модуль учёта оплаты», заранее понятно, как он будет взаимодействовать с «Модулем управления заказами» и внешними платёжными сервисами.

Инструменты для моделирования состава
  • UML Component Diagram: показывает систему в виде крупных компонентов (component) и связи между ними (interfaces, ports).
  • C4-модель (контекст, контейнеры, компоненты, классы): популярный подход в современной архитектуре для структурирования представления о системе на нескольких уровнях детализации.

Простые блок-схемы (Block diagrams): если не нужны формальные нотации, можно отразить основные блоки на схеме «прямоугольник—стрелки», сопровождая их описанием.

14.2. Роль концептуального проектирования в согласовании интересов
На концептуальном уровне часто встречаются конфликты или разные видения того, как система должна быть устроена:
  • Бизнес-заказчик может считать, что ему нужен «один единый модуль, который решает всё сразу».
  • Техническая команда может предпочитать микросервисную архитектуру, разделяя функциональность на десятки сервисов ради гибкости и независимых релизов.
  • Руководство может волновать вопрос «А сколько это будет стоить и не превысит ли бюджет?»

Концептуальное проектирование, отражающее состав системы, помогает:
  1. Показывать, как бизнес-требования раскладываются на модули. Например, «Подсистема для сбора аналитики» отвечает за KPI и отчётность, «Модуль клиентского портала» закрывает задачу повышения удобства для клиента.
  2. Оценивать сложность и стоимость. Разделение на компоненты даёт понимание, какие блоки придётся разрабатывать с нуля, что можно купить как готовое решение (COTS), что можно взять в виде open-source библиотеки.
  3. Согласовывать сроки. Если критичен быстрый выход на рынок (Time to Market), приоритизируется разработка отдельных модулей, без которых бизнес-эффект не реализуется. Менее приоритетные части можно внедрять на следующей фазе.

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

14.3. Связь концептуального проекта с дальнейшей детализацией
Когда концептуальная схема структуры системы принята, возникают естественные вопросы:
  • «Как внутри каждого модуля будут организованы данные, классы, бизнес-логика?»
  • «Как эти модули будут деплоиться и масштабироваться?»
  • «Какие протоколы использовать для взаимодействия между сервисами?»

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

Процесс итеративного развития

Часто концептуальное проектирование не заканчивается одним документом. Это живой процесс, где модель состава дополняется и пересматривается, если:
  • Меняются бизнес-требования, появляются новые функции, которые требуют отдельного модуля.
  • Выявляются технологические ограничения, заставляющие изменить структуру (например, объём данных слишком велик, что требует вынести аналитику в отдельный high-load сервис).
  • Проект переходит на новую фазу (например, интеграция с внешними системами), где нужно уточнить границы ответственности модулей.
Вывод по главе 14

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

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

Без чёткого концептуального видения команда рискует «утонуть» в деталях и создавать систему, где нет ясного разделения ролей и функций. А продуманная модель состава служит прочным фундаментом для дальнейшего системного анализа, инженерии требований и детального проектирования.
Концептуальное проектирование — важный шаг, который помогает системному аналитику и всей команде увидеть высокоуровневую структуру будущей системы, определить ключевые модули (подсистемы, сервисы) и их взаимосвязи. На этом уровне:
  1. Закладываются границы: что входит в систему, а что остаётся во внешних компонентах.
  2. Формируется понятная карта для стейкхолдеров (бизнес, IT, менеджмент), позволяющая согласовать приоритеты и ответственность.
  3. Определяется направление дальнейшего детального проектирования и архитектуры.

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

Глава 15. Внутрисистемный анализ

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

Виды системных требований:
1. Функциональные
  • Описывают логику работы, сценарии, данные, которые обрабатываются, и бизнес-правила.
  • Например: «Система должна позволять оператору видеть детализированную информацию о заказе», «В случае нехватки товара на складе система блокирует отправку».
2. Нефункциональные (атрибуты качества)
  • Относятся к производительности, безопасности, масштабируемости, удобству поддержки и т. д.
  • Например: «Время отклика на запрос не должно превышать 2 секунд при 100 одновременно активных пользователей».
3. Технические ограничения
  • Требования к технологиям, окружению, интеграционным протоколам.
  • Например: «Решение должно работать в Docker-контейнерах под управлением Kubernetes», «Формат данных обмена — JSON, протокол — HTTPS».
Системные требования часто оформляются в виде спецификации (SRS — Software Requirements Specification) или в виде user stories, дополненных критериями приёмки (acceptance criteria), если используется Agile-подход.
Читайте наши статьи по теме:
15.2. Функциональное проектирование
После того как сформулированы системные требования, нужно выработать детальное понимание функциональной логики. Функциональное проектирование фокусируется на том, какие функции система должна выполнять и как (на уровне логики, а не кода).

Методики и инструменты:
1. Use Case и Activity Diagrams
  • Позволяют описать последовательность действий (внутренний «workflow») и уточнить бизнес-правила обработки данных.
  • Показывают, какие шаги выполняет система в ответ на действия пользователя или внешнего сервиса.

2. Сценарии взаимодействия (Sequence Diagrams)
  • Описывают, в каком порядке вызываются методы, сервисы, какие сообщения передаются между объектами или микросервисами.
  • Удобно для сложной логики, где важно понять очередность взаимодействий.

3. Схемы данных (ER-диаграммы, если речь о реляционных БД)
  • Проектирование сущностей и их связей (таблицы, поля, отношения).
  • Уточнение ключевых атрибутов (например, «У заказа есть статус, дата создания, сумма»).

4. Прототипирование
  • Если часть функционала связана с пользовательским интерфейсом, создаются макеты (wireframes), чтобы проверить логику экранов и переходов.

Результат функционального проектирования — более детальное описание для команды разработки, которое позволяет однозначно понять, какие именно функции нужно реализовать и как они согласованы между модулями.
Читайте наши статьи по теме:
15.3. Выявление и формализация функций системы
Функции — это «способности» системы, позволяющие ей обрабатывать запросы, управлять процессами, хранить и трансформировать данные. Системный аналитик должен:

1. Собрать все предполагаемые функции
  • Часто отталкиваются от бизнес-процессов (TO-BE), user stories и сценариев использования, выявленных на предыдущих этапах.
  • Формируют список или декомпозицию (Functional decomposition).

2. Уточнить входы и выходы для каждой функции
  • Какие данные функция принимает на вход, что выдаёт на выход?
  • Как она реагирует на ошибки, нетипичные ситуации?

3. Определить бизнес-правила и ограничения
  • Правила расчёта, проверки, валидации.
  • Например: «Функция «Расчёт скидки» учитывает статус клиента (новый, постоянный), текущие промоакции и остатки на складе».

4. Приоритизировать
  • Не всегда все функции нужны сразу. В Agile-проектах делают «построение по мере необходимости» (MVP, затем дальнейшее развитие).
  • В классических проектах может быть «этап 1», «этап 2», где часть функционала откладывают из-за бюджета или сроков.

Задача аналитика — обеспечить, чтобы каждая важная функция была не только «названа», но и достаточно подробно описана, чтобы разработчики понимали, что от них требуется, а тестировщики могли проверить результат.
15.4. Выявление и формализация атрибутов качества
Атрибуты качества (или нефункциональные требования) определяют, какой должна быть система с точки зрения производительности, надёжности, удобства поддержки и т. д. Часто их упускают из виду, сосредотачиваясь на функционале, и потом сталкиваются с проблемами на этапе внедрения или эксплуатации.

Примеры атрибутов качества:

1. Производительность (Performance)
  • Количество обработок в секунду, время отклика при определённом уровне нагрузки, время выполнения периодических задач.
  • Критично для high-load систем, онлайн-сервисов.

2. Надёжность/Отказоустойчивость (Reliability)
  • Допустимое время простоя (SLA), механизм резервирования, восстановление после сбоев.
  • Может включать географическую репликацию данных.

3. Безопасность (Security)
  • Требования к аутентификации, авторизации, шифрованию, защите от SQL-инъекций и иных уязвимостей.
  • Соответствие стандартам (PCI DSS для платёжных систем, HIPAA для медицины и т. д.).

4. Удобство сопровождения (Maintainability)
  • Требования к структуре кода, документированию, метрикам, логированию, форматам обновления.
  • Может определять, что код должен быть покрыт определённым процентом тестов, либо что все интеграции описаны в Confluence.

5. Удобство масштабирования (Scalability)
  • Как система должна реагировать на рост количества пользователей, объёма данных?
  • Распределённая архитектура, микросервисы или возможность горизонтального масштабирования.

Формализация в нефункциональных требованиях
  • Важно указывать конкретные цифры, показатели, SLA, а не писать абстрактно «система должна быть быстрой».
  • Пример: «Среднее время отклика не более 2 секунд при 5000 запросах в час», «Система должна восстанавливаться после сбоя не более чем за 10 минут».
15.5. Выявление и формализация технических ограничений
Технические ограничения могут исходить от организации (политики ИТ-департамента), поставщиков, регуляторов или сложившейся инфраструктуры. Системному аналитику важно собрать и учесть их, чтобы потом не пришлось «переделывать» систему:

1. Среда и платформы
  • «Нужно, чтобы решение работало на Windows Server 2019» или «Все сервисы должны быть контейнеризированы в Docker».
  • «БД — только Oracle, потому что корпоративный стандарт».

2. Стандарты и регламенты
  • «Код должен соответствовать внутреннему стандарту код-ревью», «Документация — в Confluence».
  • «Интеграционный протокол — только REST, SOAP-подход не допускается».

3. Лицензирование
  • «Использовать только open-source решения» или, напротив, «запрет на использование библиотек, несовместимых с корпоративной лицензией».
  • В госорганах может быть требование «только отечественное ПО» (в некоторых юрисдикциях).

4. Требования к аппаратным ресурсам
  • «Ограничение по памяти, CPU, дисковому пространству».
  • «Должно работать на существующих серверах без закупки нового оборудования».

Формализация таких ограничений на ранних этапах позволяет архитекторам и разработчикам проектировать решение, учитывая реальные рамки, и не предлагать вариант, который не будет принято ИТ-службой или руководством.
Читайте наши статьи по теме:
Вывод по главе 15
Внутрисистемный анализ — это детальное погружение в логику и характеристики системы, чтобы она соответствовала ожиданиям пользователя и бизнесу. На этом этапе:

  1. Системные требования превращаются из высокоуровневых идей и концепций в чёткие спецификации: функциональные, нефункциональные, технические.
  2. Функциональное проектирование обеспечивает понимание, какие именно операции и сценарии будет выполнять система, какова их логика и бизнес-правила.
  3. Атрибуты качества и технические ограничения не менее важны, чем функционал, ведь система может формально «уметь» всё, что нужно бизнесу, но быть неприемлемо медленной, небезопасной или слишком дорогой в эксплуатации.
Для системного аналитика этот этап требует внимания к деталям, умения задавать множество уточняющих вопросов и согласовывать противоречивые требования между разными стейкхолдерами. Итогом такой работы становится полноценное описание того, что и как предстоит реализовать внутри системы, чтобы удовлетворить цели и ограничения, зафиксированные на более ранних этапах.

Об авторе

■ Другие статьи по теме Архитектура

Показать еще

■ Другие статьи по теме Интеграция

■ Другие статьи на тему Базы данных

Показать еще

■ Другие статьи на тему User Stories и Use Cases

■ Другие статьи на тему Требований

Показать еще

■ Другие статьи на тему Бизнес-анализ

■ Другие статьи на тему Профессия и трудоустройство

Показать еще

■ Другие статьи на тему Проектное управление

■ Другие статьи на тему Менеджмент и архитектура предприятия

Показать еще

■ Другие статьи на тему Дизайн интерфейсов и исследования