iSAQB CPSA-A REQ4ARC

Опис

Участь у курсі iSAQB® CPSA-A Requirements for Software Architects (REQ4ARC) дає учасникам 20 балів за методологічну компетентність (MC) і 10 балів за технічну компетентність (TC) у межах 70 балів, необхідних для допуску до іспиту iSAQB CPSA-A з Brightest. Важливо пам’ятати, що в межах 70 балів, необхідних для складання іспиту iSAQB CPSA-A з Brightest, потрібно набрати щонайменше десять балів за компетентності в кожній із таких областей: 

• Технічна компетентність (TC)
• Методологічна компетентність (MC)
• Комунікативна компетентність (CC)

Акредитоване навчання iSAQB® REQ4ARC - Requirements for Software Architects (CPSA-A) базується на актуальній навчальній програмі iSAQB®:

Частина 1 - Чіткий початок

• Навіть за ітеративної розробки необхідно розуміти певні попередні дії
• Необхідно добре розуміти та чітко формулювати бачення, цілі й відповідних зацікавлених сторін
• Розуміти необхідність визначення меж системи та її контексту, особливо інтерфейсів між межами системи й контекстом (тобто зовнішніх інтерфейсів продукту)

Частина 2 - Робота з функціональними потребами

• Знати визначення функціональних вимог
• Уміти відрізняти функціональні вимоги від вимог до якості та обмежень

Частина 3 - Робота з вимогами до якості та обмеженнями

• Знати визначення вимог до якості та обмежень
• Розуміти, що межа між функціональними вимогами та вимогами до якості може бути дуже тонкою, оскільки деякі атрибути можуть бути виражені через функції

Частина 4 - Розробка на основі поведінки

• Знати, що BDD охоплює підходи та технології, пов’язані з такими практиками, як TDD (Test-Driven Development) і ATDD 
• Знати, що існують різні способи специфікації вимог
• Знати, що BDD застосовується до широкого спектра типів ІТ-систем, наприклад інформаційних систем, систем бізнес-аналітики та мобільних застосунків

Частина 5 - Пріоритизація та оцінювання вимог

• Знати різні методи вираження цінності, наприклад пріоритизацію MoSCoW, визначені діапазони цінності, лінійне ранжування всіх вимог, методи зважених факторів і вартість затримки
• Розуміти, що різні зацікавлені сторони можуть по-різному оцінювати цінність вимог

Частина 6 - Взаємодія між ролями

• Розуміти, що ітеративна розробка системи охоплює всі сторони, залучені до процесу розробки
• Знати, що архітектори постійно взаємодіють із бізнес-аналітиками та фахівцями з вимог, а також із розробниками й тестувальниками

Частина 7 - Інструменти інженерії вимог

• Знати різні типи інструментів для роботи з вимогами (карти, вікі, інструменти моделювання, системи відстеження завдань тощо)

Частина 8 - Приклади інженерії вимог

• Знати приклади добре сформульованих вимог різних категорій