Артефакты аналитики с помощью ИИ

1. Артефакты аналитики с помощью ИИ

2. Модели и инструменты

Qwen
DeepSeek
Perplexity
AI IDE BUS https://aiidebas.com/

3. Общие принципы

Процесс:
1.
1.
2.
3.
сырые требования ->
декомпозиция на user story (US) ->
подготовка артефактов к каждой US по чек-листу
Использование шаблона и образца результата
3. Предварительная настройка результата
(надежнее – добавить сформулированные в
процессе правок правила в промпт)
4. Снижение количества итераций и ненужных
результатов: предлагаю уточнить задание, если
какие-то данные нелогичны или не полные
2.

4. Шаг 1. Декомпозировать сырые данные

Контекст: вся известная информация от бизнес-аналитика, результат опроса
бизнеса в сыром виде, без структурирования
Промпт: Действуй как бизнес и системный аналитик. Декомпозируй
требования на user story. В user story прописывать Acceptance Criteria не
требуется. В качестве роли всегда должен быть пользователь. Если есть
вопросы или нужно что-то уточнить, задай вопрос до выполнения задачи
Результат ИИ: Набор User Story в формате Я, как <роль>, могу <действие>,
чтобы <цель>
Постобработка:
• Убрать лишние истории
• Объединить очень маленькие
• Переформулировать при необходимости, если ИИ пока не понял контекст
Результат: Набор историй = план работы по БТ.
• Полные формулировки будут заданы далее
• В процессе подготовки артефактов границы историй могу измениться

5. Чек-лист работы с User Story

Формулировка US
Глоссарий
Use Case
Макеты
BPMN процесса и/или алгоритма
Анализ изменений (As Is – To Be)
ФТ, описание параметров
Переводы
ДМ, КА
C4
Контракты
Доработка демо-стенда
Логирование
НФТ

6. Шаг 2. Сформулировать User Story

Промпт:
Действуй как системный аналитик. Сформулируй user story.
Тема u ser story: …
Роль пользователя: …
Контекст: …
Формат User Story: Расширенный формат, где в формулировке «Я хочу...»
указывается ключевое бизнес-требование, а детали реализации (например,
модальные окна) выносятся в критерии приемки.
Критерии приемки: Единый поток Дано / Когда / Тогда (без разбивки на
множественные сценарии).
Структура блоков: Если в секции Дано, Когда или Тогда несколько условий или
действий, они оформляются в виде ненумерованных списков.
Результат ИИ: полностью готовая US
Постобработка:
•не требуется или минимальная
•скопировать US в файл для создания следующих документов

7. Пример запроса для User Story

Промпт:
Действуй как системный аналитик. Сформулируй user story.
Тема u ser story: Редактировать код ECCN
Роль пользователя: администратор сервиса Комплаенс
Контекст: В настроечной таблице Коды ECCN пользователь может отредактировать
существующую запись. Для этого в каждой строке таблицы в колонке Действия есть
пиктограмма редактирования (карандаш). По нажатию на пиктограмму
редактирования открывается модальное окно, где пользователь может изменить
значение поля Описание или Требуется лицензия и подтвердить изменения. В
отредактированной записи должны отображаться новые значения, дата последнего
изменения и автор изменения.
Формат User Story: Расширенный формат, где в формулировке «Я хочу...»
указывается ключевое бизнес-требование, а детали реализации (например,
модальные окна) выносятся в критерии приемки.
Критерии приемки: Единый поток Дано / Когда / Тогда (без разбивки на
множественные сценарии).
Структура блоков: Если в секции Дано, Когда или Тогда несколько условий или
действий, они оформляются в виде ненумерованных списков.

8. Шаг 3. Глоссарий

Промпт:
Выяви все термины в сформулированной user story. Определи, какие термины из
выявленных могут быть синонимами. Добавлять синонимы, не используемые в user
story, не требуется. Определения давать не требуется.
Если есть вопросы или требуются уточнения, задай вопросы перед выполнением
задачи.
Результат ИИ: список существительных и групп существительных,
выявление синонимов
Постобработка: удалить общие слова – не термины, привести синонимы в
тексте к одному варианту. Проверить, что термины есть в словаре
Промпт:
Дай определение терминам:
Если есть вопросы или требуются уточнения, задай вопросы перед выполнением
задачи.
Результат:
• Все термины выявлены, определены и внесены в глоссарий

9. Шаг 4. Use Case

Промпт: Действуй как системный аналитик. Сформулируй use case для user story из вложения.
Используй формат use case из приложенного файла "Шаблон Use Case", в качестве примера
результата смотри файл “UC Запрет создания заказа без резервов". Попробуй предусмотреть все
расширения и негативные сценарии.
• Все шаги опиши с UI-видимой перспективы: зафиксированы только действия, которые
пользователь видит или выполняет в интерфейсе.
• Нумерацию расширений выполни в формате StepNumber.ExtensionNumber.SubStepNumber
(например, 3.1.1, 10.5.2)
• Каждый шаг сценария (и основного, и расширений) начинается строго со слов
«Пользователь» или «Система».
Если есть вопросы или нужны уточнения - задай перед выполнением задачи.
Результат ИИ: Готовый Use Case с возможными расширениями и
негативными сценариями, сделанный по моему шаблону
Постобработка:
• Скопировать в wiki, убрать лишние расширения
• Скопировать в файл для создания следующих документов
Результат: Пользовательский сценарий (UI-видимые шаги пользователя
и системы)

10. Шаг 5. Функциональные требования

Промпт: Действуй как системный аналитик. Сформулируй
функциональные требования для реализации user story на основе
приложенных user story и use case. Для формулировки требований
используй шаблоны, описанные в файле «Шаблон требований EARS».
• Представь результат в виде таблицы с двумя колонками: тип и
формулировка требования.
• Делать заголовок для каждого требования не нужно
•Если в блоке условий или результата несколько пунктов, укажи их в виде
ненумерованного списка
• В условии/триггере несколько элементов, укажи, требуется соблюдать
все или один из них, чтобы получить результат
Если есть вопросы или нужны уточнения, задай вопросы до выполнения
задачи.
Результат ИИ: Таблица с функциональными требованиями в нужном
формате
Постобработка:
• Скопировать в wiki
• Анализ, скорректировать или убрать лишние требования
Результат: Функциональные требования для разработки

11. Шаблон требований EARS

Easy Approach to Requirements Syntax (EARS),
предлагает простой синтаксис для спецификации
требований на естественном языке. Все требования
можно разделить на два больших класса:
Нормальное поведение (normal operation) - когда все
взаимодействующие системы ведут себя как
ожидается и соответствуют целям пользователя.
Нежелательное поведение (unwanted behaviour) любые отклонения от нормального поведения.
Все требования на естественном языке можно
сформулировать при помощи пяти простых шаблона - 4
шаблона для нормального поведения и 1 для
нежелательного
https://wiki.rbagroup.ru/pages/viewpage.action?pageId=205950178

12. Эффективность

Среднее время работы над User Story
▪ До: 10,34 ч
▪ После: 2,68 ч