Якісні вимоги до програмного забезпечення — це основа для успішної розробки, тестування та підтримки будь-якої програмної системи. Вони мають бути чітко сформульовані, однозначно трактовані всіма учасниками проєкту, повними, реалістичними та придатними для перевірки. Існує низка загальноприйнятих характеристик, які визначають якість вимог. Нижче подано основні характеристики з поясненнями та прикладами.
1. Однозначність (Unambiguousness)
Пояснення: Вимога повинна мати лише одне трактування, бути чіткою й зрозумілою для всіх: замовника, аналітика, розробника, тестувальника.
Погано:
Система має працювати швидко.
Добре:
Система повинна обробляти запит на пошук протягом не більше 2 секунд при одночасному навантаженні до 1000 користувачів.
2. “Перевірюваність” – можливість перевірки чи підтвердження (Verifiability)
Пояснення: Має бути можливість перевірити виконання вимоги шляхом тестування, інспекції або іншого методу.
Погано:
Інтерфейс повинен бути інтуїтивно зрозумілим.
Добре:
Інтерфейс має відповідати гайдам користувача Apple HIG та мати не більше 3 рівнів вкладеності меню.
3. Повнота (Completeness)
Пояснення: Вимоги мають охоплювати всі аспекти функціональності, обмежень, винятків тощо. Не повинно бути “дірок”, неясних посилань чи відсутніх частин.
Погано:
Система повинна обробляти запити користувача.
Добре:
Система повинна обробляти запити на:
- реєстрацію нового користувача,
- зміну пароля,
- видалення облікового запису.
4. Зрозумілість (Understandable / Clear)
Пояснення: Вимоги повинні бути написані простою, доступною мовою, зрозумілою всім учасникам проєкту. Варто уникати спеціалізованих термінів без пояснення.
Погано:
Система повинна реалізувати функціональність REST API з підтримкою OAuth 2.0, PKCE flow та JWT токенів без state management.
Добре (із поясненням):
Система повинна надавати REST API, що використовує протокол авторизації OAuth 2.0 з підтримкою механізму PKCE для безпечної автентифікації мобільних клієнтів.
5. “Здійсненність” або можливість реалізації (Feasibility)
Пояснення: Вимоги мають бути технічно здійсненними та відповідати часовим, фінансовим і ресурсним обмеженням.
Погано:
Система повинна мати 100% безвідмовність.
Добре:
Система повинна забезпечувати доступність на рівні 99.9% протягом місяця.
6. Послідовність (Consistency)
Пояснення: Вимоги не повинні суперечити одна одній. Усі положення повинні бути логічно узгодженими.
Погано:
Вимога 1: Користувач може скасувати замовлення в будь-який час.
Вимога 2: Замовлення не можна скасувати після оплати.
Добре:
Користувач може скасувати замовлення в будь-який час до моменту оплати.
7. Можливість трасування (Traceability)
Пояснення: Вимога повинна мати унікальний ідентифікатор і бути пов’язаною з цілями бізнесу, сценаріями використання, тест-кейсами, кодом. Це дозволяє відстежити весь життєвий цикл вимоги.
Приклад:
Вимога ID: FR-05. Пов’язана з бізнес-ціллю BG-02 (збільшення конверсії в реєстрації), сценарієм UC-01, тест-кейсом TC-05.
8. Модульність (Modularity / Atomicity)
Пояснення: Кожна вимога має описувати одну логічну функціональність, не бути надто загальною або складеною з кількох частин.
Погано:
Система має надавати авторизацію і реєстрацію, а також зміну пароля.
Добре:
- FR-01: Система повинна надавати функцію реєстрації нового користувача.
- FR-02: Система повинна надавати функцію входу користувача.
- FR-03: Користувач може змінити пароль зі свого профілю.
9. Актуальність (Up-to-date / Valid)
Пояснення: Вимоги повинні бути актуальними, відповідати реальним потребам бізнесу та не містити застарілих або скасованих положень.
Приклад:
Якщо бізнес відмовився від підтримки мобільного додатку, відповідні вимоги мають бути вилучені з документації.
10. Пріоритизація (Prioritized)
Пояснення: Вимоги мають бути розділені за рівнями важливості (наприклад: обов’язкові, бажані, додаткові). Це допомагає в плануванні релізів і розподілі ресурсів.
Приклад:
- Обов’язкова: Реєстрація користувача
- Бажана: Вхід через Google
- Додаткова: Темна тема інтерфейсу
Якісні вимоги — це запорука успішного проєкту. Невизначені, суперечливі або неповні вимоги можуть призвести до непорозумінь, збоїв у роботі програми, перевищення бюджету або незадоволення замовника. Тому дуже важливо дотримуватись вищенаведених характеристик при зборі, аналізі та документуванні вимог.