|
ЯЗЫК ДОКУМЕНТИРОВАНИЯ ТРЕБОВАНИИ |
Язык, на котором формулируются требования, должен быть понятен пользователю. Пользователь должен участвовать в развитии формулировки требований. Эта формулировка должна стать элементом словаря технического проектирования. Она связана скорее с документами проектирования, а не с документами на требования. Особая важность требований Тот факт, что наша работа над программами начинается с установления требований, сильно отражается на всем дальнейшем ходе работ. Если этот процесс выполнен недостаточно аккуратно, недостаточно точно, недостаточно адекватно, то от этого пострадают все остальные части процесса разработки. Последующие усилия могут быть просто героическими, но нужная система уже не будет создана. Персонал, работающий с созданной системой, будет трактовать ошибки, искажения и неоднозначности как правильные требования, понапрасну тратя усилия не только на то, чтобы их внедрить, но и на то, чтобы затем от них избавиться. Плохие требования подобны кривым зеркалам — они все искажают. В августе 1977 г. министерство обороны США провело изучение основных автоматизированных систем. Большинство из них были системами связи. Это были системы: 1) TRI— ТАС; 2) LDMX/NAVCOMPARS и AMMC/SRT; 3) SATIN IV; 4) WMMCCS NORAD/COC; 5) WWMCCS ADP — LANTCOM; 6) Телекоммуникационный центр Пентагона; 7) WWMCCS ADP — ССТС; 8) Автоматизированный технологический контроль; 9) CUDIX/NAVMASC. Изучение показало: • Во всех системах требования были неустойчивыми и подвергались пересмотру; чем больше была система, тем большие изменения вносились в них. • В большинстве систем отсутствовал формальный механизм отслеживания и управления процессом выработки требований. • Некоторые разработчики даже не смогли осознать необходимость обоснования требований. • В большинстве систем не было отбоя от «списков пожеланий». Результаты исследования в точности соответствуют моему личному опыту деятельности в коммерческой сфере, охватывающей вычислительную технику.
|