Ответ.

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

С увеличением сложности ИТ-проектов и числа вовлечённых специалистов возникла проблема: бизнес-стейкхолдеры требуют понятного описания, техкоманда — детализированного и технически выверенного. Универсального стандарта нет, и исторически системный аналитик стал "переводчиком" между мирами, адаптируя уровень формализации требований под целевую аудиторию.

Проблема:

Бизнес плохо читает диаграммы и спецификации, не разбирается в терминах UML/BPMN. Разработчикам же недостаточно пользовательских историй\user stories и общего видения — им нужны четкие критерии, схемы, схемы API, форматы данных. Если аналитик выбирает неверный формат требований, возникают риски недопонимания, несогласованности функционала и срывов сроков.

Решение:

• Определить ключевые роли/персоны среди заинтересованных сторон и провести с ними серию интервью или анкетирование для изучения их опыта, ожиданий и потребностей.
• Для бизнес-заказчика — использовать сценарии (user stories), BPMN-диаграммы, глоссарии терминов, интерактивные mockups и wireframes. Максимально избегать избыточной детализации.
• Для разработки — готовить структурированные технические спецификации (SRS, диаграммы классов, ER-диаграммы, API-описания, Acceptance Criteria), обеспечивать однозначную трактовку.
• Для внедренцев и тестировщиков — отдельные чек-листы, критерии приёмки, тест-кейсы и схемы взаимодействий.

Ключ: Один и тот же набор требований формализовать в удобном формате для каждой ЦА, не допуская разночтений.

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

• Адаптация формата требований к компетенциям и ожиданиям аудитории
• Использование нескольких взаимосогласованных представлений для одних и тех же требований
• Выбор "золотой середины" между полнотой и избыточной детализацией

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

Можно ли брать шаблон SRS (Software Requirements Specification) и передавать всем участникам проекта без изменений?

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

Часто слышно: "Диаграммы BPMN и UML полностью заменяют письменное описание требований — так ли это?"

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

Можно ли смешивать бизнесовые и технические требования в одном разделе?

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

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

• Использование только одного формата требований для всех ролей
• Избыточная детализация там, где она не нужна ("тонны схем" для бизнеса)
• Злоупотребление профессиональным жаргоном
• Отсутствие глоссария терминов, что приводит к разночтениям

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

Негативный кейс

Аналитик подготовил огромный многостраничный документ SRS на английском, в котором присутствовали сложные UML-схемы. Бизнес-стейкхолдеры его даже не открывали, команда внедрения делала выводы на глаз, получились дефекты на стыке интеграций.

Плюсы:

• Формально вся документация была

Минусы:

• Бизнес не понял функций
• Множество возвратов и доработок
• Разработчики проигнорировали часть требований

Положительный кейс

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

Плюсы:

• Быстрое согласование
• Минимум багов на старте работ

Минусы:

• Нужно было потратить время на первичную адаптацию шаблонов