Вариант 1

1. Какие варианты работы с требованиями нужно отразить в модели жизненного цикла для учета непрерывности по­ступления требований в проект?

• требование или группа требований обрабатываются до начала работ над проектом

• специально отражать в модели эту ситуацию не нужно

• требование или группа требований обрабатываются до начала работ итерации

• требование или группа требований поступают, когда работы итерации начались

О требование или группа требований поступают, когда работы итерации завершились и релиз системы передан в эксплуата­цию

2. В чем состоит анализ проблем?

• он выявляет проблемы реализации требований к проектируе­мой программной системе

• он нацелен на определение того, какие средства должны быть реализованы

• он выявляет первичные нужды пользователей

• он нацелен на определение ранжированного по степени важности списка потребностей пользователей с перечислением следствий решения данной проблемы

• он направлен на выявление реальных проблем пользователей, для преодоления которых предназначена проектируемая программная система

3. Что такое многомерность требований?

• необходимость рассмотрения атрибутного набора требований при решении задачи их отбора для различных целей

• противоречивость атрибутов требований

• фактическое содержание требования отражает несколько по­желаний к системе

• несводимость параметров отбора требований к одному измере­нию (т.е. к одному показателю)

• различные характеристики требования, рассматриваемые сов­ местно

Вариант 2

1. Укажите возможные варианты результата анализа требований.

• требование отклоняется

• требование замораживается до следующего проекта

• требование принимается к реализации на текущей итерации

• требование откладывается до одной из следующих итераций

• требование условно принимается к реализации на текущей итерации

2. Прием «понимание пользовательских потребностей» нужен для:

• выяснения средств программной системы, которые необходимы

• упорядочения требований по степени актуальности для реализации

• того, чтобы построить систему типов требований для данного проекта

• определения требований, реализуемых в рамках ближайшей задачи проекта

• определения требований, реализуемых в рамках ближайшей и перспективных задач проекта

3. Что включает в себя определение системы?

• соглашения о разработке: виды рабочих продуктов, правила их построения, проверки

• внешние рабочие продукты и способы их использования в проекте

• общие соглашения о том, как понимаются требования и из приоритетность, оценка затрат на разработку и ресурсных потребностей, какие рисковые ситуации вероятны и стратегия управления рисками

• оценка границ применимости проектируемой системы

характеристика требуемого коллектива исполнителей

Вариант 3

1. Какие действия не рассматриваются как этапы обработки требований?

• обработка поступления требования или совместной группы требований

• принятие решения о переходе к анализу

П расщепление линии жизненного цикла, переход к анализу

• принятие решения об анализируемых требованиях

• планирование будущей итерации реализации

2. Что означает многофункциональность требований?

• определение границ применимости разрабатываемой про­граммной системы

• различные требования предполагают разные варианты приме­ нения разрабатываемой системы

• существует множество типов пользователей с разной потребностью в разрабатываемой системе

• различные инициаторы работ характеризуют будущее или раз­виваемое программное изделие с разных сторон

• требования фиксируют множество функций, которые должны поддерживаться программной системой

3. Какая задача решается при управлении областью приме­нимости системы?

• ранжирование инициаторов работ с точки зрения предоставле­ния ими требований, наиболее важных для реализации систе­мы

• ранжирование требований к программной системе по степени актуальности для реализации с точки зрения инициаторов ра­ бот

• выбрать приоритетное с точки зрения инициаторов работ на­ правление развития проекта в условиях имеющихся на данный момент ресурсов (время, кадры, финансы)

• составление формализованных описаний требований к про­граммной системе, пригодных для передачи разработчикам

• составление точного описания системы, согласованного со всеми заинтересованными в проекте сторонами