Разработка: техническое задание на сайт или концепция?

Содержание

Содержание технического задания

Я не буду говорить о ГОСТе и детальных спецификациях по ГОСТу. На мой субъективный взгляд, гораздо важнее в точности описать то, что вам нужно, нежели придерживаться некоторых правил оформления.


Что является самым важным для ТЗ?

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

Раздел Термины и определения. Не нужно забивать его общими понятиями типа “сайт”, “хорошо”, “плохо”. Здесь должны быть термины предметной области (например, “Обналичивание чеков”), с которыми предстоит познакомиться разработчикам, а также специфические термины, которых может не знать заказчик (например, “DNS-зона”). Термины и определения должны встречаться не только в этом разделе, а использоваться в ТЗ! Не создавайте мертвые термины, которые не планируете использовать.

Раздел Общие моменты по взаимодействию. Здесь мы проявляем различные ожидания по взаимодействию. Например, что все, что не описано в ТЗ – это доп (дополнительные работы; доработка, не включенная в ТЗ), который оплачивается отдельно. Заказчик должен сразу это понимать, а не делать изумленный взгляд, когда ему сообщают, что реализовать кабинет Исполнителя в системе – отдельный доп, которого нет в текущем ТЗ.

Раздел Структура сайта и структура данных. Важнейший раздел, где описывается скелет будущего проекта. Прописываем все страницы, карту адресов и краткое описание, что будет на странице. Это по сути задает некоторые границы проекта.

Структура данных описывает основные сущности, связи между сущностями и атрибуты сущностей. Например, сущность Заказ, имеет атрибуты – Стоимость, Товары, Дата заказа и др.

Раздел Требования к страницам. Здесь описываются конкретные требования к каждой странице. Главное слово “конкретные”. Очень опасно писать неконкретику в этом разделе – это порождает споры и недопонимание на этапе сдачи проекта. “Я думал, что это входит”, “а мы поняли это так-то…”.

В нашей практике был случай, когда лет 7 назад в ТЗ была прописана безобидная фраза “Интеграция с 1С”. Такого автора ТЗ можно смело увольнять – при такой постановке задачи заказчик вправе интегрировать все, что угодно из 1С. Нужно конкретно указать какие данные будут передавать из 1С (в одну сторону или в обе). Без этих деталей есть риск возникновения принципиальных разногласий.

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

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

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

Раздел про Требования к заказчику. Да, заказчик тоже должен участвовать в проекте. И надо явно обозначить его роль. Чем точнее эта роль и чем лучше заказчик осознает свои обязанности в проекте, тем больше шансов на успех проекта. Наверно кто-то подумает “вообще обнаглели. Заказчику вешают какие-то обязанности”. Можно и так сказать, но сознательный разработчик-исполнитель должен понимать, что ему не нужна в портфолио мертвая работа. Если заказчик себя плохо проявляет в начале проекта в плане общего менеджмента, то, вероятнее всего, проект быстро загнется, а исполнитель просто потратит время на неперспективный проект.

«Обычное» техническое задание

Зачастую техническое задание (если оно вообще есть) это нудный документ, в котором постранично текстом описано, что должно быть на сайте, с перечислением элементов и блоков через запятую или списком. Если очень повезет — для некоторых страниц нарисованы схемы. Делается оно обычно путем копирования кусков из старых технических заданий. Так например, в этом году я видел несколько ТЗ с требованием верстки под 800×600 и IE 6 (люди, откуда вы это копируете?? срочно сотрите!) Проверяется через строку (длинное, вычитывать лень). Заказчиком вообще читается через абзац — по той же причине.

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

Потом — это все верстается и программируется. Программисты долго пытаются состыковать ТЗ с макетами, и в результате что-то получается.

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

При это очень важно быстро сдавать проект/этап, фиксировать сдачу и переходить к следующей итерации. Остальное не работает.

Пример

Статика

Страница “Раздел каталога”

  1. “Хлебные крошки”
  2. “Дерево каталога”
  3. “Фильтрация. Общие положения”
  4. “Фильтрация. Текст”
  5. “Фильтрация. Текст и изображение”
  6. “Фильтрация. Диапазон”
  7. “Сортировка. По умолчанию”
  8. “Сортировка. По возрастанию цены“
  9. “Сортировка. По убыванию цены”
  10. “Превью товара. Плитка”
  11. “Пагинация. Постраничная”
  12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

Динамика

Функционал “Фильтрация. Общие положения”

  • выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
  • название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
  • цвет кнопки фильтра меняется на вид используемого фильтра
  • в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
  • у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
  • пагинация сбрасывается

Функционал “Превью товара. Плитка”

  1. Цена (целое число в рублях РФ)
  2. Название товара
  3. Метка “В магазине” или “С витрины”
  4. Изображение
  5. Размер
  6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
  7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

Административная панель

Товар

  1. Название (текст)
  2. Бренд (радио)
  3. Изображения
  4. Цена (целое число)
  5. Описание (текстовый блок)
  6. Тип (магазин/витрина, радио)
  7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
  8. Статус. Возможны варианты:
    1. на продаже
    2. на модерации
    3. на доработке
    4. отклонен
    5. продан
    6. не прошел проверку
    7. отменен Продавцом
  9. Размер с бирки (необязательное). Текстовое поле без валидации

Без ТЗ вы получите не то, чего ожидали

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

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

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

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

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

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

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

2.2 Основные задачи сайта

2.2.1 Имиджевая:

Сайт является нашем «лицом» (лицом нашей организации) в сети интернет и должен:

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

б) Поддерживать чистый образ:

  • партнера, помогающего решить все вопросы;
  • грамотного специалиста в своей отросли;
  • компании, с которой легко сотрудничать.

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

2.2.2 Информационная:

Сайт должен предоставлять открытый доступ к информации:

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

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

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

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

Статус текущего документа и конфиденциальность.

Назначение проекта.Указывается: для чего будет использоваться полученный продукт.

Цели создания и задачи, которые должен решить ресурс.С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены не четко и неизмеримо, то может быть довольно сложно им следовать.

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

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

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

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

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

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

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

Пример карты сайта.Шаблоны страниц

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

ОговоркаПример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).Описание контента

Требования

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

Отформатируйте ТЗ, чтобы его было удобно читать и редактировать

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

На что обратить внимание:

  1. Составляйте списки (вместо сплошного текста)

  2. Оформляйте заголовки через стили H1, H2 и так далее (для автоматического оглавления в Google Документах)


  3. Выделяйте ключевые фразы (для чтения по диагонали)

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

  5. Пользуйтесь внутренними ссылками

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

Рекомендации и советы

Главная рекомендация, это делать. Беда в том, что лень-матушка одолевает каждого и сопротивляться ей не просто. Соберите всю волю в кулак и начинайте писать техническое задание, просто пишите и не останавливайтесь. Не переживайте, что не получается “идеально”, открою тайну, такого и не бывает. Просто пишите, с каждым разом будет получаться лучше и лучше.

Вот так надо

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

Рекомендую использовать структуру ТЗ даже для небольших задач. Никто не просит вас расписывать каждый блок подробно. Просто попробуйте несколько раз оформить свою задачу в виде тех.задания.

Например для задачи “Кнопка лайк на сайте”:

  1. Описание: необходимо создать кнопку “Лайк” на нашем сайте.
  2. Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
  3. Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
  4. Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17),  разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
  5. Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
  6. Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.

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

Сбор и анализ требований

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

  1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
  2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
  3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
  4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
  5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

Учтите все необходимые работы

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

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

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

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

Примерно так описывается общая логика работы.

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

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Что еще должно быть? Неплохо было бы указать совместимость.

Этап 3. Проектирование сайта (формирование решения)

1. Комплект документов Архитектура сайта («Бумажный тигр»)

Составляем комплект документов с описанием архитектуры будущего сайта. Согласовываем с клиентом этот комплект документ в бумажном виде (в редких случаях в электронном виде).

1.4. Схемы страниц, с.26

Интерфейс – блоки – пока не утвердим от клиента не уезжаем.

После согласования можно приступать к прототипу.

2. Прототип интерфейса

Эскизное решение?

В отличие от Архитектуры проекта, интерфейс представляем в эл. виде.

Функции прототипа

Показать наличие / отсутствие на странице блоков и элементов (т.е. смысла).

Помочь определиться какие элементы могут быть статическими, а какие динамическими.

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

Показать логические связи между блоками / элементами.

В какой-то степени показать приоритеты.


Прототип не определяет однозначно форму, расположение и цвет элементов. Это утверждается на этапе дизайна.

Критерии прототипа

Между простотой и дизайном.

Прототип не должен выглядеть как недоделанный уродливый дизайн.

Может быть или черно-белым, или цветным.

Интерактивный. Хорошо, если интерактивный, хотя бы условно.

Опрятный.

При необходимости корректируем его.

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011

  • 1. Назначение системы
  • 2. Содержание системы (границы системы)
  • 3. Обзор системы
    • 1. Содержание системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения
  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке
  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений
  • 1. Назначение
  • 2. Содержание (границы)
    • 3. Обзор продукта
    • 1. Взаимодействие продукта (с другими продуктами и компонентами)
    • 2. Функции продукта (краткое описание)
    • 3. Характеристики пользователей
    • 4. Ограничения
  • 4. Термины и определения
  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования
  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Описание функционала

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

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

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

Для начала нужно рассказать о компании. Тут могут быть страницы о компании, история компании, контакты, отзывы.

Далее может идти вкладка «новости». Подпункты могут быть «события», «акции», «новое».

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

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

о компании

история компании

контакты

отзывы

новости

события

акции

новое

продукция

каталог продукции

релизы

отзывы о продукции

сервис

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы


партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Как составить техническое задание

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

Вместе с тем, надо помнить, что эти два ГОСТа имеют отношение именно к программным комплексам. То есть, в современном понимании — к сайтам, приложениям, системам автоматизации. ТЗ на размещение предприятия общественного питания в бюджетном учреждении придётся писать по другим правилам.

ГОСТ

Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.

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

Само техническое задание должно содержать следующие пункты:

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

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

Текст технического задания строится по структуре:

  • Общие сведения;
  • Назначение и цели создания (развития) системы;
  • Характеристика объектов автоматизации;
  • Требования к системе;
  • Состав и содержание работ по созданию системы;
  • Порядок контроля и приемки системы;
  • Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  • Требования к документированию;
  • Источники разработки.

Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

Заключение

Разработка и управление требованиями к ПОпример ТЗ, который я писал много лет назад

  • Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
  • Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
  • Правила составления Software requirements specification (читать вместе с комментариями)
  • Примеры ТЗ и другой документации по разработке АС для МЭР
  • ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
  • Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

Заключение

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

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

И не забывайте про задание!

P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее


С этим читают