QA Engineer

— Измеримость — должен существовать способ проверить, выполнено требование или нет.

— Достижимость — требование должно быть достижимым в рамках ресурсов проекта, его ограничений и доступных технологий.

— Атомарность — требование должно быть настолько неделимым, насколько это возможно.

— Релевантность — требование должно быть важным для бизнес — целей проекта.

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

— Непротиворечивость — требования не могут противоречить друг другу, они должны быть согласованы.

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

— Проверяемость — должна быть возможность протестировать требование, чтобы определить, что система его выполняет.

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

— Проранжированность — требования должны быть отсортированы в соответствии с важностью целей.

Далее рассмотрим примеры критериев качества требований. Учтите, что каждый пример описывает конкретный критерий, но для простоты может намеренно нарушать другие.

Пример конкретности требования

В хорошем примере корректно описано, что должна делать система, когда она должна совершать действия, каким способом и в рамках какого времени. Это требование очень важно, так как для каждого участника команды «быстро» — субъективное понятие, а значит работу системы каждый оценит по-своему.

Пример измеримости требования

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

Пример достижимости требования

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

Пример атомарности требования

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

Пример релевантности требования

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

Пример полноты требования

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

Пример непротиворечивости требования

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

Пример модифицируемости требования

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

Пример проверяемости требования

В хорошем примере существует однозначный способ проверить во время тестирования, выполнено ли требование. В то же время, «приятный» пользовательский интерфейс является очень субъективным понятием.

Пример отслеживаемости требования