✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
✅ Однозначность. Требования должны трактоваться всеми одинаково.
✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.
✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить
✅ Атомарность. Не может быть разбито на ряд более детальных требований
Подробнее – см. свойства качественных требований
#требования