Проверка требований с помощью ИИ: как найти слабые места до разработки
В 1С-разработке часть проблем появляется не из-за плохого кода. Часто разработчик делает ровно то, что описано в спецификации требований. Проблема в другом: в самой спецификации осталось слишком много недосказанного.
Не указали, что делать со старыми документами. Не описали права. Не учли печатную форму. Не проверили, куда новые данные уходят через обмен. Не зафиксировали критерии приемки. Не спросили, что делать при ошибке. Не заметили, что один и тот же термин разные отделы понимают по-разному.
На старте это выглядит как мелочи. После релиза превращается в привычное:
- “а почему это не попало в отчет?”;
- “а почему пользователь не видит документ?”;
- “а почему старые договоры пустые?”;
- “а это же должно было уходить в обмен”;
- “а мы думали, что согласование будет работать иначе”;
- “а можно еще немного поправить?”.
Я понимаю скепсис к таким темам. Когда статья называется “проверка требований с помощью ИИ”, легко ожидать очередной текст про волшебную кнопку. Но в 1С-проектах ИИ полезен не как волшебная кнопка, а как быстрый способ устроить черновое ревью текста.
ИИ хорошо подходит не для того, чтобы заменить аналитика, а для того, чтобы стать вторым внимательным проверяющим. Он не знает внутренней кухни проекта, не отвечает за бизнес-решения и не понимает контекст лучше живых участников. Но он умеет быстро разбирать текст, искать противоречия, задавать уточняющие вопросы, находить пропущенные сценарии и смотреть на спецификацию требований с разных сторон.
Я использую ИИ именно в этой роли: не как автора требований, а как рецензента. Он помогает не забыть очевидное, на что в потоке задач легко не обратить внимания.
При этом я не переношу ответы ИИ в спецификацию требований автоматически. В его ответах часто есть полезные вопросы, но бывают и фантазии: лишние статусы, сложные уведомления, отдельные регистры, избыточные проверки. Поэтому сначала я отделяю полезное от красивого, а потом уже решаю, что действительно нужно уточнить у заказчика или обсудить с разработчиком.
ИИ не заменяет аналитика
Сначала важное ограничение. ИИ не отвечает за корректность требований. Ответственность остается на аналитике, заказчике и команде проекта.
ИИ не знает, как реально работает конкретный отдел. Он не видит негласные договоренности пользователей. Он не понимает, почему в одной компании договоры согласуют через 1С:Документооборот, а в другой половина процесса живет в почте и мессенджерах. Он может уверенно предложить красивый, но неподходящий вариант.
Поэтому я не использую ИИ как источник истины. Я использую его как проверочный инструмент:
- найти неясные формулировки;
- показать пропущенные вопросы;
- разложить требования по зонам риска;
- проверить полноту сценариев;
- вытащить скрытые допущения;
- подсказать, какие роли и права нужно уточнить;
- напомнить про данные, отчеты, обмены и приемку.
Это похоже на ревью спецификации требований коллегой. Только коллега не всегда свободен, а ИИ можно подключить быстро. Но итоговое решение все равно принимает человек.
Для меня главный признак нормального использования ИИ простой: после проверки появляется не “красивый текст”, а список конкретных вопросов. Если вопросов не стало больше, значит, ИИ не помог проверить требования, а просто отполировал формулировки.
Когда ИИ особенно полезен
ИИ полезнее всего там, где текст уже есть. Не просто “сделай требования”, а именно “проверь этот текст”.
Например, есть описание доработки:
- новое поле в документе;
- изменение маршрута согласования;
- новый отчет;
- доработка печатной формы;
- изменение прав доступа;
- новый статус документа;
- изменение обмена;
- автоматическое заполнение реквизитов;
- обработка старых данных.
В таких задачах легко пропустить связанный участок. Поле добавили, а отчет забыли. Маршрут описали, а возврат на доработку не учли. Права указали общими словами, а конкретные роли не перечислили. Обмен упомянули, но не описали, что делать при ошибке.
ИИ хорошо помогает пройтись по таким местам. Он не устает, не привыкает к тексту и не стесняется задать глупый, но полезный вопрос.
Чаще всего он помогает на простых с виду задачах. Именно там команда расслабляется: “добавить реквизит”, “вывести колонку”, “поменять маршрут”, “добавить отбор”. Потом оказывается, что этот реквизит нужен в отчете, отбор зависит от прав, маршрут влияет на старые документы, а колонка должна уходить в обмен.
Что нельзя отправлять в ИИ
Перед использованием ИИ нужно сразу договориться с собой о безопасности.
В ИИ нельзя бездумно отправлять:
- персональные данные сотрудников и клиентов;
- ИНН, КПП, номера договоров, паспортные данные, зарплатную информацию;
- коммерческие условия договоров;
- внутренние адреса серверов, токены, ключи, логины, пароли;
- исходный код закрытых обработок без разрешения;
- описание конфиденциальных бизнес-процессов в узнаваемом виде;
- данные заказчика, если договор или внутренние правила это запрещают.
Я сначала обезличиваю текст. Вместо реального контрагента пишу “Контрагент А”. Вместо названия компании — “Организация 1”. Вместо ФИО — “Пользователь с ролью согласующего”. Вместо настоящих сумм — диапазоны или условные значения. Вместо точного текста договора — обобщенное описание.
ИИ нужен для проверки структуры требований, а не для хранения чужих данных.
Как подготовить спецификацию требований к проверке
Перед отправкой текста в ИИ я привожу спецификацию требований к рабочему виду. Если отправить хаотичный набор сообщений из чата, ИИ тоже вернет хаотичные советы.
Минимальная структура, с которой удобно работать:
- цель задачи;
- текущий процесс;
- что нужно изменить;
- участники процесса;
- основной сценарий;
- исключения;
- данные и реквизиты;
- права доступа;
- отчеты и поиск;
- печатные формы;
- интеграции и обмены;
- старые данные;
- ошибки и сообщения пользователю;
- критерии приемки;
- что не входит в текущий объем.
Даже если часть разделов пустая, это полезно. Пустой раздел сразу показывает, где есть риск. Например, если в задаче меняется документ, а раздел “Права доступа” пустой, я уже вижу вопрос для заказчика.
На этом этапе ИИ не нужен для красоты. Мне важно, чтобы он увидел структуру и смог пройтись по ней как проверяющий: где пусто, где слишком общо, где есть противоречия, где не хватает сценариев.
Проверяю понятность текста
Самая простая проверка — попросить ИИ найти неясные формулировки.
Пример промпта:
Проверь спецификацию требований для 1С-доработки. Найди неясные, двусмысленные и непроверяемые формулировки. Для каждой формулировки объясни, почему она опасна, и предложи, какой вопрос нужно задать заказчику. Не переписывай весь текст, сначала дай список проблемных мест.
ИИ хорошо ловит фразы вроде:
- “должно быть удобно”;
- “нужно сделать быстро”;
- “права как у руководителя”;
- “отчет как в Excel”;
- “согласование по обычному маршруту”;
- “данные должны подтягиваться автоматически”;
- “ошибка должна быть понятной”;
- “старые документы обработать при необходимости”.
Такие фразы выглядят привычно, но для разработки они слабые. “Удобно” нельзя проверить. “Как в Excel” не объясняет правила расчета. “Обычный маршрут” у разных отделов может означать разное. “При необходимости” не говорит, кто принимает решение.
После такой проверки я не принимаю предложения ИИ автоматически. Я использую их как список вопросов к заказчику или к себе.
Проверяю сценарии и исключения
В спецификации требований часто хорошо описан основной сценарий и плохо описаны исключения.
Например, основной сценарий такой: пользователь создает заявку, руководитель согласует, бухгалтерия проверяет, документ уходит дальше. На бумаге все красиво. Но в жизни бывают возвраты, отмены, замещения, срочные заявки, разные организации, филиалы, лимиты, ошибки заполнения и документы задним числом.
Промпт для проверки сценариев:
Проверь описание сценария 1С-процесса. Найди пропущенные альтернативные сценарии, исключения и ошибки. Отдельно проверь: возврат на доработку, отмену, изменение данных после согласования, замещение участника, отсутствие прав, пустые обязательные поля, старые документы, повторный запуск процесса.
Хороший промпт не заменяет нормальное обследование. Он только помогает проверить, какие вопросы я еще не задала по уже собранному материалу.
После такой проверки ИИ часто предлагает вопросы, которые легко пропустить в обычной спешке:
- что делать, если согласующий в отпуске;
- можно ли изменить документ после согласования;
- что происходит при возврате на доработку;
- кто видит комментарии согласующих;
- можно ли отменить процесс;
- нужно ли хранить историю изменений;
- что делать, если процесс запустили ошибочно;
- можно ли повторно отправить документ на согласование.
Это не значит, что все сценарии нужно реализовывать сразу. Но их нужно хотя бы осознанно обсудить. Иногда команда решает: “В первой версии отмену процесса не делаем”. Это нормальное решение, если оно зафиксировано.
Здесь ИИ полезен именно как занудный проверяющий. Он не знает, какие исключения действительно нужны в проекте, но он напоминает: исключения существуют, и их нельзя полностью прятать за фразой “обычный сценарий”.
Проверяю данные и старые документы
В 1С задачи часто ломаются на данных. Форма открывается, кнопка нажимается, маршрут стартует, но отчет показывает пустоты, обмен не получает значение, старые документы не попадают в выборку.
Я отдельно проверяю требования на вопросы по данным:
- какие реквизиты появляются;
- кто их заполняет;
- обязательные они или нет;
- какие значения допустимы;
- что происходит при пустом значении;
- нужно ли автозаполнение;
- есть ли история изменения;
- что делать со старыми документами;
- нужно ли массовое заполнение;
- как эти данные используются в отчетах и обменах.
Промпт:
Проверь требования с точки зрения данных в 1С. Найди все реквизиты, статусы, даты, суммы и справочники, которые участвуют в задаче. Для каждого элемента проверь: источник заполнения, обязательность, старые данные, использование в отчетах, правах, печатных формах и обменах. Сформируй список вопросов к заказчику.
Полезный результат такой проверки — список не “как сделать”, а “что уточнить”. Например:
- кто заполняет новый реквизит;
- нужно ли заполнять его в старых документах;
- что делать с документами за прошлые периоды;
- нужна ли обработка массового заполнения;
- может ли реквизит изменяться после проведения;
- нужно ли выводить его в список, отчет, печатную форму;
- участвует ли он в обмене с другой базой.
У меня такие проверки чаще всего срабатывают на простых доработках: добавили реквизит, на новых документах все красиво, а потом вспоминаем про историю за прошлый год. ИИ в таких местах полезен не потому, что знает нашу базу, а потому что настойчиво спрашивает: “А что со старыми документами?”
Отдельная классика: на новых тестовых документах все работает, а на продуктиве руководитель открывает отчет за прошлый год и видит пустые колонки. Это не ошибка отчета. Это неучтенная история данных.
Проверяю права доступа
Права доступа лучше проверять до разработки, а не на последнем тестировании.
ИИ помогает разложить задачу по ролям. Особенно если в требованиях написано что-то общее: “доступ имеют ответственные пользователи”, “руководители видят документы своего подразделения”, “согласующие могут выполнять задачи”.
Промпт:
Проверь спецификацию требований с точки зрения прав доступа в 1С. Составь список ролей пользователей. Для каждой роли проверь: просмотр, создание, изменение, удаление, согласование, доступ к файлам, доступ к отчетам, ограничения по организации, подразделению, проекту и контрагенту. Найди места, где права описаны слишком общо.
Такая проверка быстро показывает, где нужно уточнять модель доступа:
- кто видит документ;
- кто видит вложенные файлы;
- кто может менять реквизиты;
- кто может запускать процесс;
- кто может согласовывать;
- кто может вернуть на доработку;
- кто видит отчет;
- кто видит документы других подразделений;
- кто получает доступ к архивным документам.
В 1С:Документообороте это особенно важно. Документ может зависеть от рабочей группы, грифа доступа, роли, участия в процессе, подразделения и настроек видимости файлов. В ЗУП появляются кадровые и зарплатные ограничения. В БП важны организации, закрытые периоды, регламентированный учет и права на изменение документов.
Самая частая ловушка — проверить сценарий под пользователем с широкими правами. В тесте все проходит, а обычный согласующий потом не видит вложенный файл или не может выполнить задачу. ИИ хорошо вытаскивает такие вопросы, если прямо попросить проверять роли отдельно.
Но и здесь нужно фильтровать. Иногда ИИ начинает предлагать слишком сложную модель доступа: дополнительные роли, отдельные группы, новые статусы видимости. Я не переношу это в требования как готовое решение. Сначала оставляю вопрос: “Нам действительно нужна такая детализация прав или достаточно существующей ролевой модели?”
Проверяю отчеты, поиск и контроль результата
Заказчик часто описывает, как создать документ или запустить процесс, но не всегда говорит, как потом контролировать результат.
Например, добавили новый вид заявки. Форма работает, маршрут согласования идет, уведомления приходят. Через месяц руководитель спрашивает: “Где посмотреть все заявки по подразделениям, срокам и статусам?” И выясняется, что в требованиях отчет не описан.
Промпт:
Проверь требования с точки зрения отчетов, списков, отборов и поиска. Найди данные, которые пользователи будут искать или контролировать после запуска. Проверь, нужны ли новые колонки, отборы, группировки, варианты отчетов, выгрузка в Excel, расшифровка до документов и права на просмотр отчетов.
После такой проверки появляются нормальные вопросы:
- как пользователь найдет созданный документ;
- нужны ли новые колонки в списке;
- нужен ли отбор по статусу, подразделению, ответственному, периоду;
- нужно ли выводить новый реквизит в отчет;
- кто смотрит отчет;
- нужна ли выгрузка в Excel;
- нужна ли расшифровка до документа;
- нужно ли ограничивать отчет правами.
Хороший вопрос, который я задаю после такой проверки:
Когда доработка начнет работать, как вы будете понимать, что процесс идет нормально?
Этот вопрос часто выводит на отчеты, уведомления, контрольные списки и статусы, о которых в начале не говорили.
Проверяю интеграции и обмены
В 1С почти любое изменение может затронуть обмены. Новый реквизит может уйти в другую базу. Статус может передаваться в ЭДО. Документ может участвовать в обмене с сайтом, CRM, СЭД, складской системой или внешним сервисом.
Если про интеграции вспомнить в конце, появляется неприятный сценарий: в одной базе все работает, а обмен падает или передает неполные данные.
Промпт:
Проверь требования с точки зрения интеграций 1С. Найди все данные, статусы, документы и события, которые могут передаваться в другие системы или приходить из них. Составь вопросы по формату обмена, обязательным полям, ошибкам, повторной отправке, ответственным за внешнюю систему и проверке интеграции.
ИИ обычно вытаскивает вопросы:
- какие данные передаются наружу;
- какие данные приходят из другой системы;
- нужно ли менять формат обмена;
- что делать, если внешняя система не приняла новое поле;
- как обрабатывать ошибку обмена;
- кто видит статус ошибки;
- можно ли повторить отправку;
- кто отвечает за вторую сторону интеграции;
- какими данными проверяем обмен.
Здесь ИИ особенно полезен как напоминатель. Аналитик знает про обмены, но в конкретной задаче легко увлечься формой, маршрутом или отчетом и забыть про соседнюю систему.
На практике я не спрашиваю ИИ “как сделать обмен”. Для этого нужны конкретная конфигурация, формат, API, код, настройки и ограничения проекта. Я прошу его проверить, не забыты ли вопросы по обмену: что передаем, куда передаем, кто отвечает за вторую сторону, что делаем при ошибке и как проверяем результат.
Проверяю ошибки и сообщения пользователю
В требованиях часто хорошо описан нормальный путь и плохо описаны ошибки.
Пользователь заполнил все правильно — документ провелся. А если поле пустое? Если дата меньше текущей? Если нет прав? Если обмен недоступен? Если регламентное задание не выполнилось? Если документ уже согласован, но его пытаются изменить?
Промпт:
Проверь требования с точки зрения ошибок и нестандартных ситуаций. Найди места, где нужно описать проверку данных, текст сообщения пользователю, возможность продолжить работу, запись ошибки в журнал, повтор операции и действия поддержки.
После такой проверки нужно уточнить:
- какие проверки выполняются при записи или проведении;
- какие сообщения видит пользователь;
- можно ли сохранить черновик;
- можно ли провести с предупреждением;
- кто получает уведомление об ошибке;
- пишется ли ошибка в журнал или регистр;
- что делает пользователь после ошибки;
- что делает поддержка.
Фраза “вывести понятную ошибку” не подходит для спецификации требований. Нужно писать конкретнее: когда возникает ошибка, какой текст видит пользователь и что он делает дальше.
Иногда ИИ предлагает слишком много обработки ошибок: отдельные уведомления, статусы, журналы, повторные механизмы, служебные регистры. Я не считаю это готовым решением. Но такие предложения полезны как повод спросить: “Какие ошибки действительно критичны, а какие достаточно закрыть обычным сообщением пользователю?”
Проверяю критерии приемки
Критерии приемки — одно из самых слабых мест в требованиях. Часто задача описана подробно, но непонятно, по каким признакам заказчик принимает результат.
ИИ хорошо помогает превратить описание в проверяемые сценарии.
Промпт:
На основе спецификации требований составь список критериев приемки. Раздели их по сценариям: основной сценарий, исключения, права доступа, старые данные, отчеты, печатные формы, обмены, ошибки. Каждый критерий сформулируй так, чтобы его можно было проверить в тестовой базе.
После такого запроса можно получить заготовку для приемки:
- пользователь с ролью инициатора создает документ;
- обязательные поля проверяются при записи;
- согласующий видит задачу и вложенные файлы;
- при возврате на доработку инициатор получает задачу;
- новый реквизит отображается в списке и отчете;
- старые документы за выбранный период обработаны;
- обмен передает новый реквизит во внешнюю систему;
- при ошибке обмена пользователь видит понятное сообщение;
- пользователь без прав не видит закрытые документы.
Такой список нельзя просто копировать без проверки. Но он помогает быстро увидеть, какие сценарии нужно обсудить с заказчиком и тестировщиком.
Проверяю границы задачи
Еще один полезный сценарий — попросить ИИ найти то, что может незаметно расширить объем задачи.
Промпт:
Проверь спецификацию требований и найди возможные зоны расширения объема. Отдельно выпиши, что стоит явно отнести к текущей задаче, что нужно вынести в отдельные задачи, а что нужно зафиксировать как “не входит в текущий объем”.
Это помогает заранее увидеть потенциальные “а еще”.
- добавили реквизит — значит, может понадобиться отчет;
- добавили статус — значит, может понадобиться история изменений;
- изменили маршрут — значит, нужно проверить возвраты и замещения;
- добавили печатную форму — значит, может понадобиться хранение версии формы;
- изменили данные — значит, может понадобиться обработка старых документов;
- изменили документ — значит, возможно, потребуется изменение обмена.
Я фиксирую границы задачи прямо в спецификации требований. Это не защита от заказчика. Это способ одинаково понимать результат.
ИИ в этом месте часто помогает увидеть “хвосты”, которые команда не обсуждала. Но дальше нужно принимать обычное проектное решение: что входит в текущий объем, что уходит в отдельную задачу, а что сознательно не делаем.
Как выглядит рабочий процесс проверки
У меня проверка требований с помощью ИИ обычно идет по шагам.
- Сначала я готовлю черновик спецификации требований.
- Обезличиваю текст: убираю реальные названия, ФИО, договоры, суммы, адреса, технические ключи.
- Отправляю ИИ не весь текст “на улучшение”, а конкретный запрос на проверку.
- Получаю список вопросов, рисков и слабых мест.
- Отбрасываю лишнее и неподходящее.
- Полезные вопросы задаю заказчику или команде.
- После уточнений обновляю спецификацию требований.
- Финально проверяю сценарии, права, данные, обмены и приемку.
Ключевой момент — я не прошу ИИ “сделай красиво”. Красивый текст не равен хорошим требованиям. Я прошу найти проблемы.
Такой подход хорошо дисциплинирует и самого аналитика. Когда просишь ИИ найти слабые места, приходится сначала самому нормально собрать текст: цель, сценарии, данные, права, исключения, приемка. Иначе проверять нечего.
Пример общего промпта для проверки спецификации требований
Ниже пример промпта, который можно адаптировать под свою задачу.
Ты опытный аналитик 1С и рецензент спецификаций требований. Проверь текст ниже перед передачей в разработку. Не переписывай текст полностью. Найди слабые места, пропущенные вопросы, двусмысленности и риски. Проверь отдельно: цель, основной сценарий, исключения, данные, старые документы, права доступа, отчеты, печатные формы, интеграции, ошибки, критерии приемки и границы задачи. Результат дай таблицей: раздел, проблема, почему это риск, какой вопрос задать заказчику, что нужно дописать в спецификацию требований.
Такой промпт задает ИИ роль, контекст и формат ответа. Главное — он просит не “улучшить текст”, а провести ревью.
Еще раз: хороший промпт не заменяет нормальное обследование. Он только помогает проверить, какие вопросы я еще не задала по уже собранному материалу. Если материала нет, ИИ начнет додумывать вместо проекта.
Пример результата проверки
Допустим, в спецификации требований написано:
Добавить в документ “Заявка” поле “Категория”. Поле заполняет пользователь. Значение используется для маршрута согласования. Руководитель должен видеть заявки по категориям.
После проверки ИИ может вернуть такие вопросы:
| Проблема | Почему это риск | Что уточнить |
| Не указан список категорий | Пользователи будут выбирать значения произвольно или потребуется доработка справочника | Категории фиксированные или редактируемые? |
| Не описаны старые заявки | Маршрут и отчет могут работать только для новых документов | Нужно ли заполнить категорию в старых заявках? |
| Не описаны права | Неясно, кто может менять категорию и кто видит заявки | Кто заполняет, меняет и просматривает поле? |
| Не описан отчет | Руководитель “должен видеть”, но неясно где именно | Нужен новый отчет, колонка в списке или отбор? |
| Не описаны ошибки | Неясно, что делать, если категория не заполнена | Поле обязательное? Можно ли сохранить черновик? |
Это простой пример, но именно такие вопросы часто экономят время. До разработки их обсудить спокойно. После разработки каждый такой пункт превращается в уточнение, переделку или спор.
Типовые ошибки при работе с ИИ
Первая ошибка — просить ИИ написать требования с нуля. Он напишет гладко, но легко придумает лишнее или пропустит важный контекст.
Вторая ошибка — отправлять конфиденциальные данные без обезличивания. Для проверки структуры требований реальные ФИО, договоры и суммы обычно не нужны.
Третья ошибка — принимать ответ ИИ без проверки. ИИ может уверенно предложить неподходящий сценарий, несуществующее ограничение или лишнюю сложность.
Четвертая ошибка — просить “улучшить текст” вместо “найти риски”. После такого запроса можно получить красивую, но бесполезную редактуру.
Пятая ошибка — забывать про контекст конфигурации. Требования для 1С:Документооборота, БП и ЗУП проверяются по-разному. В ДО важны процессы, роли и файлы. В БП — учет, организации, закрытие периода. В ЗУП — кадровые данные, зарплата, права и регламентированные сценарии.
Что ИИ проверяет плохо
ИИ не всегда хорошо понимает ограничения конкретной конфигурации и конкретной базы.
Он может не знать:
- какие доработки уже есть в базе;
- как настроены роли и права;
- какие регламентные задания используются;
- какие обмены уже работают;
- какие расширения подключены;
- какие есть внутренние правила разработки;
- какие ограничения приняты в команде сопровождения.
Поэтому после проверки ИИ все равно нужна профессиональная проверка аналитика и разработчика. ИИ помогает найти вопросы. Он не подтверждает техническую реализуемость и не согласует бизнес-решение.
Иногда он предлагает правильную по форме, но лишнюю по жизни доработку. Например, может предложить отдельный статус, журнал, уведомление и отчет там, где достаточно одного понятного сообщения пользователю и записи в существующий механизм. Поэтому я смотрю не только на то, “можно ли так сделать”, но и на то, нужно ли это конкретному процессу.
Мини-чек-лист проверки требований с помощью ИИ
Перед передачей спецификации требований в разработку я проверяю ее по такому списку:
- понятна бизнес-цель задачи;
- описан основной сценарий;
- описаны исключения;
- понятны роли участников;
- указаны права доступа;
- описаны данные и источники заполнения;
- решено, что делать со старыми документами;
- проверены отчеты, списки, отборы и поиск;
- учтены печатные формы;
- проверены интеграции и обмены;
- описаны ошибки и сообщения пользователю;
- есть критерии приемки;
- зафиксировано, что не входит в текущий объем;
- текст не содержит конфиденциальных данных перед отправкой в ИИ;
- все предложения ИИ проверены человеком.
Этот чек-лист можно использовать и без ИИ. Но ИИ ускоряет проверку и помогает посмотреть на текст свежим взглядом.
Итог
ИИ не делает аналитику за аналитика. Он не знает реальный процесс лучше заказчика, не отвечает за бизнес-решения и не гарантирует корректность требований.
Но ИИ хорошо работает как второй проверяющий спецификации требований. Он помогает найти неясности, пропущенные сценарии, риски по данным, правам, отчетам, обменам, старым документам, ошибкам и приемке.
Главное — использовать его не как генератор красивого текста, а как инструмент ревью. Задача не в том, чтобы спецификация требований стала гладкой. Задача в том, чтобы она стала проверяемой, полной и понятной для разработки, тестирования и заказчика.
ИИ полезен не тогда, когда пишет требования вместо аналитика, а тогда, когда помогает найти вопросы, которые аналитик задает до разработки.
Если после проверки появляется список конкретных вопросов к заказчику, разработчику или тестировщику — ИИ использован правильно. Если после проверки появился только красивый текст без новых уточнений, пользы мало.