Создание Web-узла с помощью PHP не совсем аналогично созданию статического Web-узла. Конечно, если вы выбрали метод вставки PHP-кода, различия будут минимальными. Но если было принято решение использовать PHP для создания каждой страницы, у разработчика появляется возможность преобразовать многие шаблоны в функции. Как было сказано в главе 26, "Интегрирование в HTML-код", такие элементы, как открывающие и закрывающие тело теги, могут быть выделены в отдельную функцию или включаемый файл, но полученный результат уже нельзя в полной мере назвать Web-узлом. Это уже будет Web-приложение.
Когда такое происходит, очень легко можно выйти за рамки обычных методов разработки. Безусловно, структурированное проектирование имеет смысл даже при создании статических Web-узлов. Этот случай хорошо описан в книге Томаса Пауэлла (Thomas Powell) Web Site Engineering. Добавление PHP приводит к необходимости тщательного проектирования. PHP-приложения не могут использоваться при разработке крупных проектов, в которых задействованы тысячи программистов, но при разработке небольших проектов может очень пригодиться применение передовых идей программирования, заложенных в последней версии языка PHP. У меня нет возможности углубиться во все аспекты теории программирования применительно к проектированию Web-приложений, но в качестве отличного первоначального учебного материала можно порекомендовать вышеназванную книгу Пауэлла. Можно еще порекомендовать книгу Пита Макбрина (Pete McBreen) Software Craftsmanship. Его идеи очень хорошо вписываются в опыт разработки Web-приложений на основе PHP.
После рассмотрения основных требований к программному обеспечению и проектам мы перейдем к конкретным вопросам разработки и выполнения проектов. 
27.1. Разработка спецификаций требований
Прежде чем проектировать систему, необходимо уяснить, что требуется сделать. Зачастую это делается в форме вербального запроса наподобие "Нам нужна домашняя страница с гостевой книгой и счетчиком посетителей". Такая постановка задачи обычно приводит к созданию прототипа, который приблизительно на 25% соответствует тому, что нужно клиенту. Потом в прототип вносятся изменения, и теперь это уже 50% того, что требуется клиенту. Во время внесения изменения пожелания клиента могут измениться.
Решением этой задачи является определение цели и постоянное следование ей. Начать можно с формулировки целей проекта. Мой опыт показывает, что наиболее важный вопрос, который остается незаданным, это вопрос мотивации. Если клиент хочет, чтобы на его индексной странице появилась большая динамическая картинка, мотивация может лежать в ознакомлении с передовыми технологиями. Вместо того чтобы безоговорочно выполнить заказ клиента, лучше всего задаться вопросом "Зачем?'. Изящный графический дизайн может рассказать многое о приверженности клиента к последним достижениям в информационных технологиях.
Ну а если вы задали вопрос "Зачем?" несколько раз, у вас должен быть в распоряжении уже целый перечень целей проекта. Эти цели предполагают набор требований. Если одна из целей систем является продвижение бизнеса, одним из требований, выдвигаемых перед системой, может быть рост заинтересованности посетителя в товарах, имеющихся в каталоге. Отсюда может возникнуть требование, что товары в каталоге должны обновляться. Это может быть реализовано в виде стратегически размещенных на Web-узле баннеров. Однако не следует жестко ограничивать себя проблемами проектирования. Начальная стадия разработки Web-узла должна целиком фокусироваться на целях системы.
Опираясь на цели, можно приступить к описанию требований, предъявляемых к системе. Обычно они принимают вид документа спецификаций, формального описания поведения черного ящика, которое ожидается от Web-узла. Цели имеют вид набора функциональных требований и ограничений, накладываемых на проект. Как было сказано ранее, цель заключается в повышении продаж, среди других задач Web-узла можно назвать повышение информированности покупателя о товарах, содержащихся в каталоге. Другое требование должно заключаться в том, что Web-узел должен обеспечивать бесплатные услуги для привлечения посетителей. Примером может служить кредитное общество, предлагающее услугу калькуляции залога. Неплохим решением является неформальный перевод возможных решений в требования, но по-прежнему важно при этом не принимать никаких проектных решений.
Спецификация требований должна быть формальной и структурированной, но она должна быть понятной для тех, кто не является экспертом в технологиях разработки. Описание поведения системы должно входить в контракт, который подписывают клиент и разработчик. Четкие определения должны уменьшить количество недоразумений, которые будет уже трудно исправить в процессе разработки. Но это не значит, что документ не должен быть точным. По мере возможности необходимо определять требования в измеримых терминах. Ограничение размера страницы 30 Кбайт является объективным стандартом, который очень легко проверить. Выдвижение такого требования к Web-узлу как внушение уверенности компании-заказчику не так легко измеримо, но зачастую это все, что имеется в вашем распоряжении.