Дальнейшая характеристика требований

Итерационный цикл разработки требований и проектирования

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

Имеющиеся требования приводят к выбору определенных

вариантов проектирования,

те в свою очередь могут инициировать новые требования.

Иногда появление новой технологии может привести к тому, что мы отбросим множество предположений о том. какими должны быть требования; мы можем найти совершенно иной подход, перечеркивающий старую стратегию. ("Давайте целиком уберем модуль клиент/доступ к данным/GUI и заменим его навигационным интерфейсом.") Это важный и правомерный источник изменения требований.

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

Итак, существуют различные "разновидности" требований. В частности, мы считаем полезным выделить следующие три типа (рис. 23.3).

• Функциональные требования к программному обеспечению

• Нефункциональные требования к программному обеспечению

• Ограничения проектирования