С2 · Шпаргалка: PRD, вимоги, AC, UAT і тест-кейси

Роль: ти — бізнес-аналітик; готуєш PRD (Product Requirements Document) — документ, з якого розробка, QA і дизайн беруть вимоги до функції.

Вхідні дані: запит від бізнесу — нижче, між рядками ===. Працюй лише з ним.

Задача: склади PRD функції за форматом нижче.

Критерії приймання:
- кожна вимога має стабільний ID: FR-<ОБЛАСТЬ>-NN — функціональні, NFR-<ОБЛАСТЬ>-NN — нефункціональні, TC-<ОБЛАСТЬ>-NN — технічні обмеження, BC-<ОБЛАСТЬ>-NN — бізнес-обмеження; область — коротке слово латиницею (ADDR, PAY, UI…), NN — 01, 02…;
- одна вимога — одне твердження, яке можна перевірити; біля кожної — джерело: коротка цитата із запиту або позначка «припущення»;
- чисел, строків і правил, яких у запиті немає, не вигадуй — пиши «[питання до автора: …]»;
- NFR — лише з вимірюваним порогом; якщо порогу в запиті немає — «[поріг — питання до автора]»;
- суперечності в запиті не вирішуй сам: винеси їх у «Відкриті питання» з варіантами рішення.

Формат відповіді (Markdown):
1. Проблема і мета — з метрикою успіху, якщо вона є в запиті.
2. Користувачі.
3. Обсяг: у межах і поза межами.
4. Вимоги — чотири таблиці FR, NFR, TC, BC: «ID | Вимога | Джерело».
5. Припущення.
6. Відкриті питання — що спитати і в кого.

===
<вставте запит>
===

Роль: ти — бізнес-аналітик; готуєш PRD функції і не пишеш його, доки не з'ясуєш головне.

Вхідні дані: запит від бізнесу — нижче, між рядками ===. Працюй лише з ним і з моїми відповідями.

Задача: працюй у два кроки. Крок 1 — постав уточнювальні питання і зупинись: чекай моїх відповідей. Крок 2 — після моїх відповідей склади PRD.

Критерії приймання:
- не більше семи питань, найважливіші — першими;
- одне питання — одне рішення, з варіантами відповіді;
- питай лише про те, що змінить вимоги: суперечності в запиті, хто користувач, межі обсягу, числа, строки й пороги;
- до моїх відповідей PRD не пиши;
- у PRD кожна вимога має стабільний ID TYPE-AREA-NN: FR — функціональні, NFR — нефункціональні (лише з вимірюваним порогом; якщо порогу немає ні в запиті, ні в моїх відповідях — «[поріг — питання до автора]»), TC — технічні обмеження, BC — бізнес-обмеження;
- біля кожної вимоги — джерело: цитата із запиту або «відповідь на питання N»; на що я не відповів — лишається у «Відкритих питаннях»;
- чисел і правил, яких немає ні в запиті, ні в моїх відповідях, не вигадуй.

Формат відповіді: крок 1 — таблиця «№ | Питання | Чому це важливо | Варіанти відповіді»; крок 2 — PRD з розділами «Проблема і мета», «Користувачі», «Обсяг», «Вимоги» (таблиці FR, NFR, TC, BC: «ID | Вимога | Джерело»), «Припущення», «Відкриті питання».

===
<вставте запит>
===

Роль: ти — QA-інженер і бізнес-аналітик, які рецензують PRD, перш ніж із нього писатимуть вимоги до розробки й тести.

Вхідні дані: PRD і, якщо є, вихідний запит — нижче, між рядками ===.

Задача: знайди в PRD проблеми, які заважатимуть розробці й тестуванню.

Критерії приймання:
- вимоги, які не можна перевірити: слова без міри, кілька тверджень під одним ID;
- NFR без вимірюваного порогу;
- неправильний тип: метрика успіху чи бізнес-мета записана як NFR; правило поведінки системи записане як TC (TC — це стек, інтеграції, платформа, дані; правило поведінки — це FR);
- суперечності між вимогами, а також між PRD і запитом;
- обмеження, яких бракує: гроші, строки, ролі, межі дії функції;
- проблеми з ID: дублікати, ID без типу чи області, перенумеровані ID;
- прогалини обсягу: що не віднесено ні до «у межах», ні до «поза межами», і вимоги без джерела;
- для кожної проблеми — ID і коротка цитата; рішень не вигадуй — якщо його немає в запиті, це питання до автора.

Формат відповіді: таблиця «ID | Проблема | Тип | Що змінити | Питання».

===
<PRD>
===
<вихідний запит, якщо є>
===

Роль: ти — аналітик, який відповідає за трасування вимог.

Вхідні дані: документ вимог (PRD, вимога чи сторі з AC) і, якщо є, AC, тест-кейси чи UAT-сценарії — нижче, між рядками ===.

Задача: 1) присвой стабільні ID вимогам документа; 2) прив'яжи AC, тест-кейси і UAT-сценарії до ID і покажи прогалини.

Критерії приймання:
- граматика ID — TYPE-AREA-NN: FR — функціональна, NFR — нефункціональна, TC — технічне обмеження, BC — бізнес-обмеження; AREA — коротке слово латиницею, NN — 01, 02…;
- наявні ID не змінюй і не перенумеровуй; нова вимога отримує наступний вільний номер у своїй області;
- одне твердження — один ID; якщо вимогу треба розділити, покажи, з якої вона виникла;
- ID тест-кейсів (TC-01, TC-02…) не змінюй: у тест-кейса немає області, у технічного обмеження — є (TC-STACK-01);
- кожен AC, тест-кейс і UAT-сценарій — з посиланням на один чи кілька ID; зв'язків, яких не видно з тексту, не вигадуй.

Формат відповіді: 1) таблиця «ID | Тип | Вимога | Було» (у «Було» — старий номер або «новий»); 2) таблиця «ID | AC | Тест-кейси | UAT-сценарії»; 3) три списки: «FR без тесту», «Тести без FR», «NFR без порогу».

===
<документ вимог>
===
<AC, тест-кейси чи UAT-сценарії, якщо є>
===

Роль: ти — досвідчений бізнес-аналітик і тест-дизайнер, який рецензує вимогу перед тим, як її візьмуть у розробку.

Вхідні дані: вимога «<назва функції вашого варіанту>» — сторі й acceptance criteria — нижче, між рядками ===.

Задача: знайди проблеми у вимозі і сформулюй уточнювальні питання до автора.

Критерії приймання:
- для кожної проблеми — місце (AC1…AC7, сторі, нотатка), коротка цитата і тип: неоднозначність, неповнота, суперечність, порушення INVEST, неоднозначна межа;
- поясни, чому це заважає розробці чи тестуванню;
- не вигадуй правил, яких немає у вимозі; якщо чогось бракує — це питання, а не відповідь;
- щонайменше п'ять конкретних питань, на кожне можна відповісти одним рішенням.

Формат відповіді: таблиця «№ | Де | Цитата | Тип | Чому проблема», потім нумерований список «Уточнювальні питання».

===
<повний текст requirement.md>
===

Роль: той самий аналітик.

Задача: перепиши acceptance criteria вимоги так, щоб кожен можна було перевірити.

Критерії приймання:
- формат Given / When / Then;
- без слів без міри («швидко», «зручно», «коректно») — або число, або окреме питання;
- щонайменше один негативний і один межовий критерій;
- де відповідь залежить від відкритого питання, познач «залежить від питання N» і не вигадуй рішення.

Формат відповіді: нумерований список AC1…ACn, під кожним — з якого старого AC чи питання він виник.

Роль: бізнес-аналітик, який готує приймальне тестування разом із власником продукту.

Задача: склади UAT-сценарії за acceptance criteria вище.

Критерії приймання:
- мовою користувача, без технічних кроків;
- кожен сценарій посилається на AC;
- щонайменше чотири сценарії, зокрема негативний і межовий;
- не додавай поведінки, якої немає в AC.

Формат відповіді: таблиця «№ | Сценарій | Передумови | Кроки | Очікуваний результат | AC».

Роль: досвідчений тест-дизайнер.

Задача: склади тест-кейси за acceptance criteria вище.

Критерії приймання:
- кожен кейс посилається на AC;
- позитивні, негативні й межові; для меж — значення на межі, під нею і над нею;
- кроки й очікуваний результат — конкретні, з тест-даними;
- щонайменше шість кейсів; не вигадуй поведінки, якої немає в AC — якщо бракує даних, познач «потребує відповіді на питання N».

Формат відповіді: таблиця «ID | Назва | Передумови | Кроки | Тест-дані | Очікуваний результат | Тип | AC».

Побудуй матрицю покриття: рядки — AC, стовпці — сценарії чи тест-кейси вище. Познач AC без жодного сценарію, дублікати (два кейси перевіряють одне й те саме) і кейси, що не спираються на жоден AC.

Роль: бізнес-аналітик, який розбирає баг-репорт разом із QA.

Вхідні дані: вимога і баг-репорт — нижче, між рядками ===.

Задача: розбери баг-репорт мовою аналітика.

Критерії приймання:
- це дефект коду чи прогалина вимоги — з посиланням на конкретний AC або на те, що AC бракує;
- чого бракує в самому репорті, щоб його відтворити чи оцінити;
- чи не змішано в одному репорті кілька проблем;
- що змінити у вимозі: новий або уточнений AC.

Формат відповіді: розділи «Класифікація», «Зв'язок з вимогою», «Чого бракує в репорті», «Пропозиція до вимоги».

===
<вимога>
===
<bug-report.md>
===

Роль: аналітик, який узгоджує вимоги з кількох джерел.

Задача: знайди суперечності між джерелами і вимогою та запропонуй узгоджене рішення.

Критерії приймання:
- кожна суперечність — з цитатами з обох джерел;
- рішення з обґрунтуванням: чому саме так і хто має його підтвердити;
- відкриті питання — окремо, з адресатом;
- не вигадуй позицій, яких немає в джерелах.

Формат відповіді: таблиця «Суперечність | Джерело А | Джерело Б | Рішення | Обґрунтування | Хто підтверджує», потім «Відкриті питання».