Яндекс Практикум

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

Может показаться, что это пустая трата времени, поэтому команда разработки иногда неохотно уделяет время проверке и тестированию спецификации требований к ПО. Но если пропустить этот этап, выше риск обнаружить ошибку, когда продукт уже разработан. Из этого следует, что проверка требований до того, как разработчики приступили к созданию ПО, позволит команде избежать лишних действий и растягивания сроков проекта.

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

Мы уже рассказывали о том, что входит в проверку требований. Давайте вспомним, какие активности включает этот процесс:

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

Рецензирование требований пользователями

Лучшего способа написать идеальные требования не существует. Опыт всему голова. Может помочь конструктивная критика со стороны коллег. Она позволит посмотреть на требования со стороны, поможет понять, выполняет ли текст свою задачу, есть ли у него недочёты и прочее. Вот почему важно рецензирование требований.

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

Рецензирование подразделяют на формальное и неформальное. В чём разница?

Неформальное рецензирование полезно для знакомства пользователя с продуктом и сбора отзывов. Но у такого рецензирования нет чёткой структуры.
Неформальное рецензирование предполагает, что каждый участник самостоятельно оценивает продукт и совместное обсуждение требований необязательно. Например: вы можете попросить своего коллегу изучить требования, а позже собрать результат и, если необходимо, встретиться для обсуждения.
У неформального рецензирования есть свои минусы. Например, рецензент может интерпретировать требования не так, как задумал системный аналитик. Поэтому, если не проводить обсуждение, неверное понимание никуда не денется.
Формальное рецензирование представляет собой строго регламентированный процесс. После него формируется отчёт, в котором указаны материалы, участники рецензирования и их мнения о приемлемости составленных требований. Главный результат формального рецензирования — его участники обнаруживают дефекты в продукте и обсуждают их. Самая известная форма такого вида рецензирования — экспертиза.

Экспертиза состоит из нескольких этапов:

Определение списка участников. Чаще всего присутствуют автор спецификации, команда разработки и заинтересованные лица (источник требований).
Рассылка участникам материалов, необходимых для проведения рецензирования.
Встреча участников. Её цель — выявить в представленной спецификации как можно больше ошибок и обсудить их. Это позволит сделать требования качественными и понятными для всех рецензентов. Все замечания на встрече нужно фиксировать.
Переработка требований. Если это необходимо, начинается этап обработки требований, зафиксированных в результате встречи.
Проверка требований: все ли проблемы, которые выловили в ходе экспертизы, исправлены, все ли вопросы закрыты.

Определение заказчиками критериев приёмки требований для оценки готовности продукта

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

Критерии приёмки — это минимальные условия, при которых приложение можно считать готовым к промышленной эксплуатации.

Рассмотрим критерий приёмки на примере (спойлер: он снова про еду).

Допустим, вы готовите шоколадный брауни. Критерии приёмки его готовности таковы:

Десерт тёмно-коричневого цвета.
Корочка сверху плотная, но трескается, если отломать кусочек ложкой.
Внутри десерт немного влажный.

Важно понимать, что критерии приёмки команда пишет вместе с заинтересованными лицами. Для того чтобы правильно сформулировать критерии, можно задаться вопросом: «Как вы делаете вывод о том, что система удовлетворяет вашим потребностям?»

Возможно, будет проще написать критерии приёмки, если применять правило SMART. Тогда критерии должны быть:

Конкретными (Specific)
Измеримыми (Measurable)
Достижимыми (Attainable)
Актуальными (Relevant)
Ограниченными во времени (Time-sensitive)

Допустим, у нас есть требование к ПО: пятого числа каждого месяца формировать новый отчёт. Критерии приёмки тут такие:

Отчёт отправляется на формирование пятого числа каждого месяца.
Формирование отчёта занимает не более 10 минут.
Отчёт успешно сформирован.
В случае неуспешного формирования нужно отправить письмо сотрудникам техподдержки с просьбой вручную сформировать отчёт.

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

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

Разработка приёмочных тестов, которые должны подтвердить готовность продукта

Когда мы готовили брауни, один из критериев приёмки для него звучал так: «Внутри десерт немного влажный». Какой приёмочный тест для такого критерия может быть? Каковы критерии влажности или пропечённости десерта?

Разные виды выпечки можно протестировать по-разному. Например, для печенья и галет влажность теста невысокая, а брауни должен быть куда более влажным. Песочное печенье выпекают до влажности 6–8%, галеты — до влажности более 10–12%, а брауни как вид бисквитного теста — до влажности 18–20%. Таким образом, приёмочный тест, проверяющий критерий «внутри десерт немного влажный», звучит как «когда влажность брауни достигает 18–20% — десерт немного влажный, следовательно, готов».

Как же приёмочные тесты могут помочь при проверке требований?

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

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

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

Чек-лист качества требований

Как отличить качественные требования от некачественных?

Для начала давайте разберёмся, что такое качественное требование? Качественным считается требование, которое не вызывает дополнительных вопросов у команды разработки, не приводит к ошибкам в продукте и другим проблемам при реализации ПО.

Проверить, качественные ли у вас требования, поможет специальный чек-лист:

Полнота. Требование должно содержать всю необходимую для его понимания информацию и учитывать все возможные «что, если», которые могут возникнуть в процессе использования продукта.
Непротиворечивость. Требование не должно противоречить другим требованиям. Проверить его на непротиворечивость можно с помощью самостоятельного ревью или ревью в команде.
Корректность. Каждое требование должно точно отражать потребность заинтересованных лиц и при этом чётко определять функциональность, которую надо реализовать.
Осуществимость. Не все требования можно выполнить. Команда разработки может реализовать решение для удовлетворения требования в рамках известных технических, временных и ресурсных ограничений. Некоторые из требований неосуществимы, например, потому, что на данный момент нет инструментов, которые позволяли бы реализовать требование с использованием адекватного количества ресурсов.
Необходимость. Каждое требование описывает возможности ПО или его характеристику, которые нужны какому-либо заинтересованному лицу.
Однозначность. Все читатели требований должны интерпретировать каждое из них одинаково. Если требование неоднозначно, вы не можете определить, насколько требование качественно, так как каждый читатель воспринимает его по-разному.
Проверяемость. QA-инженер проверяет, действительно ли в продукте реализовано каждое требование. Если требование не поддаётся проверке, нельзя утверждать, что оно выполнено.

Проверка требований

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

Рецензирование требований пользователями

Определение заказчиками критериев приёмки требований для оценки готовности продукта

Разработка приёмочных тестов, которые должны подтвердить готовность продукта

Чек-лист качества требований

Подведём итоги