1. От требования до работающей системы: где заканчивается текст и начинается системный анализ

Требование — это ещё не решение.

Фраза «система должна обеспечивать формирование отчёта» выглядит вполне законченной. Но для системного аналитика работа с неё только начинается. Что именно должно попасть в отчёт? Откуда поступают данные? Кто имеет право его сформировать? Что происходит, если часть данных недоступна? В каком формате выдаётся результат? Сколько времени допустимо ждать? Нужно ли сохранять историю формирования?

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

Например: «Система должна уведомлять Пользователя об изменении статуса заявки».

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

В результате исходное требование можно представить уже как последовательность:

событие → бизнес-правило → обработка → интеграция → результат → контроль результата.

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

В этой точке техническое письмо становится частью системного анализа.