1️⃣Критерії вимог

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

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

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

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

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

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

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

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

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

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

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

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

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