Живые требования – тот еще фрукт. Актуализируем и реализуем, пока не испортились

Сначала полностью завершается этап «определение требований», в результате чего получается список требований.

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

Задумаемся, какие ограничения устанавливаются для требований в момент завершения фазы определения требований по каскадной методологии? Ответ достаточно очевиден – в этот момент требования фиксируются и далее являются неизменными.

Что означает «неизменными» с точки зрения проекта? Как минимум, следующее:

– содержание требования, как его понимают все участники проекта, более не меняется;

– связи требования с другими требованиями прояснены и не изменяются значимым для понимания других требований образом;

– не возникает новых требований;

– существующие требования не удаляются из рассмотрения.

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

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

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

Допущения простой модели требования довольно быстро ограничили область применения «чистой» «водопадной» методологии, потому что в реальности требования далеко не всегда столь стабильны, как допускается для этой методологии.

Это порождает серьезные риски в проектах, которые достаточно часто недооценивают.

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

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