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 - Примеры инженерии требований

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