Затраты труда при реализации функций разработки отдельного программного изделия, согласно кривой Релея, имеют максимальное значение в фазах проектирования и программирования. Осуществление функций разработки начинается в фазе исследований с того момента, когда будет признана необходимость создания конкретного программного изделия. В этом случае план — это план завоевания рынков сбыта, план выпуска серии программных изделий и бюджет. Основной параметр этих планов — срок, к которому возникает необходимость в данном программном изделии. Первая задача, выполняемая в рамках разработки, состоит в том, чтобы определить, когда следует начать разработку изделия, чтобы обеспечить его готовность к моменту, когда в нем возникнет необходимость. Функция разработки предусматривает согласование момента начала проектирования с возможностью выполнения других функций, чтобы гарантировать их совместное обеспечение в процессе проектирования. В рамках функции разработки фиксируются предлагаемые сроки начала и завершения всех видов работ, среди которых выделяют основные этапы проектирования, и запрашиваются ресурсы, необходимые для анализа осуществимости проекта, — кадры, машинное время, командировки, фонды для проведения консультаций. Это достигается путем составления сметы затрат, в которой обязательно указывается, кто несет ответственность за выполнение проекта в каждой функциональной группе, здесь же предлагается кандидатура руководителя проекта в целом. Руководитель проекта (администратор) дает указание выполнить анализ результатов работ, выполненных в фазе I (фазовый обзор), и ходатайствует о соответствующем финансировании. Обычно администратор ограничивается выделением средств на работы, связанные с составлением соглашения о требованиях. Такая мера ограничит трату ресурсов, в которых нет необходимости во время фазы анализа осуществимости.
Для правильного принятия решения на основе результатов фазы I оценивается не только стоимость, но и календарные сроки проектирования. Поэтому один из участников проекта, ответственный за подготовку соглашения о требованиях, представляет формально законченный план — график работ. Этот первоначальный вариант плана должен обязательно фиксировать точный срок представления соглашения о требованиях и предполагаемый срок окончания разработки программного изделия.
Если на основании фазового обзора I руководство разрешает начать анализ осуществимости, выделяя для этого соответствующие ресурсы, то предпринимается попытка составить соглашение о требованиях. Формальное составление соглашения о требованиях облегчается, если придерживаться строго формализованной формы. Требования должны быть выражены в ясной форме и не допускать противоречивых толкований. В соглашениях о требованиях следует избегать пунктов, объясняющих, как надо решать поставленную задачу. Рассматривая соглашения о требованиях, функциональные группы обычно накладывают жесткие ограничения на эксплуатационные качества и другие характеристики программного изделия. Для обоснования этих ограничений (принять или нет) обязательно должен быть проведен достаточно глубокий анализ осуществимости.
Соглашение о требованиях — это договор между руководителем проекта и заказчиком, который также включает субподряды, заключенные между группой разработки и другими функциональными группами. Договорный характер соглашения о требованиях подчеркивается тем, что привязываются индивидуальные рабочие планы к конкретным положениям данного документа. И так как соглашение о требованиях связывает воедино усилия многих подразделений, его необходимо согласовывать на всех уровнях (вплоть до конкретного исполнителя).
На базе соглашения о требованиях составляется общий план для всего проекта. В нем указываются взаимодействия между функциональными группами и вклад каждой из них в проект, а также очерчиваются границы обязанностей каждой группы. В этом плане также дается основа описания всех задач, решаемых группой разработки. Обычно этот план составляется в виде сетевого графика.