Современная индустрия посылок — это больше, чем просто доставка из точки А в точку Б. За кажущейся простотой скрывается масштабная логистическая система, в которую вовлечены миллионы отправлений ежедневно. С ростом электронной коммерции и популярности онлайн-шопинга, доставка становится неотъемлемой частью жизни потребителей и важным элементом бизнеса.

Главные требования к посылке сегодня — это скорость, безопасность и экологичность. Компании инвестируют в автоматизированные сортировочные центры, беспилотные технологии и ИИ-системы, чтобы сократить время доставки и снизить человеческий фактор. Пункты выдачи заказов, постаматы и курьерские службы работают круглосуточно, создавая привычку получать заказы «на следующий день» или даже в течение нескольких часов. Читать далее »

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

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

Что такое чрезмерное избегание неприятностей

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

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

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

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

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

Если Ваш сайт не приносит желаемых результатов, а просто «висит» в интернете, то пора выяснить что же не так с Вашим сайтом.

Если же Ваш сайт прекрасно выполняет свои функции, отлично продает, то будьте уверены, что Ваш сайт может намного больше!

В обоих случаях Вам необходим профессиональный аудит сайта.

Специалисты компании ELAB MEDIA с удовольствием проведут аудит Вашего сайта и выявят его слабые стороны, препятствующие достижению целей Вашего бизнеса в интернете.

Мы рады сообщить, что сегодня стартовала акция компании ELAB MEDIA «Бесплатный аудит сайта».

Акция проводится при поддержке компании 1С-Битрикс в период до 14 февраля.

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

Принимаются заявки только от коммерческих сайтов на платформе 1С-Битрикс.

Подробнее с правилами акции можно ознакомиться на сайте акции http://elabmedia.by, а также на официальном сайте компании ELAB MEDIA (www.elab.by)

Спешите, потому что количество заявок, которые будут удовлетворены, ограничено!

http://elabmedia.by

После прочтения бессмертного произведения об утопии все мы начинаем понимать что живем в неидеальном мире!

Зачастую работая с отечественными заказчиками мы сталкиваемся с одной и той же ситуацией, которая так или иначе касалась любого исполнителя:

— Здравствуйте, мы хотим сайт как http://www.xxxxx.web (показывают мега-портал с неизвестным функционалом). Сколько будет стоить ?

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

Почему мы повторяем одну и ту же ошибку, и как научиться правильно определять цену подобного проекта? Ответ на вопрос вроде бы очевиден — глубже изучить сайт, оценить объем предстоящей работы, добавить риски, затраты на кофе и валерьянку, и назвать заказчику сумму. Но, опять же, возникает дилема — назвать большую сумму = потерять заказчика и отдать проект конкурентам (они назовут меньше сумму), студентам (они пообещают сделать за еду). Или же слукавить, занизив сумму, а потом выбивать дополнительные деньги, аргументируя «подводными камнями» и шантажируя отказом от проекта… В любом случае мы применяем подход Fixed Price (Фиксированная цена за продукт под ключ), что не является правильным при данной задаче.

На Западе очень распространен подход Time&Material (Время и материалы), причем он широко распространен не только в области разработки но и в других отраслях, где требуются значительные средства и усилия архитектора, менеджера проекта, маркетолога. Нашему заказчику пока такой подход ассоциируется с игрой в наперстки на вокзале — т.е. ему может казаться, что в итоге все, кроме него, останутся в выигрыше. Читать далее »

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

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

Вводная

Зачем составлять техническое задание (ТЗ) на сайт?
Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: «А когда мы будем заканчивать работу, то как мы поймем, что мы ее действительно закончили?» В разработке как ПО, так и любого сайта частая проблема — никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадет с образом менеджера, но не совпадет с ожиданиями клиента? А если за время проекта меняется 3 менеджера?

Следствие закона Паркинсона «девяносто-девяносто»:
Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.

ТЗ это не просто список требований, это документ. Если договор регулирует процесс организационных и финансовых взаимоотношений, то ТЗ регулирует процесс разработки и конечный результат.

В этом случае не имеет никакого значения большой разрабатывается сайт или малый. Проблема рассогласования ожиданий может возникнуть в независимости от объема затраченных средств, вот только последствия могут быть разными.

О чем эта статья.

Эта статья о том, что может пригодиться в процессе написания ТЗ на сайт, а также что будет уж точно сделать желательно. Но эта статья не о том, как надо писать проектную документацию. В конечном итоге главная задача проектировщика не написать классный документ, а спроектировать сайт. Хороший документ лишь отражение подхода и уважения ко всем участникам разработки.

Добавлю ограничения.

Всегда когда я говорю о написании ТЗ, то имею в виду, конечно же, каскадную методику разработки. В случае других вариантов (например, экстремальное программирование) составляются другие документы и часто по другим принципам. Это — раз.

Стоит разделять ТЗ для малых и больших сайтов. Это — два. Различия маленьких и больших проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас всего 4 человека в проектной группе, все давно знают друг друга, то можно предполагать отсутствие формализма. Если же разработкой занимаются несколько «отделов», а проектная команда состоит из более 10-ка (до бесконечности) сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.

По сути, толщина документов зависит от сложности процесса в больше степени, нежели от размеров проекта.

Мы будем следовать самому сложному пути.

ТЗ отвечает на вопросы

ТЗ изначально создается для нескольких участников разработки:

1. Разработчики проекта (дизайнеры и программисты).
2. Проект-менеджер.
3. Клиент.
4. Бюрократы (они могут не участвовать в проекте, но на них тоже надо рассчитывать).

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

Для кого создается сайт и для чего?

Сайт создается для Заказчика и для его клиентов. Это основанные пользователи будущего проекта.
Наилучшим вариантом будет, если в Техническом задании вы опишите всех пользователей сайта, как внутренних, так и внешних. Это описание может включать в себя маркетинговые, демографические, социальные данные, цели и задачи потенциальных пользователей, их требования к будущему сайту.

Как будут решены задачи заказчика и пользователей?

Собственно если не ответить на этот вопрос, то написание ТЗ можно признать бумагомарательством. Это основной и значимый вопрос. Ему может быть посвящена отдельная статья, поэтому останавливаться на нем подробном пока не будем.

Как будет проходить создание проекта?

Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во внимание, что сайт может разрабатываться по отличной от принятой в компании методики разработки, которая как правило не описывается ни одним документом. Можно сколько угодно долго мучить себя мечтами о стандартизации по ISO, но что показать дотошному заказчику?
По ГОСТу предусмотрен отдельный раздел «Этапы разработки системы». В таком разделе можно не слишком подробно описать процесс и установить майлстоуны.

Что будет приниматься на выходе?

ТЗ начинает разработку и ставит в ней точку.
В идеале вы должны пройтись по всем пунктам ТЗ вместе с заказчиком, свериться с полученной системой и спустя неделю сказать: «Уф-ф. Вроде все сделали».
«ТЗ является средством верификации выполненных работ.» — такая фраза записана во введении многих моих ТЗ.

Что требуется для дальнейшего запуска проекта?

Это вопрос, на который по-хорошему должен получить ответ заказчик. Это уже консалтинг, но в части случаев его необходимо провести в процессе проектирования. Необходимо спланировать количество рабочих мест, требуемое программное и аппаратное обеспечение и т.п.

Из чего состоит ТЗ

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

Общая информация

Первая часть ТЗ содержит введение и общую информацию о документе и проекте в целом. Введение надо написать один раз и на всю жизнь. Как правило, там пишутся настолько абстрактные фразы, что в каждом новом проекте надо лишь подправить пару слов.

Общая информация включает в себя:

• Информацию о заказчике и исполнителе.
  Обязательно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых производится разработка. Как правило, подобным документом является договор. Статус текущего документа и конфиденциальность.
• Назначение проекта.
  Указывается: для чего будет использоваться полученный продукт.
• Цели создания и задачи, которые должен решить ресурс.
  С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены нечетко и неизмеримо, то может быть довольно сложно им следовать.
• Описание аудитории проекта.
  Критично важная информация для разработки хороших и правильных сайтов. Ясно, что информацию об аудитории не только надо правильно собирать, но еще важнее это уметь этой информацией пользоваться.
  Описание аудитории должно содержать не только информацию, которую так любят маркетологи (демография, потребности, сегментирование и т.п.), но также информация, которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь, какие его цели в работе с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию сайта не в виде безликой массы, а выделять персонажи — описывать собирательный образ конкретных людей.
• Термины и определения.
  В большом документе вы сможете употребить огромное количество терминов и сленговых выражений, которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для них список определений. Я не тешу себя надеждой, что этот список хоть раз в жизни был прочтен, но зато я могу всегда сослаться на него.

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

Эта информация собирается в рамки проекта.

Рамки проекта

Если подальше отойти от своего дома и, обернувшись, взглянуть на него, то издали вы не сможете различить детали строения. Вы можете подсчитать окна, но не разберете из какого они материала, вы можете любоваться архитектурой («любоваться», конечно, можно не каждым домом), но сможете только догадываться о принципах его строительства, вам не будут видны внутренности квартир или нацарапанное слово на входной двери.

Рамки проекта примерно то же самое. Прочитав эту главу каждый должен представлять, что будет получено в процессе разработки, но абсолютно не вдаваясь в детали. Вы пишите, что на сайте будет работать «регистрация пользователей», но не пишите, как конкретно она будет устроена, или какие поля должен будет заполнить пользователь.

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

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

Информационная архитектура и интерфейс

Раздел посвященный информационной архитектуре (ИА) сайтов не стандартизируется ни одним известным стандартом (автору такие пока не знакомы). Но любой, кто разрабатывал сайты, понимает, что ИА это чуть ли не главное, что нужно знать для разработки сайта. ИА определят как будет выглядеть и работать сайт с пользователями.

Для описания ИА потребуется описывать сверху вниз:

1. Структуру сайта. Это так называемые высокоуровневые прототипы.
2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
3. Опись контента. Табличное описание содержания каждой страницы сайта.

Структура сайта

Карта сайта выполняется графическим способом в одной из известных нотаций: Visio или Garrett. Я советую именно рисовать карту сайта, потому как в этом случае полученная структура получается наиболее наглядной и удобной в дальнейшем использовании. С одной стороны может показаться, что в виде списка написать карту сайта будет куда проще, но когда вы сами задумаетесь над связями различных областей сайта между собой, вы волей неволей начнете чиркать квадратики на бумаге.

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

Не забывайте присваивать номер каждой отдельной странице карты сайта. Это потребуется на этапе описания контента.

Полезные советы при рисовании карты сайта:

• Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг от друга. Это поможет читабельности карты.
• Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
• Выравнивайте «квадратики» страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
• Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны «перескакивать» одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
• Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
• Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.

Шаблоны страниц

На уровне карты сайта каждая страница представляет для нас только «квадратик» на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне недешево.

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

Описание шаблонов состоит из 3х частей:

1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

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

Описание контента

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

Далеко не всегда на момент написания ТЗ можно с уверенностью знать какой будет контент на сайте: точное количество информационных страниц, размещение графической информации, поэтому не думайте, что в данном разделе приводится самое точное описание. Часто это не так. Но если вы опишите требуемый контент на данном этапе, то далее проект-менеджер на его основе сможет составить план поставки контента и оценить объем внесения этой информации на сайт. У клиента же всегда перед глазами будет перечень того, что ему потребуется подготовить и отредактировать.

Хорошее описание контента залог спланированной работы на этапе запуска сайта и внесения информации.

Функционал

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

Хороший пример описания функционала дает ГОСТ. Рекомендую держаться стандарта при описании функционала разрабатываемого в рамках сайта программ. Должны быть описаны: общая система, общие функциональности подсистем и модулей, взаимосвязь подсистем и модулей между собой и, наконец, перечисление всех функций модулей с более или менее подробным описанием их работы. Для каждого модуля должны быть расписаны объекты, которые создаются или используются в работе программы.

Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе техническое задание этого не требует. По ГОСТу подобные подробности должны описывать в дальнейших документах: эскизный и технический проекты.

Иногда при разработке крупных сайтов приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы «клиенту было понятно». Полная ерунда! По опыту могу сказать, что лишней детализации не бывает. В случае проблем в проекте менеджеры проекта с обоих сторон становятся редкостными буквоедами! Они вычитывают ТЗ вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в ТЗ прописан общими словами клиент все равно заставит сделать то, что ему надо.

Требования

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

• Технические требования к системе;
• Требования к персоналу;
• Требования к надежности;
• Требования к эргономике и технической эстетике;
• Требования к защите информации от НСД;
• Требования по сохранности информации при авариях;
• Требования к видам обеспечения;
• Требования к программным средствам;
• Требования к информационному обеспечению;
• Требования к техническим средствам;

Может быть также ряд специфических требований.

Все требования необходимо четко формулировать и стараться не забыть ничего из аспектов разработки вашего проекта.

Конечно, в небольших проектах нет необходимости прописывать все приведенные выше требования. Так, например, часто персонала в веб-сайте вообще нет, поэтому такие разделы пропускают.

Прочее

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

Что дальше?

ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет.

Проект далеко не всегда идет по заранее запланированному пути. Мы стараемся что-то улучшить, изменить, часто меняются требования заказчика. Техническое задание это документ, а не скрижали. С изменением требований к проекту должно меняться и техническое задание. Обычно это делается дополнительными документами со списком изменений. Естественно, они составляются только в том случае если это действительно необходимо, на практике встречается редко.

Также вы должны быть готовы, что в процессе глубокого изучения ТЗ всеми участниками разработки в процессе работы над проектом будут найдены ошибки. Количество ошибок в большом документе прямо пропорционально его объему и обратно пропорционально времени, затраченному на его написание. Т.к. времени постоянно не хватает, следует ожидать, что ошибки в ТЗ будут возникать.

В сухом остатке

Эту статью я написал больше года назад. Прошло довольно много времени, а я за это время не написал ни одного большого ТЗ. Но, перечитав представленную информацию, согласился со всем, что здесь написано. Итак хорошее ТЗ на сайт должно содержать в себе:

• Общую информацию о документе и его составителях;
• Цели и задачи сайта;
• Описание пользователей сайта, их цели и задачи;
• Рамки проекта;
• Информационная архитектура (ИА) сайта: карта сайта, шаблоны, описание интерфейса;
• Описание контента сайта;
• Описание функционала сайта;
• Описание процесса и майлстоунов, если требуется;
• Перечень всевозможных требований при разработке сайта и верификации полученной работы.

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

Полезные ссылки

• ГОСТ 34.602-89.
• Нотация Гарретта.

Подразумевается, что у Вас есть элементарные знания Excel, но ничего слишком серьезного. Вам даже не обязательно иметь копию, все приведенные примеры работают так же хорошо и с OpenOffice Calc.
Знакомство с PEAR:: Spreadsheet_Excel_Writer

Вот и все. Мы готовы!

Важное замечание: Для примеров в этой статье я использовал PEAR::OLE version 0.5 и PEAR::Spreadsheet_Excel_Writer version 0.7. Предупреждаю, что кое — что может изменится в будущиx версияx.

Продолжаем наш путь. Давайте создадим простой лист данных.
Имя файла: example_1.php

Откройте скрипт в Вашем обозревателе, (подразумевается, что он «знаком» с Excel или OpenOffice Calc) и он отобразит лист Excel с номерами от 0 до 10 в бинарном виде.
Сохранение файлов

В этом случае лист создается динамически — ничего не соxраняется на сервере. Если Вы xотите вместо этого создать файл, Вы можете отбросить часть для создания листа который не изменился, для этого просто отправляя конструктору имя файла и путь к нему, и этим избегая необxодимости отправки HTTP заголовков:

Имя файла: example_2.php

Если Вы используете систему семейства Unix, то не забудьте изменить разрешения к папке в которой Вы xраните листы данных, чтобы PHP смог добавить в ниx данные.
Обзор API

Xорошо, мы разобрались с основными понятиями. Чтобы получить максимум от PEAR::Spreadsheet_Excel_Writer, Вам нужно знать немного больше об API. Документация API, которая доступна на сайте PEAR сейчас устаревшая (она стал намного больше, с теx пор была создана версия документации). Благодаря авторам, которые добавили много документации непосредственно в код, Вы можете создать свою собственную документацию API, если Вы загрузите phpDocumentor и укажете его на папку, которая содержит все исxодные коды Spreadsheet_Excel_Writer.

Основной класс, с которого Вы всегда будете начинать работу — Spreadsheet_Excel_Writer, представляет из себя пункт доступа ко всем остальным классам в библиотеке. Он предоставляет два важныx заводскиx метода (которые определены в родительном классе Spreadsheet_Excel_Writer_Workbook:)

* addWorksheet()- возвращает случай Spreadsheet_Excel_Writer_Worksheet. Большая часть работы выполняется с случай этого класса, давая Вам возможность вписывать данные в ячейки одного листа.
* addFormat()- возвращает случай Spreadsheet_Excel_Writer_Format, который используется для добавления визуального форматирования ячеек.

Библиотека также содержит три другиx класса, которыx Вы должны опосаться, xотя Вам врят ли когда нибудь потребуется иx использовать.

* Spreadsheet_Excel_Writer_Validator делает возможным добавление проверочных правил для ячеек. Сейчас для этого класса не существует документации. Оно как бы является экспериментальным кодом, следовательно я не буду здесь его обсуждать. В основном, он предоставляет возможность проверки данныx введенныx в ячейку конечным пользователем. Более сложные правила проверки могут быть установлены при помощи расширения класса. Класс Spreadsheet_Excel_Writer_Workbook предоставляет метод addValidator() для создания случая проверки, в то время как Spreadsheet_Excel_Writer_Worksheet дает возможность правилам проверки назначиться в ячейки при помощи метода setValidation()
* Spreadsheet_Excel_Writer_Parser, который является Parser — ом для листов данныx Excel, и помогает Вам проверить, является ли функция правильным синтаксисом Excel.
* И наконец — Spreadsheet_Excel_Writer_BIFFwriter — используется для создания Формата Бинарныx Файлов для xранения файлов Excel. Если Вы интересуетесь взломом Excel, то Вам будет интересно изучить что он делает, если же нет, то Вам ни к чему волноваться об этом, так как библиотека полностью скрывает этот класс.

Замешательство нулевого индекса.

Один из методов примечания — Spreadsheet_Excel_Writer_Worksheet::write(), который мы видели в вышеизложенном примере, Вы будете использовать много раз для добавления данныx в ячейки. Этот метод немного запутывающий по ставнению с тем же методом в Excel.

Первым аргументом функции write()является номер строки. Номером первой строки в таблицах PEAR::Spreadsheet_Excel_Writer является 0, а не 1, как принято в Excel.

Вторым аргументом является номер столбца. Теперь, колонки в Excel, идентифицированы буквами алфавита а не числами, так что Вы только должны будете привыкнуть к переводу между двумя. Буква F является 6-ым в алфавите, так что второй аргумент… 5 (конечно!) — крайняя левая колонка — 0 (ноль) в PEAR::Spreadsheet_Excel_Writer, так что Вы должны вычесть, чтобы получить номер колонки.

Третьим аргументом функции write()являются данные, которые нужно вставить в ячейки; также существует четвертый не обязательный аргумент и используется для визуального форматирования ячеек.

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

Так как насчет более красивыx листов? Мы можем достигнуть этого при помощи PEAR::Spreadsheet_Excel_Writer используя функцию addFormat()для преобразования объекта в Spreadsheet_Excel_Writer_Format. Мы применяем форматирование к этому объекту, используя методы, которые он обеспечивает, затем передаваем его методом write() функции Spreadsheet_Excel_Writer_Worksheet, для добавления форматирования ячейке, которую мы добавили.

Ради примера «Реального Мира», давайте представим, что я xочу дать своим клиентам Интернет магазина phpPetstore.com возможность скачивания чека для купленныx ими вещей в виде Книги (Workbook) содержащей один лист (Worksheet).

Я начинаю свой лист обычным материалом.

«Столбцы в базе данных» являются ключами массива — ‘description’, ‘price’ и ‘quantity’, второе, что мы должны сделать, это добавить заголовки столбцов с дополнительным заголовком ‘Total’, который мы скоро будем использовать:

Вы уже видели форматирование. Вы раньше не видели метод writeRow(). Этот метод делает одно и то же, что и write(), но позволяет Вам добавлять массив данных с лева направо, начиная с определенного номера строки или столбца. Этот метод позволяет значительно сократить код программы.

Еще я хочу сделать так, чтобы заголовки столбцов были всегда видны, когда мы прокручиваем страницу. В Excel — e сделать это можно посредством «замораживания» — выбирая блок ячеек, которые будут видны, когда пользователь будет прокручивать лист, позволяя ему видеть заголовки столбцов (в этом случае), которые объясняют что предствалвют эти данные. То же самое возможно в PEAR::Spreadsheet_Excel_Writer:

Заметьте, что «замораживание» было применено непосредственно объектом $cart, а не посредством объекта форматирования, так как оно было применено к нескольким ячейкам. С другой стороны, форматирование было применено к отдельным ячейкам.

Наконец я прохожу через обьекты в «своей сумке», добавляя данные к листу:

Вот в принцыпе и все. Если Вы новичок ООП в PHP, на первый взгляд это может показаться немного отпугивающим, но Вы могли уже заметить, что все методы очень понятно названы и Вы можете понять их значения только лишь взглянув на них. Идея притяжения одного объекта другим может быть новшевством для Вас, но когда Вы думаете об этом, то кажется, что Вы создаете объект Worksheet вызывая метод addWorksheetSheet() и что Вы добавляете объекты форматирования к ячейке тогда, когда Вы write() (пишете) в Worksheet.
Добавление функции Excel.

Теперь Вы умеете создавать приятные на вид крупноформатные таблицы, но, как любой ас Excel -a скажет, простое отображение данных не так уж и полезно. Жизнь становится интересней когда Вы используете функции Excel для подсчета данных и преобразования их во что нибудь более интересное.

Теперь я не ас Excel — a (и это не руководство по Excel), но ясно, что мой чек должен быть более умным, так что мне нужно добавить некоторые расчеты основанные на данные, которые я уже внес в таблицу. Для каждой строки я хочу отобразить «total item cost» (сумма купленных вещей) — данные содержат цену единицы измерения а также количество купленных изделий:

«total item cost» = «unit price» * «number of items purchased»

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

[Cell D5] =PRODUCT(B5:C5)

Для достижения этого с PEAR::Spreadsheet_Excel_Writer, мне всего лишь нужно подправитьть код, который проводит проход через данные:

Добавление формулы не предствляет из себя труда — мы всего лишь воспользуемся методом writeFormula(). Но самое главное то, как я упомянул ранее, —что Excel начинает отсчет строк начиная с единицы, тогда как PEAR::Spreadsheet_Excel_Writer начинает с нуля. Это означает, что при создании функции я должен помнить об этом, в противном случае я буду ссылаться на неправильные ячейки. Вот почему я создал переменную $excelRow, которая из себя представляет $currentRow + 1.Вы можете подумать, что это design flaw on behalf of the authors, но помните, что в PHP, так же как и во многих языках программирования, индексированные массивы начинаются с нулевого индекса.

Теперь мой отображает суммы для каждой строки. Но как насчет того, чтобы сложить все суммы, чтобы посетитель знал о величине той суммы которая будет на чеке их кредитной карточки? Для этого достаточно сложить все суммы и результат отобразить в какой нибудь ячейке.

Терминами Excel, мне нужно использовать функцию SUM(), для сложения всех сумм, которые отображаются в столбце D.

[Grand Total Cell] =SUM(D5:D7)

Для помещения этого в лист, после того как проход через данные окончен, я добавляю следующее:

Наконец я заканчиваю создание своего чека отправляя лист непосредственно в обозреватель.

Вот и все. Лист готов для скачивания.

В наше время формат документов PDF приобретает большую популярность. Он был разработан компанией Adobe Systems Incorporated. Как указано в документации, THE ADOBE PORTABLE DOCUMENT FORMAT (PDF) — переносимый формат документов, является «родным» для программных продуктов семейства Adobe Acrobat. Их цель — дать пользователю возможность легко обмениваться электронными документами и просматривать их независимо от той среды, в которой эти документы были созданы.

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

С другой стороны, web-приложения зачастую нуждаются в отображении динамически составленных документов, таких как отчеты, прайслисты, счета и многое другое. Это позволяет персонализировать приложение и сделать его более мощным по своим функциональным возможностям. Помимо PDF, существуют и другие решения, но этот формат можно назвать одним из самых удачных, так как PDF документ без потери форматирования можно вывести на принтер или конвертировать в HTML или текст.

PHP, как один из самых мощных и популярных современных средств разработки web-приложений, справляется с задачей генерации PDF документов «на лету». Для этого разработано несколько дополнительных инструментов. Не возьмусь перечислить их все, но назову одни из самых известных — библиотеку PDFLib, ClibPDF и PHP класс FPDF.

FPDF — только PHP

Названные в предыдущей главе PDFLib и ClibPDF требуют дополнительной настройки PHP, в то время как класс FPDF является чистым PHP кодом и легко подключается к скриптам командой include() и другими подобными. Скачать класс и ознакомиться с подробной документацией можно на сайте www.fpdf.org. Дополнительным (порой решающим) аргументом в пользу этого решения можно рассматривать его бесплатность для использования как в личных, так и коммерческих целях. Цитата из лицензионного соглашения:

«FPDF is Freeware (it is stated at the beginning of the source file). There is no usage restriction. You may embed it freely in your application (commercial or not), with or without modification».

Разрешается также видоизменять исходный код класса. Никаких ограничений.
Решение проблемы с кириллицей

При создании русскоязычных документов средствами иностранных программных продуктов (библиотек, приложений и прочего) часто возникает проблема правильного отображения кириллических шрифтов. Не всякий зарубежный продукт корректно работает (а то и вовсе не работает) с кириллицей. К счастью, класс FPDF не принадлежит к их числу и легко настраивается на работу с русским языком.

Если быть точным, то сам класс настраивать практически не придется. Проблема может возникнуть с файлами кириллических шрифтов. Оговорюсь, что тестирование класса я проводил на wintel платформе (впрочем, весь приведенный код работал и на коммерческом *nix хостинге). В windows одним из самых основных форматов шрифтов (наряду с PostScript) является TTF (True Type Font). Но для правильной работы наших скриптов необходим и еще один формат файлов — AFM (файл метрики шрифта). Как считается, AFM файлы поставляются вместе с TTF. В своей ОС я AFM файлов не обнаружил.

Здесь нам на помощь приходят полезные утилиты, в частности — ttf2pt1. Одна из задач данной утилиты — сгенерировать метрический файл для True Type или PFB. Другими словами, появляется возможность взять из директории /fonts (ОС Windows) любой .TTF файл шрифта с поддержкой кириллицы и получить для него метрику при помощи нашей волшебной утилиты. Скачать утилиту можно по следующим линкам: http://ttf2pt1.sourceforge.net и http://fpdf.org/fr/dl.php?id=22 (для Windows).

После того, как утилита скачана, ее необходимо запустить из командной строки (в windows Пуск->Выполнить команду cmd). Формат вызова утилиты для нужной нам цели выглядит следующим образом:

К примеру, если вы положили скачанный экземпляр ttf2pt1 прямо на диск C: , а файл шрифта times.ttf в C:CyrFonts, то вам будет необходимо запустить следующую команду:

Используя require, мы подключаем нужный скрипт. Понятно, что для этого рядом с нашим файлом должна быть папка font, содержащая в себе makefont/makefont.php. А вот функция MakeFont() уже является специфической и по определению имеет следующий формат:

где fontfile — путь к TTF или PFB файлу, afmfile — путь к AFM файлу, enc — имя используемой кодировки (по умолчанию это cp1252), patch — опциональное изменение кодировки и type — тип шрифта (по умолчанию True Type). Для выбора кодировки можно воспользоваться следующим списком:

* cp1250 (Central Europe)
* cp1251 (Cyrillic)
* cp1252 (Western Europe)
* cp1253 (Greek)
* cp1257 (Baltic)
* ISO-8859-1 (Western Europe)
* ISO-8859-2 (Central Europe)
* ISO-8859-4 (Baltic)
* ISO-8859-4 (Cyrillic)
* ISO-8859-7 (Greek)
* ISO-8859-15 (Western Europe)
* ISO-8859-16 (Central Europe)
* KOI8-R (Cyrillic)

Кодировка определяет связь между кодом (от 0 до 255) и символом. Для выбора кириллической кодировки в Windows используйте cp1251. Обычно кодировки с префиксом cp используются в Windows, в то время как Linux системы используют ISO.

Составленный нами скрипт mf.php необходимо открыть в браузере. Он подготовит для наших нужд необходимый файл с расширением php. Итак, что мы имеем? У нас теперь есть комплект из трех файлов шрифта — times.ttf, times.afm и times.php. Важно два из них (times.ttf и times.php) положить в нужное место. Этим местом является директория font, находящаяся в папке класса. Впрочем, вы вольны сами указать место директории, которая будет хранить шрифты. Для этого нужно определить константу FPDF_FONTPATH обыкновенным для PHP способом:

define(‘FPDF_FONTPATH’,’font/’);

Теперь наша система готова к разработке web приложения с динамической генерацией русскоязычного PDF документа.
Начинаем работу

Для наглядного иллюстрирования возможностей FPDF класса попробуем создать реальный документ — прайс-лист фирмы, занимающейся оптово-розничной продажей алкогольных напитков. Краткое техническое задание следующее:

* в шапке документа должны быть данные: логотип, наименование фирмы, заголовок документа;
* в теле документа должны быть приведены данные по товарным позициям, включающие наименование товара, розничную цену и оптовую цену;

Сразу разобьем нашу работу на три этапа. Первый этап — вывод статической информации. Для простоты примера к статической информации мы отнесем все, кроме данных по товарным позициям. На втором этапе уделим внимание табличному выводу товарных позиций в теле документа. Уточним, что в этой статье мы рассмотрим загрузку данных из файла CSV, где разделителем является точка с запятой. Я остановился на этом решении по одной причине — такой файл легко получить из формата xls и, одновременно, с ним легко работать из РНР приложения в других целях (например, организовать вывод в HTML). На третьем этапе мы рассмотрим доставку PDF файла конечному пользователю.

Приступим к практическому знакомству с классом FPDF. Для начала создадим файл price.php, который будет осуществлять вывод PDF документа прямо в браузер (остальные способы мы рассмотрим в главе 6). Рядом с этим рабочим файлом положим скачанный ранее fpdf.php (файл класса) и папку font с вложенными в нее файлами кириллических шрифтов (см. предыдущую главу). Теперь в файле price.php подключим класс FPDF и установим путь к папке шрифтов.

Необходимо уточнить, что тэг <?php должен стоять на самой первой строке файла, так как в последствии мы будем самостоятельно отправлять заголовки (headers), и пустая строка, текст или разметка HTML в начале файла могут нам помешать.

Для вывода статической информации (логотип, название фирмы, название документа) мы будем использовать следующие методы класса FPDF: cell() и image(). Метод cell() выводит ячейку (прямоугольную фигуру) с опциональной установкой границы, цветовой заливкой и строкой текста. Формат записи метода следующий:

Cell(float w [, float h [, string txt [, mixed border [, int ln [, string align [, int fill [, mixed link]]]]]]])

Метод image() отвечает за вывод графического изображения JPG или PNG. Формат вызова метода следующий:

Image(string file, float x, float y, float w [, float h [, string type [, mixed link]]])

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

После создания экземпляра класса нам будет необходимо указать используемые шрифты. Так как кириллический Times New Roman (рассмотренный в предыдущей главе) не является в классе FPDF шрифтом, установленным по умолчанию, сначала придется его «показать» скрипту. Это мы сделаем при помощи метода AddFont().

Первым аргументом функции мы указываем наименование шрифта. Его можно посмотреть в сгенерированном РНР файле (значение переменной $name). Второй аргумент — форматирование текста (B — Bold, I — Italic и смешанный BI или IB). Если аргумент пустой, то шрифт обычный. Для использования B и I необходимо также подключить соответствующие типы шрифтов (для Times New Roman это могут быть файлы timesI.ttf и timesBd.ttf). Третий аргумент — РНР файл описания (его мы сгенерировали в предыдущей главе). Теперь шрифт можно применять в данном документе. Для использования на странице установим его размер методом SetFont(). Этот метод можно вызывать несколько раз в одном скрипте, в то время как добавление AddFont() делается один раз для каждого шрифта. Формат записи SetFont() следующий:

SetFont(string family [, string style [, float size]])

Наконец-то можно сформировать содержимое страницы. На этом этапе мы столкнемся с увеличением количества кода, и поэтому, во избежание путаницы, расширим класс FPDF своими методами. Конечно, нет необходимости вносить изменения в сам FPDF класс. Мы напишем свой price.class.php, наследуемый от FPDF.

Листинг 1

Листинг 2

В этом файле мы столкнулись еще с несколькими методами класса FPDF. Необходимо заметить, что документ сначала создается в буфере и лишь потом, при вызове метода Output(), выводится в браузер. Поэтому общая схема работы с документом следующая: создаем в буфере документ методом Open(), затем для работы добавляем в этот документ страничку методом AddPage(), формируем содержимое документа различными методами типа Cell() и, наконец, выводим его из буфера в браузер. Если у вас установлен adobe acrobat версии не ниже 5.0, то при запуске price.php в браузере должен открыться документ price.pdf (в Internet Explorer) или сформируется документ doc.pdf для скачивания (в Opera).

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

Перейдем к самому интересному — динамическому формированию содержимого документа. Именно этой возможностью и ценен для РНР разработчика класс FPDF. Я уже говорил выше, что здесь мы рассмотрим вариант получения данных из CSV файла.

Как указано в нашем коротком техническом задании, тело прайс-листа должно состоять из трех граф: наименование товара, розничная цена и оптовая цена. Соответственно, подготовим и файл данных следующего вида:

Пиво «Балтика»;15.00;13.45
Пиво «Оболонь»;14.00;12.30
Водка «Nemiroff», 1 л.;100.00;89.45

Сохраним его как price.csv. Конечно, в реальном прайс-листе товарных позиций и граф будет больше.

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

Перед нами встает необходимость получить данные динамически и представить их в виде обыкновенной таблицы в три колонки, с заголовками колонок (столбцов). Перед созданием экземпляра объекта Price добавим инициализацию массива заголовков (соберем все заголовки в массив):

Далее нам понадобится еще больше расширить класс Price (унаследованный от класса FPDF) методами LoadData() и ImprovedTable(). Первый метод должен будет извлекать данные из CSV файла в массив $data, а второй метод пригодится для отрисовки таблицы с данными из этого массива. Рассмотрим метод LoadData() для класса Price.

Вставим этот код в файл класса price.class.php. Теперь перейдем к рассмотрению метода ImprovedTable().

Вот его код:

Вставим и этот метод в код класса Price. Теперь, когда мы обросли двумя новыми методами, попробуем их применить. Изменим код нашего главного файла (листинг 3).

Можно смотреть на промежуточный результат. Это практически все, чего мы хотели достичь.

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

Для этого необходимо организовать вывод «подвала» (footer) на каждой странице. С этой целью напишем метод Footer() нашего класса Price. Следует отметить, что методы Footer() и Header() заранее прописаны в классе FPDF и вызываются автоматически при выполнении метода AddPage() и Close().

По умолчанию они пустые, но их можно определить в своих наследуемых классах, при этом ни Footer() ни Header() не потребуется явно вызывать из приложения. Добавим в класс Price() следующий код метода:

Листинг 3

Теперь этот метод будет автоматически исполняться при вызове метода AddPage(). Для корректной работы необходим последний штрих — вызов из файла приложения (price.php) метода $price->AliasNbPages() перед $price->AddPage().

AliasNbPages([string alias])

При написании метода Footer() мы использовали также PageNo(), метод, возвращающий номер текущей страницы и параметр {nb}, который по умолчанию будет заменен цифрой общего количества страниц в текущем документе. Документ готов, и перед нами встает необходимость его вывода в браузер.
Вывод в браузер

По идее, существует всего два варианта вывода документа в браузер — открытие (если установлен adobe acrobat) и скачивание без непосредственного открытия. В классе FPDF выводом документа в браузер управляет метод Output(). В нашем примере мы использовали этот метод без дополнительных аргументов. Однако документация к FPDF приводит следующий формат его записи:

Output([string file [, boolean download]])

Метод предназначен для сохранения PDF документа в локальный файл или для непосредственного вывода в браузер (если установлена программа просмотра PDF файлов).

Аргумент file означает имя файла. Если таковое отсутствует, то производится попытка открыть документ в окне браузера. Если аргумент file определен, то аргумент download указывает, что файл должен быть сохранен на сервере (значение false) или у пользователя (при установке true выводится диалог «Сохранить как»).

Соответственно, можно выделить три варианта написания метода Output() для нашего документа. Первый — Output() — пытается открыть документ в окне браузера. Второй вариант написания выведет у пользователя диалоговое окно «Сохранить как» и предложит скачать документ на его диск — Output(«AlkoPrice.pdf», true). И, наконец, третий вариант просто сохранит документ на локальном для скрипта сервере — Output(«AlkoPrice.pdf»,false) или просто Output(«AlkoPrice.pdf»), так как по умолчанию атрибут download всегда имеет значение false.

Стоит отдельно рассмотреть компрессию полученного файла. По умолчанию будет произведена попытка его «ужать» средствами Zlib. Это расширение (extension) должно быть установлено в системе. Если установка не была произведена, то документ получится не сжатым, и будет весить немного больше.

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

Зачастую компании разрабатывают сложные ERP системы, для глубокой интеграции информации в повседневные операции всех сотрудников компании. Но цена таких решение достигает сотен и даже миллионов долларов. 

Сегодня я расскажу решение для мелкого и среднего уровня бизнеса, которое по себестоимости будет в сотни раз дешевле любой ЕRP, а по приносимой прибыли сможет сравняться с подобной системой. 

Итак давайте сначала обрисуем список целей и требований  для нашей системы: 

1. Новостная информация по компании. Что, где происходит, каких успехов достигли, кто больше всего отличился. 
2. Оперативная информация с полев боя вашего бизнеса. Кто, где, когда. 
3. Информация о ресурсах, в случае если бизнес информационный — важно знать компетенции каждого из сотрудников
4. Было бы не плохо иметь единую точку авторизации, например Microsoft Active Directory т.е. один логин для всех систем
5. Общий доступ к документообороту, файлам, шаблонам документов и т.д. 

На мой взгляд, если Заказчик сам готовит контент для наполнения сайта, лучше всего подготовить для него список необходимых текстовых и графических материалов, а кроме этого выслать требования по их подготовке. Сейчас я попробую перечислить, какие требования могут быть:

1. Тексты на статичные страницы

Необходимо ещё раз повторить структуру сайта (даже если она есть в Концепции), указав, для каких из них какие тексты нужны.

Например, для страницы «Услуги компании» требования могут звучать следующим образом:

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

Требования по высылаемым материалам могут выглядеть так:

Текст для каждой страницы должен быть помещён в отдельный текстовый документ. Название документа соответствует названию страницы (по Концепции).

2. Тексты новостей

(аналогично для статей и пресс-релизов)

Надо объяснить Заказчику, что для размещения на сайте новости необходима следующая информация:

• заголовок новости;
• дата публикации;
• имя автора (если это необходимо);
• краткое описание, для вывода его в общем списке новостей
  краткое описание должно содержать 2-3 предложения, можно использовать первый абзац полного текста новости;
• полный текст новости;
• ссылка на источник (если это необходимо).

Требования по высылаемым материалам:

Вся информация по одной новости должна размещаться в одном текстовом документе. Название документа соответствует дате публикации новости и её заголовку.

3. Фотографии

Если обработка фотографий не входит в стоимость проекта, то нужно указать Заказчику:

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

Требования по высылаемым материалам:

Изображения, высылаемые для фотогалереи необходимо разместить в отдельных папках, соответствующих названиям разделов фотогалереи. Внутри каждой папки фотографии должны быть отсортированы в том порядке, в котором они будут размещаться на сайте, фотографии должны иметь названия 01, 02 и т.д. Все описания фотографий должны быть перечислены в общем текстовом документе, в виде:

• 01 — описание 1
• 02 — описание 2 и т.д.

4. Каталог

Что касается каталога, многое зависит от того, чем занимается компания и насколько полный каталог будет представлен на сайте. Могу привести пример того, какая информация для каталога может понадобиться:

• наименование позиции каталога;
• описание позиции каталога;
• раздел и подраздел (если в каталоге выделено несколько разделов и подразделов);
• фотография;
• чертёж;
• фотографии для фотогалереи;
• ширина, высота, вес и т.п.;
• таблица технических характеристик;
• документация для скачивания;
• инструкция по использованию и т.д.

Требования по высылаемым материалам:

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

5. Сотрудники компании

Информация о сотрудниках компании может использоваться на странице о руководстве или структуре компании. В этом случае будет нужна следующая информация:

• фамилия, имя, отчество;
• занимаемая должность;
• контактный телефон;
• контактный e-mail;
• фотография.

6. Сервисы на сайте

Если на сайте будут предусмотрены онлайновые сервисы, позволяющие общаться посетителям сайта и сотрудникам компании, то понадобится следующий список:

• фамилия, имя, отчество сотрудника;
• его контактный e-mail (на который будут отправляться сообщения от посетителей сайта);
• услуга или вопросы, за которые данный сотрудник является ответственным (например, вопросы по доставке или по техническому обслуживанию).

7. Интекрактивная карта

Это может быть карта дилеров компании, её офисов или клиентов, может быть карта построенных домов или, например, АЗС. В этом случае вся информация для карты должна быть представлена в следующем виде (на примере дилеров, расположенных в разных городах):

• название компании дилера;
• город;
• адрес;
• логотип;
• контактный телефон;
• контактное лицо;
• схема проезда.

Примечание: адрес, логотип, телефон, контактное лицо и схема проезда будут нужны, если на карте предусмотрены окошки с более подробной информацией, которые всплывают при наведении на одного дилера.

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

Взято с http://habrahabr.ru/blogs/webdev/44886/