• (PDF) Разработка требований к ПО (Карл Вигерс, 2014)
• Тестирование требований на примерах
• Тестирование требований. Особенности

Тестирование Бизнес-, Пользовательских и Системных требований направлено на то, чтобы уже на начальных этапах проектирования Продукта/Системы устранить максимально возможное количество ошибок.
Это позволяет:

• снизить итоговую стоимость Проекта/доработки;
• повысить скорость в цепи поставки / сэкономить время в Проекте;
• улучшить качество Продукта/Системы;
• сохранить нервы всей команде.

• тест-аналитики
• тестировщики

В любом случае, это должны быть НЕ авторы требований.
Качество проверки документации зависит от квалификации сотрудника, который её проводит. Для этой задачи стоит выделить опытного специалиста.

До старта разработки. Для этого нужно рассчитать необходимое время на проверку и заморозить тестируемую документацию до окончания проверки.
В том случае, когда проверка требований ведется параллельно с разработкой, крайне важно оперативно предупредить Разработчиков и Аналитиков о найденных дефектах, чтобы они могли вовремя исправить ошибку в документации и в коде.

В документе, содержащем Требования, нужно проверить:

1. Что нет опасных и подозрительных путаных опечаток:
   Разработчики/Аналитики иногда дают похожие названия компонентам, методам, сущностям, полям. И в документации начинает возникать путаница: написали одно, а имели в виду другое;
2. Завершённость и полноту требований. Каждое требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям "это и так всем понятно".
1. поискать неучтённые случаи, используя карту состояний или диаграмму переходов;
2. нет видимых логических нестыковок в схемах и диаграммах, описывающих те самые состояния и переходы.
3. Непротиворечивость и последовательность — каждое требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Логика новых/изменённых функций составлена с учётом ранее реализованных и логически связанных с изменениями функций и не портит их.
4. Недвусмысленность — требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз.
5. Обязательность/нужность и актуальность — если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но "не очень важное", для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность.
6. Прослеживаемость/трассируемость — убедиться, что Бизнес- и Пользовательские требования покрыты как минимум одним (не)функциональным в документе Системного уровня;
7. Проранжированность (приоритизированность) по важности и срочности. Важность характеризует зависимость успеха проекта от успеха реализации требования. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования.
8. Проверяемость — подразумевает возможность создания объективного тест-кейса, однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.
9. Если есть интеграция с другими Системами,
   то удостовериться, что схема и формат взаимодействия описание отправляемого/ожидаемого соответствует ожидаемому/отправляемому в документе сопряжённой системы;

Необходимо понимать, что все ошибки в требованиях всё равно не найти, и если удалось обнаружить хотя бы несколько, и их поправили, то это уже хорошо.

• Более качественные требования
• Зарегистрированные дефекты документации