Принципы и приемы оперирования требованиями (продолжение)

Организация работ по управлению требованиями

Управление требованиями и приемы этой работы, представленные выше, являются главными условиями успешного развития большинства сложных проектов, поскольку именно это обеспечивает возможность построения системы, реально удовлетворяющей потребности пользователей с учетом внешних обстоятельств разработки (надежность заказчика, рыночная конъюнктура и др.). Однако большинство рекомендаций, которые можно дать для организации этих работ, принадлежат конкретным методологиям. Наиболее регламентированно подходят к вопросу монументальные методологии, ставящие критерии отслеживания процесса развития проекта на первое место [18]. Противоположная позиция у методологии экстремального программирования, провозгласившей "путешествие налегке" (все, что не относится к решению задач проекта в их текущем видении, не требуется учитывать, а тем более специально разрабатывать), сотрудничество с заказчиком как с членом команды (он отвечает за актуальность решаемых при производстве релизов задач), а также ряд специальных методик, делающих классический анализ требований избыточным [3].

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

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