Описатели

Требования к качеству

В требованиях к качеству фиксируются такие характеристики системы, как производительность, загрузка, доступность, специальные возможности, удобство обслуживания и сопровождения. Эти требования обычно имеют форму ограничений на функционирование системы.

Состояния и переходы

Состояние: Новое: Требования к качеству добавляются в список, который находится в папке требований библиотеки документов, или с помощью описателя в Team Explorer (Проводник команды).

• Переход: От нового к активному
  • Основание: Новое: Требование к качеству активируется как новое припервом создании.

Состояние: Активное: Работа с требованием к качеству начинается в активном состоянии. Бизнес-аналитик фиксирует требование, указывая для него информативное название, и заполняет поле описания как можно более подробными сведениями о требовании. После того как требование полностью сформулировано, бизнес-аналитик назначает его ведущему разработчику. В поле "Specified" (Сформулировано) устанавливается значение "Yes" (Да) и требование остается в активном состоянии на время его реализации. Ведущий разработчик координирует с другими разработчиками действия, необходимые для реализации требований.

• Переход: От активного к обработанному
  • Основание: Завершено: Требование к качеству переводится в состояние обработанного на основании "Completed" (Завершено), если команда разработчиков закончила написание кода, реализующего данное требование. Ведущий разработчик назначает требование тестировщику.
  • Основание: Отложено:Требование к качеству считается обработанным с основанием "Deferred" (Отложено), если в данной итерации реализовать его невозможно. Реализация требования может быть отложена из-за нехватки времени у разработчиков или обнаружения проблем, блокирующих работу. В поле "Iteration" (Итерация) нужно указать правильный номер итерации, в которой требование будет реализовано. Если осуществление требования откладывается до следующей версии продукта, поле "Iteration" нужно оставить пустым. Не забудьте подробно описать причины, по которым отложена реализация требования, и укажите планируемые сроки работы над ним.
  • Основание: Удалено: Требование к качеству удаляется ("Removed"), если больше не считается целесообразным. При удалении требования проверьте поля "Issue" (Препятствие) и "Exit Criteria" (Условия завершения). Обычно для удаленных требований в этих полях содержится "No" (Нет).

Состояние: Обработанное: После реализации требования к качеству ведущий разработчик устанавливает его состояние в "Resolved" (Обработанное). Ведущий разработчик также назначает это требование тестировщику после чего может начаться проверка требования.

• Переход: От обработанного к закрытому
  • Основание: Завершено: Требование к качеству закрывается как "Completed" (Завершено), когда тестировщик сообщает о прохождении тестов. При завершении работы с требованием проверьте поля "Issue" (Препятствие) и "Exit Criteria" (Условия завершения). Обычно для реализованных требований в этих полях содержится "No" (Нет).
  • Основание: Отложено: Требование к качеству считается закрытым с основанием "Deferred" (Отложено), если в данной итерации реализовать его невозможно.
  • Основание: Удалено: Требование к качеству закрывается как удаленное ("Removed"), если оно больше не считается целесообразным.

• Переход: От обработанного к активному
  • Основание: Тест не проходит: Требование к качеству возвращается в активное состояние, если не проходит один или несколько тестов. Тестировщик должен снова назначить данное требование ведущему разработчику, который его зафиксировал. Тестировщик также должен создать соответствующий описатель дефекта для сбоя теста.

Состояние: Закрытое: Тестировщик переводит работу с требованием в состояние "Closed" (Закрыто) при прохождении всех тестов. Требование также закрывается, если оно откладывается, удаляется или разбивается на более мелкие.

• Переход: От закрытого к активному
  • Основание: Повторная активация: Отложенное требование к качеству активируется заново, когда начинается итерация, на которую назначена его реализация. Если требование все еще нужно задокументировать, назначьте его бизнес-аналитику Если же требование готово к реализации, назначьте его ведущему разработчику. При повторной активации удаленных требований, следуйте той же процедуре, что и для отложенных требований.