В других направлениях, например в угольной отрасли, геология имеет свою специфику, отличную от нефтегазовой отрасли. Этот пример показывает, что бывает достаточно трудно прийти к общему пониманию тех задач, особенностей, специфики, которые несет предметная область, для которой и реализуется программный продукт. Очень важно, что при этих встречах должно быть в полной мере выявлено и обсуждено все множество как функциональных, так и нефункциональных требований и ограничений заказчика на программное обеспечение, которое у него появится и будет решать его задачи, желательно в количественном виде. Это производится с помощью нескольких собеседований. В итоге появляется документ, который содержит формализованное описание требований к программному обеспечению в виде списка требований или технического задания. Этот результат имеет принципиальный характер, поскольку на основе требований, с учетом количественных ограничений и осуществляются последующие стадии (проектирования, реализации и т. д.) программного продукта.
Следующая стадия – подготовка проектных спецификаций. Она происходит на основе описания требований, т. е. тех документов, которые получены на предыдущей стадии ЖЦ. Эта и следующие стадии являются в основном прерогативой разработчика. Хотя в ряде методологий проектирования и реализаций программных комплексов, таких гибких, как Agile, X P, Scrum, заказчик участвует на всех этапах ЖЦ ПО. Для больших корпоративных систем, как правило, разработка ведется по методологиям RUP или MSF, и там основным действующим лицом является разработчик. Проектные спецификации содержат описания всей функциональности проекта и всех основных ограничений, желательно выраженных количественно. Здесь уже можно ограничить и программное обеспечение, и технологии, которые будут использованы, и архитектуру (например, сделать выбор между платформами Java или. NET). Необходимо четко ограничить количество одновременных пользователей, количество подключений, транзакций и их интенсивность, пропускную способность канала и ряд других параметров. При этом методологию или модель разработки ПО – каскадную, эволюционную, спиральную или иную – следует выбрать как можно раньше, поскольку выбор методологии или модели ЖЦ определяющим образом сказывается на сроках, стоимости и успехах проекта. Проектные спецификации должны ограничивать сроки и стоимость проекта исходя из договоренностей, которые достигли разработчик и заказчик на предыдущем этапе.
Далее на основе проектных спецификаций производится детальное проектирование, которое описывает программную архитектуру с учетом всех компонентов проекта. В случае объектно-ориентированного подхода это модули и интерфейсы между ними, компоненты и средства их взаимодействия в условиях той программной среды, которой располагает заказчик. Однако в больших корпоративных системах всегда присутствует некоторое количество взаимодействующих систем, которые уже работают у заказчика, и, как правило, разработчики приходят к заказчику с предложениями, которые учитывают эти условия программной и аппаратной среды. У заказчика может быть множество серверов, например серверы баз данных, кэш-серверы, серверы безопасности, серверы, отвечающие за телекоммуникации, и пр. Детальное проектирование также выполняется разработчиком. Кроме написания программной архитектуры, детальное проектирование на выходе дает документы, которые описывают все программные модули корпоративного комплекса.