> For the complete documentation index, see [llms.txt](https://swit-school.gitbook.io/qa-book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://swit-school.gitbook.io/qa-book/testuvannya-igor/vimogi-ta-yikh-testuvannya/kriteriyi-vimog.md).

# Критерії вимог

**Як же тестується GDD документ?** Щоб зрозуміти, що вимоги описані погано, потрібно звичайно ж в першу чергу розуміти, як повинні виглядати добре описані вимоги. Хороші вимоги визначаються згідно наступних критеріїв якості:

**Атомарність.** Відповідно до цього критерію, вимоги повинні бути описані так, щоб їх не можна було уточнити ще детальніше або розбити одну вимогу на декілька. Приклад поганої вимоги – користувач може зареєструватися та ввести своє ім'я, вибрати аватар. Реєстрація та введення/зміна  імені, аватара - це дві різні функції, які повинні бути описані і уточнені в різних пунктах специфікації. Приклад хорошої вимоги – користувач може зареєструватись скориставшись акаунтом соціальної мережі Facebook.

**Завершеність.** Вимоги до одного функціоналу повинні бути описані в одному пункті специфікації. Не можна допускати ситуацію, коли один і той самий функціонал описаний в різних частинах документа.

**Послідовність.** Вимога не повинна суперечити іншим вимогам та обмеженням системи. Наприклад: із соціальних мереж повинен запитуватися телефонний номер користувача. Очевидно, що дана вимога суперечить обмеженням соціальних мереж, так як номер телефону є прихованою інформацією, яку соціальні мережі не надають. Користувач повинен сам ввести номер телефону, щоб система його отримала. Подібних протиріч не повинно бути і між пунктами специфікації. Наприклад, одна і та ж кнопка повинна називатися однаково у всьому документі.

**Відстеження (Трасування).** Критерій, який дозволяє зрозуміти, чому було прописано саме таку вимогу. Наприклад, для гри, яка містить в собі криваві сцени, ненормативну лексику або сцени насилля вимогою може бути реєстрація тільки повнолітніх користувачів у зв'язку із законодавчими обмеженнями.

**Актуальність.** Критерій, який перевіряє відповідність вимог до сучасних реалій (наприклад, із законодавчого/технічного боку або з боку зручності використання продукту, актуальності його користувацького інтерфейсу). Не варто прописувати у вимогах застарілі версії Андроїда або застарілі мобільні девайси та їх ОС, тому що вони практично не використовуються.

**Здійсненність.** Перевірка на те, що вимогу можливо реалізувати за допомогою актуальних існуючих на даний момент технологій. Наприклад, вимога того, що гра повинна давати швидкий відгук (тут потрібна конкретизація – не довше, ніж 3 секунди) при помірному навантаженні (тут також потрібна конкретизація за кількістю користувачів та виконуваних ними дій) може існувати. Але вимога відгуку менше секунди при дуже великому навантаженні – нездійсненна в сучасних реаліях вимога.

**Зрозумілість (доступність).** Вимога має бути сформульована  достатньо чітко, конкретно та однозначно, для того, щоб вона однаково розумілася всією командою розробки.

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

**Обов'язковість.** Визначення того, наскільки важливе та пріоритетне виконання даної вимоги. Всім вимогам в специфікації повинні бути призначені важливість, стабільність та пріоритет. За допомогою цього вибираються першочергові значення для виконання командою розробки завдання.

**Ідентифікація.** У кожної вимоги повинен бути унікальний ідентифікатор, за допомогою якого вимога прив'язується до інших артефактів проекту. Наприклад, в описі тест-кейса вказується ідентифікатор вимоги, яка перевіряється цим тест-кейсом.

**Модифікація.** Вимоги повинні бути легко модифіковані (внесення змін) за необхідності.

**Повнота.** Найскладніший критерій, згідно з яким вимоги повинні вичерпно описувати весь функціонал системи. Все, що система повинна виконувати, повинно бути зафіксовано у вимогах, інакше можна зробити серйозну помилку під час проектування архітектури. Складність у тому, що на початкових етапах проектування системи дуже важко точно вказати та описати всі функції. Вимоги спочатку описуються більш загальними твердженнями, а далі уточнюються.