Нейросети для системного аналитика: требования

Нейросети для системного аналитика: требования удобно готовить по одной короткой заявке. Ниже — готовый промпт, который копируется целиком, заполненная таблица с ID, статусом и источником, список неизвестного, четыре приёмочных сценария и проверки результата. Вход — учебный пример: «Сотрудник бронирует переговорную; занятое время нельзя занять повторно; отменяет только создатель».

Готовый промпт для требований

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

Ты — системный аналитик. На вход — краткая заявка. Сформируй требования к системе бронирования переговорных. Правила: (а) каждому требованию присвой ID вида FR-01, FR-02…; (б) для каждого требования укажи статус: ЯВНОЕ — прямо в заявке, КОСВЕННОЕ — выведено из контекста [ТРЕБУЕТ ПОДТВЕРЖДЕНИЯ], ПРОБЕЛ — данных нет [ТРЕБУЕТ УТОЧНЕНИЯ]; (в) не придумывай авторизацию, интеграции, уведомления, роли и лимиты, если их нет в заявке — относи их к ПРОБЕЛ; (г) выведи таблицу: ID | Формулировка | Статус | Источник (фраза заявки); (д) отдельным блоком — список неизвестного; (е) отдельным блоком — 4 приёмочных сценария в формате Дано/Когда/Тогда; (ж) отдельным блоком — возможные противоречия; если из заявки они не следуют, явно напиши «противоречий не установлено». Не придумывай исключения, чтобы найти конфликт. Заявка: «Сотрудник бронирует переговорную; занятое время нельзя занять повторно; отменяет только создатель».

Что менять под себя: текст заявки в конце, список запретных для домысливания сущностей в пункте (в), число приёмочных сценариев в пункте (е), язык формулировок. Правила статусов и структуру таблицы оставьте — они держат проверяемость.

Промпт устроен по общей логике, которую описывает документация Microsoft: сначала инструкция, затем основной контент, затем формат вывода. В разделе про инженерию промптов на learn.microsoft.com сказано, что порядок информации в промпте влияет на результат, а инструкцию полезно давать до контента. Там же отмечено, что ответы модели нужно проверять. Это общая методика текстовых промптов.

Яндекс Практикум в статье о промптах для анализа данных перечисляет пять элементов запроса: роль, контекст, задача, формат вывода, ограничения. Наш промпт покрывает все пять: роль аналитика, заявка как контекст, задача сформировать требования, таблица как формат, правила статусов как ограничения.

Таблица требований с ID, статусом и источником

Эталонный результат по учебной заявке — семь строк. Три требования явные, одно косвенное, три пробела. Колонка «Источник» хранит фразу заявки, из которой выведено требование.

Три статуса разделяют работу. ЯВНОЕ — формулировка прямо в заявке, её можно защитить цитатой. КОСВЕННОЕ — вывод из контекста, он требует подтверждения заказчика. ПРОБЕЛ — данных нет, нужен уточняющий вопрос. Такое разделение не даёт модели выдать догадку за согласованное требование.

Проверьте таблицу до передачи дальше. В каждой строке со статусом ЯВНОЕ колонка «Источник» содержит фразу из заявки. Если цитаты нет, требование переводится в ПРОБЕЛ или удаляется. Косвенное требование FR-04 опирается на FR-02: запрет повторного занятия слота подразумевает отказ в брони. Это следствие, и его подтверждает заказчик.

Список неизвестного

Список неизвестного заполняется вопросами. По учебной заявке он выглядит так:

• как система узнаёт, что это «создатель»;
• шаг брони (15/30/60 мин);
• можно ли бронировать несколько переговорных;
• поведение при одновременной попытке двух сотрудников;
• нужны ли уведомления;
• интеграции с календарём.

Каждый пункт — открытый вопрос к заказчику. Формулировка «как система узнаёт, что это создатель» оставляет выбор способа идентификации за человеком. Запись «авторизация по корпоративному SSO» была бы решением, которого в заявке нет.

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

Порядок работы со списком: вопросы уходят заказчику, ответы возвращаются в таблицу новыми строками или уточняют статус существующих. Пункт про идентификацию создателя при ответе превратит FR-05 из пробела в явное требование с источником.

Четыре приёмочных сценария

Приёмочные сценарии описывают поведение системы в формате Дано/Когда/Тогда. По учебной заявке их четыре.

1. Дано: слот свободен. Когда: сотрудник бронирует. Тогда: бронь создана, слот занят.
2. Дано: слот занят. Когда: другой сотрудник пытается занять то же время. Тогда: система отклоняет бронь, слот остаётся за первым.
3. Дано: бронь создана сотрудником А. Когда: сотрудник Б пытается её отменить. Тогда: отмена отклонена.
4. Дано: бронь создана сотрудником А. Когда: А отменяет. Тогда: бронь снята, слот освобождён (при подтверждении правила из FR-07).

Сценарий 1 проверяет FR-01. Сценарий 2 проверяет FR-02 и косвенное FR-04. Сценарий 3 проверяет FR-03. Сценарий 4 связан с пробелом FR-07: освобождается ли слот после отмены, заявка не задаёт. Поэтому четвёртый сценарий несёт пометку об условии.

Каждый сценарий содержит все три части. Если в блоке «Тогда» появляется проверка прав администратора или отправка уведомления, сценарий вышел за заявку. Такие шаги переносятся в список неизвестного до решения заказчика.

Сценарии дают проверяемое поведение. По ним пишутся тест-кейсы: слот свободен, слот занят, отмена чужим, отмена создателем. Четыре сценария покрывают три явных требования и одно косвенное.

Проверка противоречий

Раздел противоречий заполняется честно. По учебной заявке вывод — «противоречий не установлено». FR-02 запрещает повторно занять занятое время, FR-03 ограничивает отмену создателем. Эти правила совместимы: одно управляет занятием слота, другое — правом отмены. Конфликта между ними нет.

Модель может подтолкнуть к поиску конфликта ради заполнения раздела. Промпт это блокирует: «Не придумывай исключения, чтобы найти конфликт». Если из заявки противоречия не следуют, ответ так и звучит.

Отдельно проверьте пограничные случаи. Недоступность создателя в заявке не задана. Вопрос «нужен ли иной порядок отмены при недоступности создателя?» выносится на уточнение. Права администратора и таймаут не вводятся без решения заказчика.

Совместимые ограничения не объявляются противоречием. FR-02 и FR-03 работают вместе: слот занят до отмены создателем. Вывод «противоречий не установлено» согласован с этой совместимостью и остаётся допустимым результатом.

Проверки результата

После генерации прогоните ответ по четырём проверкам. Они ловят домыслы и незаполненные поля.

• Ни одно требование со статусом ЯВНОЕ не содержит слов «авторизация», «интеграция», «уведомление», «роль», «лимит». Их появление означает, что модель додумала.
• Каждое ЯВНОЕ требование имеет цитату из заявки в колонке «Источник».
• Вывод «противоречий не установлено» согласован с совместимостью FR-02 и FR-03; недоступность создателя остаётся вопросом.
• Все четыре сценария содержат части Дано, Когда, Тогда.

Первая проверка — поиск по тексту таблицы. Слова из списка указывают на добавленные сущности. Вторая — сверка колонки «Источник» с заявкой. Третья — чтение раздела противоречий. Четвёртая — разбор каждого сценария на три части.

Проверки применяются к ответу модели. Документация Microsoft прямо говорит: даже при аккуратном промпте ответы нужно проверять. Запрос на цитаты снижает долю недостоверных утверждений, потому что модели приходится ошибаться дважды — в формулировке и в ссылке. В нашем случае роль ссылки играет колонка «Источник».

Как читать таблицу требований и не спутать пробел с решением

Разбор удобно начать с одной строки, вокруг которой держится весь артефакт. Возьмём FR-05 «Способ идентификации сотрудника» со статусом ПРОБЕЛ. Формулировка намеренно описывает предмет вопроса. Читатель, который видит такую строку впервые, часто хочет дописать справа «вход по корпоративной учётной записи» — и получает требование, которого заказчик не давал. Проверка здесь простая: если формулировку нельзя подтвердить фразой из заявки, она остаётся вопросом. Статус ПРОБЕЛ — это рабочее состояние строки.

Дальше стоит проследить, как одна и та же фраза заявки порождает требование и его следствие. FR-02 фиксирует запрет повторного занятия слота. Из него выведено FR-04 про отклонение попытки брони. Эти две строки связаны отношением «правило — поведение системы», и подтверждать их нужно по-разному: FR-02 защищено цитатой, FR-04 опирается на логику и потому помечено как косвенное. Если заказчик скажет, что при занятом слоте система ставит сотрудника в очередь, FR-04 изменится, а FR-02 останется. Такое разделение помогает обсуждать правки точечно, не переписывая весь документ.

Отдельного внимания заслуживает строка FR-07 про освобождение слота после отмены. Она выглядит почти решённой: интуиция подсказывает, что отмена возвращает время в оборот. Заявка этого не утверждает, поэтому четвёртый приёмочный сценарий несёт пометку об условии. Читателю полезно увидеть этот приём в действии: сценарий остаётся полноценным, но его результат зависит от подтверждения правила. Так проверяющий видит, где заканчивается данное и начинается предполагаемое.

Теперь о возможной ошибке, ради которой всё построено. Модель, получив короткую заявку, стремится заполнить пустые места связным текстом. Появляются уведомления, роли, лимиты длительности, интеграция с календарём. Каждое такое добавление звучит разумно и потому опасно: оно попадает в документ как согласованное. Защита состоит из двух частей. Промпт заранее относит перечисленные сущности к пробелам. Проверка затем ищет соответствующие слова среди явных требований. Если слово найдено, строка возвращается в статус вопроса или удаляется. Действие читателя после такой находки — не спорить с формулировкой, а вернуть её заказчику как открытый пункт.

Вторая ошибка тоньше. Раздел противоречий хочется заполнить хоть чем-нибудь, и под руку попадают FR-02 и FR-03. Они действительно ограничивают поведение, но в разных плоскостях: одно про занятие слота, другое про право отмены. Совместимость проверяется вопросом «может ли система одновременно выполнять оба правила». Здесь может: слот занят, пока создатель не отменит бронь. Действие читателя — оставить вывод об отсутствии противоречий и вынести на уточнение пограничный случай с недоступным создателем, не превращая его в новое требование.

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

Отрицательная приёмка: четыре намеренно плохих фрагмента

Ниже — учебный разбор ошибок, которые может допустить модель на той же заявке. Это условные фрагменты. Каждый фрагмент показывает, где проверка обязана остановить ответ и что делает читатель.

Первый фрагмент опасен тем, что механизм входа выглядит правдоподобно и потому проходит беглое чтение. Причина отказа проста: в заявке нет ни слова о способе идентификации, а колонка «Источник» осталась бы пустой или заполненной пересказом. Действие читателя — не обсуждать SSO как решение, а вернуть строку в статус вопроса и передать заказчику. Любое условное изменение статуса согласует заказчик.

Второй фрагмент маскирует пробел под готовый сценарий. Безусловное освобождение слота звучит естественно, но заявка этого не утверждает, поэтому четвёртый сценарий теряет честную пометку об условии. Проверка здесь — сверка с FR-07: пока правило не подтверждено, результат сценария остаётся условным. Читатель сохраняет сценарий целиком и лишь фиксирует зависимость, не удаляя его и не превращая догадку в требование.

Третий фрагмент — ложный конфликт. FR-02 управляет занятием слота, FR-03 ограничивает право отмены; система выполняет оба правила одновременно, значит противоречия нет. Причина отказа — раздел заполнили ради формы.

Четвёртый фрагмент добавляет уведомление, которого в заявке нет. Формулировка выглядит безобидной, но у неё отсутствует фраза-источник, поэтому строка не может оставаться явной. Проверка ищет слова «авторизация», «интеграция», «уведомление», «роль», «лимит» среди явных требований и при находке возвращает строку в ПРОБЕЛ. Читатель переносит пункт в список неизвестного и ждёт решения заказчика, прежде чем включать его в объём работ.

Частые вопросы

Как нейросеть помогает системному аналитику с требованиями?
Модель превращает короткую заявку в таблицу требований с ID, статусом и источником. Она отделяет явные формулировки от косвенных и пробелов, готовит список неизвестного и приёмочные сценарии. Аналитик проверяет результат по формальным критериям.

Что делать, если нейросеть придумала авторизацию или уведомления?
Такие требования переводятся в статус ПРОБЕЛ или удаляются. Промпт заранее запрещает добавлять авторизацию, интеграции, уведомления, роли и лимиты. Проверка ищет эти слова среди явных требований и отмечает домыслы.

Сколько приёмочных сценариев нужно по короткой заявке?
В учебном примере их четыре: бронь свободного слота, отказ на занятый слот, отказ в чужой отмене, отмена создателем. Число сценариев задаётся в промпте. Ориентир — покрыть каждое явное требование и косвенные следствия.

Обязательно ли писать «противоречий не установлено»?
Да, когда из заявки конфликт не следует. Совместимые ограничения не объявляются противоречием. Вывод фиксирует проверку и оставляет пограничные случаи вопросами к заказчику.

Можно ли доверять готовой таблице требований?
Таблицу проверяют по колонке «Источник» и по списку запретных слов. Каждое явное требование должно иметь цитату из заявки. Ответы модели требуют проверки, о чём говорит документация Microsoft.