Задача системного аналитика здесь — составить общую картину: что из себя представляет бизнес, какие проблемы и возможности видит руководство, как новая или улучшенная система должна помочь достичь целей.
Результаты моделирования помогают определить, какие бизнес-процессы нужно автоматизировать или оптимизировать, и какая функциональность необходима в новой системе.
Структурное моделирование даёт системному аналитику «карту» бизнеса, на которой видны ключевые объекты, их взаимосвязи и ответственные лица. Это особенно важно при сложных проектах, где задействованы несколько отделов и систем.
Роль аналитика — обратить внимание на истинные причины, а не только на «симптомы». Иногда решение может заключаться вовсе не в новой информационной системе, а в изменении регламентов работы или обучении персонала.
Описание окружения помогает заранее увидеть точки интеграции и понять, какие требования к надёжности, скорости и формату данных нужно учитывать на уровне архитектуры.
Понимание границ системы, а также моделирование её взаимодействий «снаружи», не вдаваясь в детали внутренней реализации, помогает получить целостную картину, избежать дублирования функций и выявить потенциальные конфликты или пробелы.
Таким образом, научная критика (в частности, от Paul Ralph) ставит под сомнение идею, что требования — это фиксированный список того, что «объективно» нужно пользователям и бизнесу. Скорее, требование в реальном проекте — это подвижная цель, которая формируется на стыке идей, технологических ограничений, креативных решений и эволюционирующего понимания задачи.
Таким образом, современный системный аналитик должен владеть не только теорией инженерии требований, но и мягкими навыками коммуникации, фасилитации и быстрой адаптации к изменениям, а также осознавать, что «требования» нередко рождаются из диалога, компромисса и креатива.
В результате UML остался актуальным и полезным в выборе отдельных диаграмм, но всё меньше компаний пытаются моделировать все аспекты системы «до уровня кнопки». Формальная модель перестала рассматриваться как универсальная основа, а стала лишь инструментом, помогающим при сложных сценариях или архитектурных вопросах.
Вместо попытки описать «всё и сразу» с помощью UML, DDD стимулирует команду работать тесно с экспертами предметной области, многократно уточнять и развивать модель. При этом можно использовать легковесные диаграммы (Context Map, Domain Model диаграммы), но их цель — уточнять совместное понимание домена, а не выполнять генерацию кода.
Таким образом, «кризис» модель-ориентированного проектирования не означает, что UML или другие нотации совсем не нужны. Это означает лишь, что использовать их стоит осознанно, учитывая реальное «вписывание» в процессы разработки и реальные потребности команды. А подходы вроде DDD показывают, как можно проектировать систему, уделяя больше внимания богатству доменной модели и качеству кода, чем стремлению к формальной стопроцентной описательной нотации.
Таким образом, User Stories помогают аналитикам и всей команде оставаться сфокусированными на ценности и результате, а не на бесполезной детализации без учёта реальных потребностей.
При проектировании UI аналитик и дизайнер должны учитывать физические ограничения (размер экрана, устройства ввода), специфику контекста (веб-трафик, оффлайн-доступ), тип пользователей (техническая грамотность, частота использования).
Модели навигации позволяют выявить несогласованность (когда нет логичного пути к нужному экрану), лишние дублирующие пути, слишком сложные переходы. Чем яснее структура, тем проще пользователю ориентироваться.
Простые блок-схемы (Block diagrams): если не нужны формальные нотации, можно отразить основные блоки на схеме «прямоугольник—стрелки», сопровождая их описанием.
Таким образом, «проектирование состава» служит площадкой для диалога между всеми стейкхолдерами. Аналитик может визуализировать несколько альтернативных вариантов структуры и вместе с командой выбрать оптимальный, исходя из целей, рисков и ограничений.
Концептуальное проектирование — важный шаг, который помогает системному аналитику и всей команде увидеть высокоуровневую структуру будущей системы, определить ключевые модули (подсистемы, сервисы) и их взаимосвязи. На этом уровне: