Качество требований

Проверяемость - главное свойство

Требование проверяемо, если существует процедура, однозначно устанавливающая факт выполнения: тест, замер, демонстрация. Ключевое слово - однозначно: результат не должен зависеть от того, кто именно проверяет и в каком настроении.

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

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

Однозначность и атомарность

Однозначность ломается на словах-резинках: «современные браузеры», «в разумный срок», «при необходимости», «корректно обрабатывает». Каждое из них читается по-разному аналитиком, разработчиком и тестировщиком, и все трое будут уверены, что поняли правильно.

Отдельный маркер - конструкция «и/или». Почти всегда она означает не то, что вариантов правда два, а то, что решение просто не принято и его отложили. Правильная реакция - вернуться к владельцу требования и спросить, а не решить за него.

Атомарность - это одно проверяемое утверждение на требование. «Система отправляет письмо и SMS» неатомарно, и вот чем это плохо на практике: письмо работает, SMS нет. Требование выполнено или нет? Статус становится неопределённым, в отчёте о покрытии оно висит наполовину, и спор о приёмке начинается на ровном месте.

// Разделение даёт две вещи сразу: независимую приёмку каждой части и честную трассировку, где видно, какая именно половина не сделана. Стоит это одной лишней строки в документе.

Полнота на двух уровнях

Слово «полнота» означает разное применительно к набору и к отдельной строке, и путать их - значит искать дыры не тем инструментом.

У набора полнота - про охват: не забыты ли альтернативные потоки, все ли роли учтены, описано ли поведение во всех состояниях и при ошибках. Ищется обходом сценариев: берёшь путь пользователя и на каждом шаге спрашиваешь «а если нет».

У отдельного требования полнота - про самодостаточность: есть ли условие, действие и результат, не висит ли в конце «и так далее». Ищется обычной вычиткой текста, без всяких сценариев.

// Самая дорогая дыра полноты - незаданное поведение при ошибке. Оно всё равно будет реализовано: решение примет разработчик, молча и на своё усмотрение, а узнаешь ты об этом на приёмке или, что хуже, от пользователя.

Как отвечать: «Что не так с требованием: система должна быть производительной?»

Оно непроверяемо, и это не придирка: нет показателя, нет условий замера и нет порога, поэтому принять по нему работу невозможно, и спроектировать под него тоже нельзя - непонятно, на что закладываться. Я бы вернулся к автору и выяснил, где именно болит: какая страница медленная, при какой нагрузке, какое время ответа считается приемлемым. После этого требование выглядело бы примерно так: время ответа страницы каталога не превышает 300 миллисекунд на 95-м перцентиле при нагрузке 200 запросов в секунду в промышленной среде. Такую формулировку уже можно заложить в нагрузочный тест и по ней принять работу без единого спора.

Кандидат называет дефект, показывает три недостающие части, говорит, что именно пойдёт выяснять, и переписывает требование в проверяемый вид. Три шага вместо одного диагноза.

На чём валятся

• −− Считают, что согласованное требование и есть качественное: подписать можно и совершенно непроверяемую формулировку.
• −− Сами решают за владельца, что означало «и/или», вместо того чтобы вернуться и спросить.
• −− Путают полноту набора с полнотой формулировки и ищут дыры не тем инструментом.
• −− Пишут критерии только на успешный путь: поведение при ошибках доопределяет разработчик.
• −− Гонятся за подробностью вместо проверяемости: длинный текст без критерия приёмки остаётся пожеланием.