Двусмысленность является наиболее критичным фактором риска проекта, закладываемого в фазе формирования требований.
Требование, сформулированное двусмысленным образом, может привести к различным его интерпретациям представителями Разработчика и Заказчика. Разработчик, руководствуясь своей интерпретацией, определит на ее основе архитектурную основу, создаст аналитические и проектные модели и в конечном итоге создаст программный код.
Если не заложить средства на проверку требований на предмет двусмысленности в момент их формирования - существует риск непринятия готовой системы в момент приемо-сдаточных испытаний, т.к. каждая из сторон будет придерживаться своей версией интерпретации требований, что ведет к убыткам, судебным процессам и т.п.
2.2) "Золочение" продукта
Под "золочением" понимают такие ситуации, когда разработчики добавляют функции, которых нет в спецификации, но им кажется, что это понравится пользователям.
Зачастую же клиентам не нужны такие избыточные возможности, получается, что время, отведенное на реализацию, тратится впустую.
Эта ситуация возникает в случае, когда
-в коллективе Разработчика присутствуют творческие личности (ведь далеко не всякая команда станет проявлять инициативу и делать сверх того, о чем ее просили);
-существует разрыв в прохождении информации от Заказчика к Разработчику.
Инициативный разработчик "золотит" продукт из самых лучших побуждений, но, возможно, он плохо знаком с бизнес-процессом Заказчика и заложенные им возможности попросту не будут востребованы.
Другая сторона "золочения" заключается в том, что группа представителей Заказчика неоднородна по своей структуре и может возникнуть ситуация, когда представитель Заказчика, формулирующий "дорогие" требования, не обладает соответствующими полномочиями.