Ответ.

История вопроса:

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

Проблема:

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

Решение:

Системный аналитик активно собеседует архитекторов, DevOps, QA, интеграторов:

• Определяет технологические стеки, бизнес- и инфраструктурные зависимости.
• Согласует требования с архитектурными принципами: SLA, отказоустойчивость, масштабируемость, ограничения по лицензиям или безопасности.
• Фиксирует и валидацирует компромиссы между возможностями и хотелками бизнеса.
• Применяет подходы «Scenario-based analysis» и «Non-functional requirements».

Ключевые особенности:

• Ранняя фиксация ограничений и зависимостей со всеми ответственными.
• Документирование компромиссов и неявных ограничений.
• Постоянная сверка проектных решений с архитектурой компании.

Вопросы с подвохом.

Можно ли игнорировать неявные технические ограничения, если они не сказаны прямо?

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

Должен ли аналитик участвовать в архитектурных созвонах/воркшопах?

Верно: Да, системный аналитик — связующее звено между бизнесом и архитекторами, транслирует требования обеим сторонам и фиксирует решения.

Достаточно ли собрать только бизнес-требования и не анализировать унаследованные ограничения?

Верно: Недостаточно. Унаследованный код, лицензии, интеграции (legacy) иногда диктуют большее количество ограничений, чем явно заданные требования.

Типовые ошибки и анти-паттерны

• Недооценка скрытых ограничений и зависимости старых систем.
• Игнорирование «нерукописных» правил архитектуры.
• Фиксация только бизнес-части без учета технической реализуемости.

Пример из жизни

Негативный кейс: Аналитик зафиксировал интеграцию по бизнес-процессу, но не узнал ограничений по скорости передачи данных в интерфейсе.

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

Положительный кейс: Аналитик участвовал в архитектурных сессиях, выявил ограничения (максимум потоков = 100, интеграция 1 раз в 10 секунд), согласовал с бизнесом режущие лимиты.

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