Ще трошки по нефункціональним вимогам. Як специфікувати атрибути якості?🤔 Практичні способи наступні:

1. Частина критеріїв прийняття. Ніхто не забороняє їх безпосередньо вписувати серед інших вимог. Приклад:
"
- Користувач може ініціювати завантаження звіту ABC за обраний період.
- Максимальний час завантаження даних за максимально доступний період не має перевищувати 1 хвилину.
"⏱

2. Окремим розділом у вимогах (NFRs, Quality Attributes). Іноді доцільніше описати окремо як сценарій з фокусом на те, що саме потрібно перевірити, адже сценарій може поєднувати кілька критеріїв прийняття у одній користувацькій історії. Приклад: ви описуєте форму реєстрації чи опитування, всілякі поля, логіку. У цьому випадку можна описати сценарій:
"
- Новий користувач, що потрапляє на форму опитування, має витратити не більше 2 хвилин на заповнення обов'язкових полів.
"📝

Виходячи з цього, висуваються вимоги до багатьох факторів:
🎨 Дизайн користувацького інтерфейсу (обрання потрібних елементів для заповнення, формулювання питань);
⚡️ Поведінка у часі (наприклад, швидкість завантаження даних для вибору, як-от введення адреси);
🔒 Безпека (наприклад, спосіб чи необхідність підтвердження певних даних).

3. Окрема сторінка нефункціональних вимог/атрибутів якості 📄
Такий підхід доречний:
- На старті проєкту 🛠 – коли зібрані лише високорівневі нефункціональні вимоги, які вже потрібно десь зберігати.
- Для ведення реєстру 📂 – якщо одні й ті самі атрибути якості та їх значення поширюються на різні функціональні вимоги у багатьох місцях системи.

Наприклад, на такі вимоги можна посилатися у користувацьких історіях чи задачах Jira:
🔗 Вказувати посилання у Jira на вимогу "Fault Tolerance" на відповідне місце у Confluence при описі автоматизованого процесу.
🆔 Також можна давати унікальні ідентифікатори таким вимогам (наприклад, "FLT-003" при лінкуванні).

Чи пробували якось документувати атрибути якості ? Поділіться досвідом в коментах 🙌

#NFRs