Определение стратегии проверки

из "Разработка и управление требованиями "

Необходимо всегда учитывать стоимость конкретно разрабатываемой стратегии проверки. [c.127]
Организация всесторонних интенсивных испытаний всегда очень дорогое удовольствие, поэтому к выбору типа испытаний нужно подходить очень аккуратно и здесь лучше все-таки следовать принципу последовательности , так, например, прежде чем приступать к испытаниям корабля в открытом, да еще и в штормовом море, лучше вначале посмотреть на его поведение в спокойной бухте. [c.127]
Практический вывод, вытекающий из формирования стратегии, следующий. Если требование нельзя проверить тем или иным путем, то это требование не может называться требованием. Правильно разработанное требование это такое требование, которое легко понять и выполнение которого может быть легко продемонстрировано. [c.127]
Пользовательские требования следует разрабатывать как можно раньше, потому что именно они определяют возможности, необходимые заинтересованным сторонам, при этом выраженные удобным и понятным для них языком. [c.128]
Таким образом, необходимо сосредоточивать усилия именно на проблемной области, а не на области решений. [c.128]
Пользовательские требования должны быть хорошо структурированы и (там, где возможно) должны быть увязаны с первоисточником информации, из которого они были получены. Необходимо четко определить границы ответственности сторон при разработке пользовательских требований. Заинтересованные стороны должны нести ответственность за содержание требований. Требования должны быть ограничены рамками бюджета, соблюдение которого должно контролироваться финансистами. За сбор и оформление требований должны отвечать обученные специалисты-аналитики. [c.128]

Вернуться к основной статье