Проверка и утверждение требований

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

Проверка и утверждение требований является по существу контролирующим процессом разработки требований. Именно в рамках данного процесса принимаются решения о приемлемости требований и завершении всего процесса разработки базовой спецификации требований.

На каждой итерации разработки требований в рамках данного процесса осуществляется просмотр всех изменений и дополнений текущей версии спецификации требований для проверки их соответствия критериям качества и выявления имеющихся проблем.

При обнаружении проблем формулируется соответствующий запрос на устранение недостатков. Если же просмотр не выявляет каких-либо проблем, то проводится экспертиза и тестирование требований.

По выполнении критериев завершения выявления требований, а также завершении экспертизы и тестирования имеющихся требований, осуществляется утверждение базовой версии спецификации требований.

Рис. 7‑1. Модель проверки и утверждения требований

Особенностью предложенной модели является тестирование требований. Любые усилия, затраченные на выявление ошибок в спецификации к требованиям, сэкономят реальные время и деньги. Зачастую тестирование рассматривается как одна из последних стадий проекта. Проблемы, связанные с требованиями, могут оставаться в продукте до тех пор, пока они не будут выявлены в ходе долгого тестирования системы или их не обнаружит клиент. Если же начать планирование тестирования и разработку вариантов тестирования на ранней стадии проекта, можно обнаружить многие ошибки сразу вскоре после их появления. При этом удается не только предотвратить дополнительный ущерб, наносимый ими, но и снизить затраты на тестирование и обслуживание.

Хотя в процессе разработки требований проведение классических программных тестов невозможно, так как никакого программного обеспечения еще нет, однако создание концептуальных (то есть, не зависящих от реализации) вариантов тестирования вполне реализуемо. При этом концептуальные варианты тестирования, созданные на основе требований, позволят выявить ошибки, неясности и пропуски данных в спецификации требований к программному обеспечению и проанализировать модели задолго до того, как разработчики приступят к написанию кода.

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

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