Как писать техническое задание на сайт?

Техническое задание на сайт: понятие веб-сайта, классификация веб-сайтов, веб-сайт как фронтальная часть автоматизированной системы или системы обработки информации, методика заполнения разделов техзадания на разработку сайтов. Функциональная часть изложена в статье Как писать техническое задание для сайта на Drupal? Редакция от 08.12.2023.

Создан 04.01.2009 16:59:54

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

- Эффективная реклама колы

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

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

Далее:
Терминология, применимая к веб-ресурсам
Классификация веб-сайтов
Разделы технического задания на сайт
Назначение и цели создания системы
Требования к структуре и функционированию системы
Требования к численности и квалификации персонала и режиму его работы
Требования к надежности
Требования безопасности
Требования по допустимым уровням освещенности, вибрационных и шумовых нагрузок
Требования к эргономике и технической эстетике
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Требования к защите информации от несанкционированного доступа
Требования по сохранности информации при авариях
Требования к защите от влияния внешних воздействий
Требования к функциям (задачам), выполняемым системой
Требования к видам обеспечения
Состав и содержание работ по созданию системы
Итоги

Терминология, применимая к веб-ресурсам

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

- Определение веб-сайта по википедии

Глубокая проработка вопроса...

Примечание от 22.08.2014 г. - Совсем недавно был введен в действие ГОСТ Р 52872-2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению. В нем приведена кривенькая и очень-очень спорная терминология, но ГОСТ есть ГОСТ и придется пользоваться именно им.

Что же в реальности? Имеется физический сервер (средство технического обеспечения), на котором установлена операционная система (общее программное обеспечение), «поверх» которой выполняется веб-сервер Apache (nginx и т.п.) - «технологическое» программное обеспечение. На жестких (или SSD) дисках физического сервера размещается та самая «совокупность документов частного лица или организации» в виде файлов формата HTML (часть информационного обеспечения). Это «серверная» часть вопроса.

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

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

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

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

  1. серверная и клиентская стороны оснащены средствами технического обеспечения (физический сервер и пользовательский компьютер);
  2. обе стороны применяют общее и «технологическое» программное обеспечение (операционные системы и т.д.);
  3. на серверной части имеет место быть информационное обеспечение - «совокупность документов частного лица или организации»;
  4. пользователь (а имеется еще и пользователь) получает информацию с сервера на одном или нескольких языках - признаки лингвистического обеспечения;
  5. кто-то же создает и заливает на сервер «совокупность документов частного лица или организации»? Все признаки организационного обеспечения;
  6. и т. д...

Обратимся к первоисточникам. Автоматизированная система - это «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций [из 1.1 ГОСТ 34.003—90]»

Налицо персонал, комплекс средств автоматизации, перечисленные виды обеспечения - компоненты АС и т.д. Таким образом, клиентская и серверная стороны обладают всеми признаками автоматизированной системы.

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

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

Классификация веб-сайтов

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

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

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

Для ресурсов с невысокой посещаемостью - 500 хостов, 2000 хитов и «текстовым» трафиком - достаточно виртуального хостинга с бюджетным тарифным планом, а из персонала - редактора и администратора в одном лице. Для ресурсов, подобных порталу sportbox.ru, на который единовременно заходят десятки и сотни тысяч посетителей, просматривающих прямые телевизионные трансляции, необходимы десятки кластеризованных физических серверов, каналы связи с гигабитной (и выше) пропускной способностью, команда круглосуточно дежурящих администраторов, программистов, верстальщиков и редакторов в полсотни человек.

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

Таким образом, указанные выше критерии можно считать основополагающими, первичными «половыми признаками», а изложенные в Педевикии - вторичными.

Разделы технического задания на сайт

Коль скоро выяснилось, что веб-сайт является фронтальной частью автоматизированной системы, имеет смысл сдуть пыль с ГОСТ 34.602-89 и углубиться в его изучение. Далее будет рассмотрено наполнение содержанием основных разделов технического задания по ГОСТ 34.602-89.

Назначение и цели создания системы

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

Далее:
Назначение сайта
Назначение АС сайта
Цели создания сайта
Цели создания АС сайта
Выводы

Назначение сайта

Сайт предназначен для решения перечисленных ниже задач:

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

Назначение АС сайта

АС сайта предназначена для решения перечисленных ниже задач:

  1. задачи обеспечения надежного функционирования сайта;
  2. задачи обеспечения адаптивности к изменяющимся требованиям пользователей сайта за счет увеличения числа и качественных показателей предоставляемых сайтом услуг;
  3. задачи обеспечения единого унифицированного механизма поиска по всем информационным объектам сайта, включая индексацию и поиск объектов, используемых в рамках подсистемы «...», а также сервисов публикации мультимедийной информации;
  4. задачи обеспечения единого механизма регистрации, авторизации и аутентификации пользователей в рамках всех персонифицированных сервисов, предоставляемых сайтом (Форум, Вопрос-Ответ и т.п.);
  5. задачи обеспечения единого механизма сбора, хранения, анализа и предоставления статистических данных о востребованности публикуемых индивидуальных страниц сайта, а также информационных и сервисных разделов внешнего интерфейса сайта;
  6. задачи обеспечения доступности сайта для конечных пользователей и партнеров;
  7. задачи обеспечения масштабирования как сайта, так и АС сайта в целом.

Цели создания сайта

Целями создания сайта являются:

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

Цели создания АС сайта

Целями создания АС сайта являются:

  1. повышение надежности функционирования сайта до значения не менее 99,99 % (24 часа 7 дней в неделю 365 дней в году);
  2. повышение доступности сайта для конечных пользователей и партнеров;
  3. повышение адаптивности к изменяющимся требованиям пользователей сервисов сайта;
  4. повышение комплексности подачи информации в рамках интересующей пользователя проблемной области, т.е. повышения уровня «проблемной» ориентированности публикуемых индивидуальных страниц сайта, заключающейся в предоставлении по запросу пользователей максимально возможного количества аннотированных информационных объектов различных типов;
  5. повышение эффективности предоставляемых административных средств обратной связи с аудиторией сайта, в частности, создание административных средств оперативного автоматизированного анализа и предоставления динамических аналитических (служебных) отчетов о востребованности пользователями той или иной публикуемой информации и/или предоставляемой услуги;
  6. дальнейшее развитие функциональных возможностей информационно-аналитической системы и повышение эффективности ее использования в текущей работе сотрудников;
  7. повышение производительности, позволяющей масштабировать сервисы сайта в широких пределах;
  8. повышение масштабируемости подсистем за счет увеличения количества серверов в них;
  9. повышение масштабируемости всей АС сайта за счет увеличения количества подсистем (наращивание предоставляемых АС сайта сервисов).

Выводы

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

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

Требования к структуре и функционированию системы

Какие требования к структуре и функционированию системы можно придумать для сайта-визитки, состоящего из страничек «Новости», «О нас», «Услуги» и «Контакты»? Да никаких... Странички сливаются на виртуальный хостинг через файловый менеджер в виде веб-формы, указывается вид стартового файла index.htm (html, php, asp), и на этом все заканчивается. Решение иных вопросов на свои хрупкие плечи возлагает хостинг-провайдер. А как быть с аналогичными требованиями к серьезному порталу? На рисунке ниже приведено определение интернет-портала, представляющееся автору более-менее обоснованным. Обычный сайт отличается от портала только тем, что не предоставляет посетителю возможностей интерактивного взаимодействия.

- Определение Интернет-портала

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

А как балансировать пользовательские запросы? Созданием подсистемы балансировки запросов. А если налетят злобные хакеры? Придется создать подсистему безопасности...

А как работать с удаленным персоналом? Организацией подсистемы удаленного доступа: точки входа для админов, точки входа для программеров, точки входа для редакторов, тестеров, техписов (прости, господи!) и т.д.

А как тестировать систему? Созданием тестовых серверов и подсистемы прототипирования.

А как вообще все это увязать промеж себя? Организацией подсистемы сетевой инфраструктуры. И так далее...

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

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

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

Далее:
Требования к способам и средствам связи для информационного обмена между компонентами системы
Требования к характеристикам взаимосвязей со смежными системами
Требования к совместимости со смежными системами
Указания о способах обмена информацией
Требования к режимам функционирования системы
Перспективы развития, модернизации системы

Требования к способам и средствам связи для информационного обмена между компонентами системы

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

Физически каналы связи могут быть выполнены как угодно: оптикой (ВОЛС), Ethernet и т.д. На практике широко применяется стандарт IEEE 802.x. Для сайтов-визиток формулировать в техническом задании требования данного раздела не имеет никакого смысла, поскольку указанные вопросы решаются хостинг-провайдером.

Требования к характеристикам взаимосвязей со смежными системами

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

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

Требования к совместимости со смежными системами

Требования к совместимости со смежными системами реализуются:

Здесь речь идет как о технической, так и о информационной совместимостях астоматизированных систем.

Указания о способах обмена информацией

Подраздел говорит сам за себя - автоматически, вручную и т.д.

Требования к режимам функционирования системы

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

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

Перспективы развития, модернизации системы

Перспективы развития, модернизации системы:

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

Для сайтов-визиток перечисленные возможности определяются тарифным планом хостинг-провайдера.

- Тарифы хостинг-провайдера

Требования к численности и квалификации персонала и режиму его работы

Численность персонала системы должна удовлетворять перечисленным ниже требованиям:

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

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

Требования к надежности

Серьезные порталы, как и несерьезные сайты-визитки, должны быть доступны посетителю 365 дней в году, 7 дней в неделю и 24 часа в сутки. Надежность визиток берет на себя хостинг-провайдер, поэтому данный пункт требований для них неактуален. Надежность же серьезного портала должна быть выражена через коэффициент готовности, время восстановления и прочие показатели, регламентируемые ГОСТ 27.002-89, такие как показатели надежности, безотказности, долговечности, ремонтопригодности, сохраняемости и т.д. (для технических средств).

Для программного обеспечения портала стоит привести:

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

Требования безопасности

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

Требования по допустимым уровням освещенности, вибрационных и шумовых нагрузок

Актуальны для серьезных порталов, ТС которых размещены на площадях заказчика, особенно в тех случаях, когда под площадкой проходит неглубоко залегающая ветка метрополитена - земля буквально дрожит под ногами. Нормативы: СанПин 2.2.2.542-96, ГОСТ 12.1.012-90, ГОСТ 12.1.003-83, ГОСТ 12.1.036-81, ГОСТ 27818 и ГОСТ 26329 (имеет смысл проверить на изменения).

Требования к эргономике и технической эстетике

Для серьезных порталов. Нормативы: ГОСТ 12.2.049, ГОСТ 30.001, ГОСТ 20.39.108, ГОСТ 21958 и ГОСТ 50948 (для видеомониторов с ЭЛТ).

Примечание от 23.01.2022 - В стародавние времена подготовки настоящей статьи не был еще принят и введен в действие ГОСТ Р ИСО 9241-151-2014 Эргономика взаимодействия человек-система. Часть 151. Руководство по проектированию пользовательских интерфейсов сети Интернет. Ergonomics of human-system interaction. В нем хорошо и подробно все расписано.

Далее:
Комфортность условий работы персонала

Комфортность условий работы персонала

Для серьезных порталов. Нормативы: ГОСТ 21958, ГОСТ 12.2.049, ГОСТ 20.39.108.

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Далее:
Виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания
Предварительные требования к допустимым площадям для размещения персонала и ТС системы
Требования к параметрам сетей энергоснабжения

Виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания

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

  • ежедневное техническое обслуживание (ТО-1 или ЕТО);
  • ежемесячное техническое обслуживание (ТО-2);
  • полугодовое техническое обслуживание (ТО-3).

Предварительные требования к допустимым площадям для размещения персонала и ТС системы

Согласно СанПиН 2.2.2.542-96.

Требования к параметрам сетей энергоснабжения

Согласно ГОСТ 13109-97.

Требования к защите информации от несанкционированного доступа

Кому не лень, тот поднимет руководящие документы ФСТЭК (бывш. Гостехкомиссия), классифицирует автоматизированную систему и распишет требования по защите от НСД согласно вида АС.

Требования по сохранности информации при авариях

Система в целом должна обеспечивать сохранность, целостность и корректность информации:

Требования к защите от влияния внешних воздействий

Для серьезных порталов следует определить класс оборудования согласно ГОСТ Р 51318.22, а также требования к стойкости, устойчивости и прочности к воздействию внешних факторов. А ВВФ много - в одном только ГОСТ 26883-86 дано целых 56 терминов и определений. Наиболее актуальные из них (в части технических средств портала, размещаемых в специально оборудованных помещениях):

Требования к функциям (задачам), выполняемым системой

Здесь все сугубо индивидуально, поскольку функционал веб-сайтов может существенно отличаться. Форумы, галереи, блоги, опросы, чаты и т.д. - функционал у каждого свой. Для сайтов на Drupal функциональная часть расписана в статье

Требования к видам обеспечения

Далее:
Требования к информационному обеспечению
Требования к лингвистическому обеспечению
Требования к программному обеспечению
Требования к техническому обеспечению
Требования к организационному обеспечению

Требования к информационному обеспечению

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

- Макет структуры разделов портала

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

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

Требования к лингвистическому обеспечению

Помимо языковых требований лингвистическое обеспечение должно обеспечивать:

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

Требования к программному обеспечению

К визиткам не предъявляется. К серьезным порталам - требования самые серьезные. Общеизвестно, что ОПО, производимое конторой нашего американского друга Билла, малопригодно для порталов с большим трафиком, требующим, к тому же, высокого уровня информационной безопасности. Таким образом, лучший путь - решения open source.

Из личного опыта автора: пока сайт authorit.ru «висел» на NT-хостинге, он и «висел» в буквальном смысле слова. Не было ни дня, чтобы сайт был полностью доступен, а уж в выходные достучаться до него (и техподдержки) было и вовсе невозможно. Когда окончательно надоела ежедневная ругань со службой техподдержки хостинг-провайдера, был совершен переход на UNIX-хостинг и все проблемы исчезли сами собой.

Раскрывать секреты мастерства админов автор не вправе, но рекомендовать решения на основе OpenVZ, MySQL, PostgreSQL и Drupal (для порталов) вправе.

Требования к техническому обеспечению

Относятся к серьезным порталам. Предварительно следует оценить объемы хранения данных и объемы трафика - на их основе требования к техническим средствам хранения данных и к ТС каналообразования родятся сами собой. Ну и, разумеется, к производительности серверного оборудования. Какую либо конкретику для данного раздела привести трудно, но в АС портала sportbox.ru задействовано свыше 40 блейд-серверов от HP.

Требования к организационному обеспечению

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

Состав и содержание работ по созданию системы

Данный и нижележащие разделы детально приведены в документах:

Итоги

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

Удачи!