3.5 Как тестировать требования
Рецензирование
Беглый просмотр
Первый человек создает артефакт требований. Второй быстро просматривает документ и отмечает места, где у него появились вопросы. Первый сам исправляет документ с учетом замечаний.
Можно делать одному. Для этого документ нужно отложить на 3 дня.
Техническое ревью
Ревью группой специалистов. В конце документа всегда есть несколько подписей от разных специалистов.
Формальная инспекция
Очень тщательное исследование или переработка требований.
- Если требования плохие, то их нужно переработать.
- Если требования хорошие, то их нужно подтверждение что с требованиями все хорошо.
Задавание вопросов
Если хоть что-то не понятно, нужно задавать вопросы.
| Плохие требования | Плохие вопросы | Хорошие вопросы |
|---|---|---|
| "Приложение должно запускаться быстро" | Какое максимальное время запуска и на каком оборудовании? На какой операционной системе? На сколько система нагружена другими приложениями? Почему время запуска на столько важно? Что от этого зависит? Могут ли некоторые компоненты системы запускаться в фоне? По каким критериям мы определяем, что приложение запустилось? |
Написание чек-листов
Нужно задать себе вопрос: "Как я собираюсь проверять эти требования?", "Могу ли я составить тесты, которые проверят именно это требование?"
Если приходит много идей, то это хорошо.
Если не возникают идеи, то это плохо. Значит нам не понятны требования. Значит нужно задавать вопросы. Эти вопросы приведут к улучшению требований.
Визуализация
Можно рисовать схемы, диаграммы, карты... любые рисунки. Можно применять инструменты типа UML.