Эра оркестратора. Как выжить системному аналитику в мире победившего ИИ. ИИ для системного аналитика: от требований до ГОСТов

Итоговая карточка, готовая к импорту в Jira:

User Story

Как зарегистрированный покупатель,

Я хочу иметь возможность восстановить доступ к своему аккаунту с помощью одноразового SMS-кода,

Чтобы быстро войти в систему и завершить покупки, если я забыл свой текущий пароль.

Acceptance Criteria (критерии приёмки)

Сценарий 1: успешное восстановление пароля (Happy Path)

• Given (Дано): пользователь находится на экране «Восстановление пароля» и ввёл свой валидный номер телефона, привязанный к профилю.

• When (Когда): пользователь нажимает кнопку «Получить код» и вводит корректный 4-значный код из SMS в течение 180 секунд с момента отправки.

• Then (Тогда): система перенаправляет пользователя на экран ввода нового пароля, содержащий поля «Новый пароль» и «Подтвердите пароль».

Сценарий 2: истечение срока действия SMS-кода (негативный)

• Given (Дано): система сгенерировала и отправила пользователю SMS-код, но с момента отправки прошло более 180 секунд (три минуты).

• When (Когда): пользователь вводит этот код в поле подтверждения и нажимает «Проверить».

• Then (Тогда): система блокирует верификацию, отображает ошибку «Срок действия кода истёк» и активирует ссылку «Запросить код повторно».

Сценарий 3: превышение лимита попыток ввода (безопасность / защита от brute-force)

• Given (Дано): пользователь ввёл неверный 4-значный код из SMS три раза подряд.

• When (Когда): пользователь совершает четвёртую попытку ввода неверного кода или пытается повторно нажать кнопку «Получить код».

• Then (Тогда): система блокирует возможность отправки и верификации SMS-кодов для данного номера телефона на 30 минут, отображая на экране таймер обратного отсчёта и текст: «Доступ заблокирован из-за частых запросов. Попробуйте через 30 минут».

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

К чему это приведёт? Злоумышленник запустит скрипт перебора кодов напрямую через API, обходя мобильный интерфейс, или обычный пользователь просто закроет приложение, откроет его снова, память обнулится, и он сможет подбирать код дальше. Баланс компании на SMS-шлюзе улетит в трубу за час.

Твоя задача как системного аналитика — вмешаться, заблокировать эту генерацию и жёстко дописать техническое требование к бэкенду: «На уровне бэкенда в кеше Redis необходимо реализовать два разных ключа с разным временем жизни (TTL) для разграничения бизнес-логики и безопасности:

1. Ключ самого SMS-кода (например, sms_code: phone_number): содержит сгенерированные четыре цифры. Время жизни ключа TTL = 3 минуты (180 секунд) по требованию бизнеса. По истечении этого времени ключ автоматически удаляется, делая старый код невалидным.

2. Ключ счётчика блокировки (например, sms_block: phone_number): инкрементируется при каждой неудачной попытке ввода. При достижении трёх попыток флаг блокировки фиксируется в Redis со временем жизни TTL = 30 минут. Бэкенд должен мгновенно отдавать фронтенду ошибку 423 Locked на любые запросы авторизации по этому номеру, пока ключ блокировки не удалится по тайм-ауту».

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

Глава 2. Проектирование интеграций и API с помощью ИИ

Генерация контрактов API (REST, gRPC, GraphQL) по текстовому описанию

Когда-то аналитики гордились тем, что могут без единой ошибки в отступах написать руками 500 строчек YAML-файла для Swagger. Сегодня этот навык не стоит ничего. Расстановка двоеточий, скобок и дефисов — это чистая механика, которую нужно со свистом делегировать ИИ.

Твоя ценность как аналитика теперь в другом — ты проектируешь семантику и поведение ресурса. Ты решаешь, какой HTTP-метод использовать (PATCH для частичного изменения или PUT для полной замены), как обеспечить идемпотентность и какие бизнес-коды ошибок возвращать команде фронтенда.

Давай посмотрим, как ИИ справляется с генерацией контрактов под три разных архитектурных стиля на основе обычного текстового ТЗ.

1. REST API (формат OpenAPI 3.0 / Swagger)

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

Промпт высокой точности:

text

Роль: API-архитектор и системный аналитик.

Задача: напиши валидную спецификацию OpenAPI 3.0 в формате YAML на основе текстового описания метода.

Контекст метода:

— Действие: обновление статуса заказа курьером.

— Путь: /api/v1/orders/ {orderId} /status

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.