📊
Разбираемся, как формулировать задачи так, чтобы разработчики вас поняли, а тестировщики — проверили 💡
Каждый аналитик знает: плохо написанное требование — это как закладка с сюрпризом, которая взрывается на этапе тестирования или, что ещё хуже, в продакшене. Чтобы этого избежать, требования должны быть качественными. Но как это проверить? Есть чёткие критерии, на которые можно ориентироваться. Давайте разберём их с примерами и эмодзи 😉
1️⃣ Понятность (Clear) 🧐
Требование должно быть написано языком, понятным и заказчику, и разработчику, и тестировщику. Никаких сложных терминов без объяснений, никаких абстракций.
❌ Плохо: «Система должна быть удобной».
✅ Хорошо: «После ввода некорректного пароля поле ввода подсвечивается красным, а под ним появляется сообщение: "Неверный пароль. Осталось 2 попытки"».
2️⃣ Полнота (Complete) 📋
Требование описывает всю необходимую информацию: предварительные условия, входные данные, ожидаемый результат, исключительные ситуации.
❌ Плохо: «При нажатии на кнопку "Отправить" данные сохраняются».
✅ Хорошо: «Если все обязательные поля заполнены, при нажатии на кнопку "Отправить" данные записываются в БД, а пользователь видит сообщение "Сохранено". Если хотя бы одно обязательное поле пустое — кнопка неактивна, рядом с пустыми полями появляется подсказка "Обязательное поле"».
3️⃣ Однозначность (Unambiguous) 🎯
Требование нельзя истолковать двояко. У него есть только одно толкование.
❌ Плохо: «Цвет кнопки должен быть светлым».
✅ Хорошо: «Цвет фона кнопки — #F0F0F0 (светло-серый), цвет текста — #000000 (чёрный)».
4️⃣ Проверяемость (Testable) ✅
К требованию можно написать тест-кейс и однозначно сказать, выполнено оно или нет.
❌ Плохо: «Интерфейс должен быть интуитивно понятным».
✅ Хорошо: «75% новых пользователей должны найти функцию "Сброс пароля" за 30 секунд без подсказок».
5️⃣ Непротиворечивость (Consistent) 🔗
Требование не конфликтует с другими требованиями в рамках системы.
❌ Плохо: В одном месте сказано «пароль должен содержать не менее 8 символов», а в другом — «максимальная длина пароля 6 символов».
✅ Хорошо: Все требования к паролю собраны в одном разделе и согласованы между собой.
6️⃣ Атомарность (Atomic) ✂️
Требование описывает ровно одну функцию или характеристику. Не надо смешивать несколько идей в одном пункте.
❌ Плохо: «Пользователь может зарегистрироваться и восстановить пароль через email».
✅ Хорошо:
- 1.1. Система позволяет зарегистрироваться по email.
- 1.2. Система позволяет восстановить пароль через email.
7️⃣ Необходимость (Necessary) 💡
Требование действительно нужно для решения бизнес-задачи, а не добавлено «на всякий случай».
❌ Плохо: «Добавить анимацию переворачивающейся карточки на странице контактов» (без обоснования).
✅ Хорошо: «Добавить анимацию переворачивающейся карточки, чтобы привлечь внимание к контактам отдела продаж — это увеличит конверсию в звонки на 5%».
8️⃣ Реализуемость (Feasible) 🛠️
Требование технически выполнимо в рамках текущих ограничений (бюджет, сроки, технологии).
❌ Плохо: «Система должна распознавать лица с точностью 99,9%» при том, что у вас нет ни данных, ни GPU.
✅ Хорошо: «Система должна распознавать лица с точностью 95% на основе готового облачного сервиса X».
9️⃣ Приоритетность (Prioritized) ⚖️
У требования есть понятный приоритет, чтобы команда знала, что делать в первую очередь.
❌ Плохо: Список требований без указания важности.
✅ Хорошо: Каждое требование помечено меткой: Must have, Should have, Could have, Won't have (MoSCoW).
Как применять эти критерии? 🤔
Просто пройдитесь по списку каждый раз, когда пишете новое требование. Задайте себе вопросы:
- Поймёт ли его новичок в проекте?
- Можно ли написать тест?
- Не противоречит ли оно другим?
- Действительно ли оно нужно?
Если на все ответы «да» — вы золото, а не аналитик 🏆
Вместо заключения
Качественные требования экономят часы обсуждений, спасают нервы разработчиков и делают релизы стабильными. А ещё они очень нравятся тестировщикам — они готовы носить такого аналитика на руках 🤗
Пишите требования осознанно, и пусть ваши спринты будут чистыми и предсказуемыми 🚀
А какие критерии используете вы? Делитесь в комментариях! 👇
Подписывайся https://t.me/analist_analist_analist