Ответ
Анализ требований (Requirements Review) — это профилактическая деятельность, направленная на выявление дефектов в требованиях до начала разработки. Цель — повысить качество спецификаций и снизить риски дорогостоящих изменений на поздних этапах.
Ключевые дефекты, которые я ищу:
-
Неоднозначность (Ambiguity): Требование допускает multiple интерпретаций.
- Плохо: "Система должна работать быстро."
- Лучше: "95% запросов к поиску товаров должны обрабатываться менее чем за 2 секунды при нагрузке до 100 пользователей одновременно."
-
Неполнота (Incompleteness): Отсутствуют важные детали или сценарии.
- Пример: В требовании к форме оплаты не описана обработка случая, когда платежный шлюз недоступен.
-
Противоречивость (Contradiction): Два требования конфликтуют друг с другом.
- Пример: Требование А: "Все логи должны храниться 30 дней." Требование Б: "Персональные данные пользователей должны удаляться немедленно по запросу." Что делать с логами, содержащими персональные данные?
-
Нетестируемость (Untestability): Невозможно создать объективный критерий проверки.
- Плохо: "Интерфейс должен быть удобным."
- Лучше: "Новый пользователь должен выполнить первую покупку не более чем за 5 кликов с главной страницы."
Методы и техники, которые я применяю:
- Чек-листы с типовыми вопросами (Что? Кто? Когда? Где? Как? Почему?).
- Мозговой штурм тестовых сценариев на основе требований.
- Составление Mind Map для визуализации связей и выявления пропущенных функций.
- Формулировка уточняющих вопросов заказчику или аналитику.
Результат: Список замечаний и вопросов по требованиям, который позволяет уточнить и улучшить спецификацию до начала coding, что экономит время и ресурсы команды.