В требовании «система должна быть удобной» команда спорит о трактовке. Как аналитик преобразует его в проверяемый сценарий качества?
Аналитик преобразует расплывчатую формулировку в сценарий качества: указывает источник стимула, контекст, наблюдаемое поведение системы и измеримый критерий результата. Например, вместо «система должна быть удобной» фиксируется: «Новый оператор при стандартном сценарии оформления заявки выполняет его без обучения не более чем за 3 минуты, совершая не более одной ошибки».
Функциональные требования описывают, что система делает, но не всегда определяют, насколько быстро, понятно, надёжно или безопасно она должна это делать. Расплывчатые нефункциональные требования появились как практическая проблема: разные участники одинаково соглашались с формулировкой, но по-разному оценивали результат.
Сценарный подход возник как способ связать качественное свойство с наблюдаемым поведением и измерением. Он помогает сделать такое требование предметом проектирования, тестирования и приёмки.
Слово «удобная» не задаёт ни целевого пользователя, ни его задачи, ни условий выполнения, ни допустимого результата. Разработчик может считать удобным минимальное число экранов, заказчик — отсутствие ошибок, а тестировщик — успешное прохождение сценария большинством пользователей.
Если оставить формулировку без уточнения, критерий готовности станет субъективным. Это приводит к поздним спорам, переделкам интерфейса и невозможности доказать, что требование выполнено.
Сначала аналитик определяет качественный атрибут: например, удобство следует уточнить через эффективность работы, обучаемость, предотвращение ошибок или доступность. Само слово «удобство» обычно не является достаточной измеримой категорией.
Затем формируется сценарий качества из следующих элементов:
Полезная формулировка должна описывать наблюдаемое поведение, а не способ реализации. Например: «Оператор, ранее не работавший с модулем, в рабочее время оформляет стандартную заявку по инструкции из пяти шагов; система отображает следующий необходимый шаг и предотвращает отправку при пропуске обязательного поля; не менее 90 процентов участников выполняют сценарий за 3 минуты без критической ошибки».
Порог, выборка и условия измерения должны быть согласованы с заинтересованными сторонами. Важно уточнить, что считается ошибкой, какой сценарий считается стандартным, какие данные используются и допускается ли обращение к справке.
Нельзя автоматически превращать любое мнение в жёсткий числовой норматив. Измерение должно быть воспроизводимым, но чрезмерно точный показатель без обоснования создаёт ложную объективность и может заставить команду оптимизировать метрику вместо реального пользовательского результата.
В проекте заявили: «Оператор должен быстро находить договор клиента». Рассматривались три варианта уточнения. Оставить слово «быстро» было легко для согласования, но невозможно для приёмки. Задать только время поиска было измеримо, однако не учитывало ошибочный выбор договора. Провести большое исследование пользователей было наиболее надёжно, но не укладывалось в сроки ближайшего релиза.
Выбрали промежуточный вариант: для типового оператора и заранее определённого набора данных зафиксировали время поиска, долю успешных попыток и условия теста. Например, оператор должен найти нужный договор не более чем за 30 секунд в 9 из 10 попыток, не открывая договор другого клиента.
Такой сценарий позволил отдельно проверить скорость и точность. После теста выяснилось, что время укладывается в норму только при знании внутреннего идентификатора, поэтому в требование добавили реальный способ поиска по имени и номеру договора.
1. Достаточно ли измерить время выполнения, чтобы доказать удобство?
Нет. Малое время может быть достигнуто за счёт высокой частоты ошибок, помощи опытного пользователя или выполнения неполного сценария. Нужно определить полный контекст проверки и связанные меры: успешность, количество критических ошибок, необходимость обучения и, если важно, субъективную оценку пользователя.
2. Кто должен устанавливать числовой порог качества?
Порог согласуют заинтересованные стороны на основе бизнес-цели, текущих показателей, пользовательских исследований, нормативных ограничений или технической выполнимости. Аналитик не должен произвольно назначать число, но обязан выявить отсутствие обоснования и предложить способ его получить.
3. Можно ли считать сценарий качества критерием приёмки?
Да, если сценарий содержит однозначные условия, ожидаемый результат и воспроизводимую меру. Однако сценарий качества может быть частью более крупного требования или набора критериев приёмки; он не заменяет описание функционального поведения, если для проверки нужны оба аспекта.