Находить двусмысленные и непроверяемые формулировки («быстро», «удобно», «и т.п.») и переписывать их в однозначные, измеримые требования.
Слова-ловушки и как с ними бороться
Слова-ловушки и как с ними бороться
Двусмысленность — самый распространённый дефект требований. Аналитик, читая требование, должен задать себе вопрос: «Как именно я проверю, что это выполнено?». Если ответа нет — требование плохое.
Слова-ловушки — это выражения, которые кажутся понятными, но не дают критерия проверки. Классический список: «быстро», «удобно», «гибко», «надёжно», «при необходимости», «и т.п.», «в разумные сроки», «большой объём», «достаточная производительность», «интуитивно понятный». Каждое из них скрывает вопрос: «по сравнению с чем?» или «как именно измерить?».
Скрытые предположения — ещё один тип дефекта: требование выглядит полным, но опирается на знание, которое не зафиксировано явно. Например, «система сохраняет данные» — куда? когда? что именно считается «данными»? Аналогичная проблема — незакрытые списки: «поддержка браузеров Chrome, Firefox и других» — каких именно других?
Приём устранения двусмысленности прост: к каждому требованию задайте вопрос «как это проверить?» и зафиксируйте измеримый критерий. «Быстро» → «страница загружается не дольше 2 секунд при 500 одновременных пользователях». «Удобно» → «не менее 90% пользователей в ходе юзабилити-тестирования выполняют задачу без обращения к справке». Конкретное число или условие — это и есть критерий проверки требования.
Слово-ловушка → вопрос → измеримый критерий
| Ловушка | Спросите | Измеримо |
|---|---|---|
| «быстро» | За сколько и при какой нагрузке? | ответ ≤ 1 с при 300 пользователях |
| «удобно» | Кто, что делает и за сколько шагов? | покупатель оформляет заказ не более чем за 4 шага |
| «и т. п.» | Что именно ещё? | оплата: банковская карта и СБП |
| «большой объём» | Сколько именно? | отчёт до 50 000 строк |
| «при необходимости» | Кто решает и когда? | по кнопке администратора |
Конспект урока
Слова-ловушки и как с ними бороться
Двусмысленность — самый распространённый дефект требований. Аналитик, читая требование, должен задать себе вопрос: «Как именно я проверю, что это выполнено?». Если ответа нет — требование плохое.
Слова-ловушки — это выражения, которые кажутся понятными, но не дают критерия проверки. Классический список: «быстро», «удобно», «гибко», «надёжно», «при необходимости», «и т.п.», «в разумные сроки», «большой объём», «достаточная производительность», «интуитивно понятный». Каждое из них скрывает вопрос: «по сравнению с чем?» или «как именно измерить?».
Скрытые предположения — ещё один тип дефекта: требование выглядит полным, но опирается на знание, которое не зафиксировано явно. Например, «система сохраняет данные» — куда? когда? что именно считается «данными»? Аналогичная проблема — незакрытые списки: «поддержка браузеров Chrome, Firefox и других» — каких именно других?
Приём устранения двусмысленности прост: к каждому требованию задайте вопрос «как это проверить?» и зафиксируйте измеримый критерий. «Быстро» → «страница загружается не дольше 2 секунд при 500 одновременных пользователях». «Удобно» → «не менее 90% пользователей в ходе юзабилити-тестирования выполняют задачу без обращения к справке». Конкретное число или условие — это и есть критерий проверки требования.