Техническое задание на сайт. Практика

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

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

Структура техзадания будет иметь следующий вид:

1. Общие слова
2. Эксплуатационное назначение
3. Функциональное назначение
4. Термины и определения
5. Типы данных
6. Функциональные характеристики
7. Страницы
8. Требования к надежности
9. Требования к хостингу
10. Наполнение контентом
11. Сдача и приемка

Вот эти разделы и будут описаны в нашем примере ТЗ.

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

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

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

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

В тексте ТЗ будут отметки рядом с текстом.

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

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

---

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

Приступим к анализу задачи.

Шаг 1. Первоначальная схема сайта.

Набросаем грубо план-схему будущего сайта.

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

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

Создав новый проект и набросав эту схемку в azalo.net, мы уже немного написали ТЗ. Мы сделали заготовку под ТЗ, каждой коробочке (странице) на схеме соответствует пункт, и у нас заготовлены места под все остальные части ТЗ.

Показываем и поясняем схему заказчику, он смотрит всё ли есть и подтверждает наше понимание. Пока движемся правильно.

Ссылка на техническое задание, схема сайта.

На случай хабрэффекта тз на дропбоксе, скриншот схемы.

Шаг 2. Вводная часть, требования к хостингу и надежности, условия сдачи и приемки.

Пока в голове зреют детали будущего сайта, заполним разделы в начале и конце техзадания, которые слабо связаны с остальными частями ТЗ. Это разделы 1-3, 8-10 нашего ТЗ.

Общие положения

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

Необходимо создать веб-сайт для турбазы „Лесистые холмы“. Турбаза находится на берегу Чёрного моря в окружении невысоких гор и расположена на паре холмов. Имеет 16 домиков с 3 категориями номеров. Домики имеют по 2 и 4 комнаты. При оформлении путевки клиент указывает тип номера, но конкретный домик определяется менеджером на основе свободных мест.

В сервисе azalo.net этот кусочек будет выглядеть так:

Теперь мы более-менее представляем для какой турбазы будет делаться сайт.

Эксплуатационное назначение

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

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

Функциональное назначение

Какими средствами мы будем обеспечивать «эксплуатационное назначение»:

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

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

Наполнение сайта

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

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

Требования к хостингу

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

Минимальная подходящая конфигурация:

• Хостинг с дисковой квотой не менее 330 Мб
• Хостинг с PHP5 и установленным модулем apache Rewrite
• База данных MySQL версии 5 и выше с модулем InnoDB
• Наличие зарегистрированного и корректно настроенного домена

Почему 330Мб? Уточнил у программистов, сказали, что под этот проект им нужно 330. Каждому.

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

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

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

Но при всём при этом бэкапы никто не отменял.

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

Условия сдачи и приемки

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

Сайт должен нормально выглядеть и работать:

Сайт должен корректно отображаться и функционировать в следующих браузерах:

• Chrome 13
• FireFox 4
• Safari 5
• Opera 11
• Internet Explorer 8 и 9

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

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

Теперь, после шага 2, у нас есть следующее техзадание. Схема сайта с предыдущего шага никак не изменилась.

В тексте техзадания синей полосой отмечены сделанные описания.

На случай хабрэффекта тз на дропбоксе.

Ход конем

Писать всё техзадание целиком и сразу, лично для меня, слишком сложная задача. Я стараюсь делить задачу на мелкие подзадачи. На них проще сосредотачиваться и решать, и эти решения можно повторно использовать.

Работая над ТЗ в azalo.net, я использую «компоненты». Компоненты — это логически законченные части сайта, которые, как правило, могут быть использованы в разных проектах. Например, новости, блог и т.д. Это как у программистов сайтов плагин «Новости», плагин «Блог» и т.д.

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

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

• Общие положения
• Эксплуатационное назначение
• Функциональное назначение
• Наполнение сайта
• Требования к надежности
• Условия сдачи и приемки

Однако компонент, наравне с сайтом, имеет такие пункты как:

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

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

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

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

Итак, далее шаги 3, 4 и 5 относятся к компоненту «Бронирование».

Шаг 3. Функциональное описание; данные и списки

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

Заказчик нам сообщил, что бронирование должно происходить следующим образом:
Есть определенное кол-во номеров. Номера имеют разные типы (подешевле, поудобнее и удобные), в домиках по 2 или 4 номера, не обязательно одного типа. Клиент может выбрать период, когда он хочет отдохнуть, тип номера и кол-во номеров и сделать заявку. Заявка должна быть проверена, для этого менеджер связывается с клиентом, если клиент подтверждает заказ, номера бронируются. Далее некоторое время ожидается оплата от клиента, если оплата не пришла через N дней, менеджер снимает броню. Если оплата пришла, броня помечается как оплаченная.

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

Цены на отдых зависят от типа номера и периода. Летом одна цена, зимой другая.

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

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

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

Заявка на бронирование имеет 3 состояния:

• Не подтверждено
• Подтверждено
• Забронировано

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

Неподтвержденная заявка имеет период жизни, определяемый полем “Срок подтверждения заявки”. Если статус брони не был изменен со статуса “Не подтверждено”, то заявка должна быть автоматически удалена при достижении срока подтверждения заявки.

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

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

По функциональным характеристикам всё.

Анализ сущностей.

Из рассказов заказчика становится ясно, что у нас есть:

• Дома
• Номера в домах
• Типы (категории) номеров (простой, удобный, ...)
• Периоды времени (зима-лето)
• Цены, которые зависят от времени года и номера
• Брони

Эти сущности нам предстоит описать в 5-м разделе техзадания «Типы данных».

Номер

Начнем с номера. Номер — это комната в доме, из атрибутов имеет «номер», номер, в смысле название, идентификатор, например, «номер 205» и категорию.

Дом

По большому счету, это просто агрегатор номеров. Т.е. он имеет номера, и всё. Ни фотографий, ни этажности, ни координат расположения. Возможно название типа «Ветерок» или «Солнышко» или просто «Дом 2». Если же номер номера (извините за тавтологию, но иначе нужны новые термины, а этого не хотелось бы) однозначно определяет дом, например, номер «205» означает дом 2, комната 5, то и такого названия дому не нужно. Всё ясно из названия номера. Из беседы с заказчиком мы выяснили, что название у дома будет, и номера у номеров должны быть текстовой строкой, «на всякий случай».

Дома и номера — это сущности, связанные отношением один ко многим: один дом имеет несколько номеров.

Переменная «Номера» с типом «номера» как бы подчеркивает наличие отношение один-ко-многим.

Если на каком-то этапе у нас есть переменная, но мы еще не знаем или не понимаем её смысла, мы можем отметить её тип как «Неопределенный». Также это может пригодиться, если еще не создан тип «Номер», и его еще нет в списке типов данных:

Категория

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

Период

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

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

Цена

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

Броня

Пожалуй, самая обширная структура. Броня должна иметь:

• начало и конец действия (дата)
• желаемая категория номера (категория)
• количество номеров (целое число)
• имя заказчика, его телефон, email (строки)
• пожелание «все номера в одном доме» (логическое)
• примечание — текст оставляемый клиентом при оформлении брони (текст)
• статус заявки (целое число)
• крайний срок подтверждения заявки (дата)
• комментарий — примечание менеджера сайта (текст)
• номера — список номеров входящих в заявку (список номеров)

Списки

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

К этому моменту у нас хорошо пополнился раздел техзадания со структурами данных.

ТЗ на дропбоксе, на случай хабрэффекта.

Шаг 4. Структура компонента и описание страниц

В нашем ТЗ компонента «Бронирование» остался незаполненным раздел 7 «Страницы». Представить, какие страницы нам необходимы легче всего набросав схемку-структуру.

Публичная сторона бронирования будет невелика и включает страничку с отображением цен и страницы с бронированием и несколькими дочерними.

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

Редактирование таких «справочников» имеет типичный вид: список всех элементов сущности, переход к редактированию существующей сущности, создание новой и удаление существующей. Т.о. нам нужны на каждую сущность 3 страницы: список с возможностью удалить элемент(ы), страница для создания и для редактирования записи.

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

Доработанная схема:

Тут техническое задание, которое пополнилось пока пустыми разделами для описания страниц и схема сайта.

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

Шаг 5. Описание страниц

Подготовка к написанию текста для страниц сайта

Мы уже определились с тем, какие страницы и данные нужны для компонента «Бронирование».

Теперь сделаем хитрый ход, который в дальнейшем упростит нам описание текста страниц.

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

Это действие, кроме того, что подготавливает к созданию описания страниц, еще и позволяет заметить «бреши» в нашем ТЗ. Например, если мы видим «коробочку», не заполненную данными, это по крайней мере странно. Что это за страница такая, с которой не связаны никакие данные? Или может есть страница, но для неё забыли описать данные?

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

Описание страниц

Нам осталось выполнить последний шаг — описать все страницы, т.е. заполнить 7-й раздел ТЗ «Страницы». Шаг этот немаленький, но у нас есть средства для упрощения работы.

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

Когда «изюминка» сделана, на душе у исполнителя появляется ощущение, что работа сделана, а оставшаяся рутина — это мелочи. Главное позади.

Для нашего сайта «изюминкой» будет бронирование. И подробного описания заслуживает 3 страницы:

• Бронирование, страница клиента
• Карта заказов (админка)
• Редактирование заявки (админка)

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

_{По поводу эскизов. Для создания эскизов я использую Pencil Project. Не скажу, что это лучшая программа такого рода, но так вышло. Все дальнейшие эскизы сделаны с её помощью. Маленькая хитрость: когда я делаю компоненты, я обязательно сохраняю вместе с компонентом исходные файлы эскизов. Поэтому когда я делаю следующий сайт, перерисовать эскизы с учетом тонкостей нового проекта не составляет труда.}

А теперь текстовое пояснение:

Согласно принципу Парето, ключевые страницы-изюминки определяют 80% результата, требуя при этом 20% усилий. Дальше нас ждет 20% результата и 80% усилий: страницы-рутина.

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

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

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

Зеленой рамкой выделены слова которые были подставлены на основании тех данных, которые были связаны с данной страницей.

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

Отмечу, что вы можете писать свои кусочки текстов. Для текстов доступны переменные, которые заменяются на соответствующие значения.

У нас осталась страница с ценами, которую я упоминал раньше.

К редактированию цен можно было бы подойти по разному. Цены у нас связаны с периодами. Поэтому можно было бы на странице редактирования периода вывести список цен на этот период для разных категорий с возможностью редактирования.

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

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

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

И описание:

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

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

К данному моменту у нас готов компонент техзадания «Бронирование» и схема с эскизами всех страниц.

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

ТЗ на дропбоксе и там же схема компонента.

Шаг 6. Всё остальное

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

Для всего вышеперечисленного у нас есть компоненты с былых проектов, и мы просто пристыковываем их к нашему проекту.

И вот результат наших трудов: финальное техническое задание, и схема получившегося сайта.

На случай хабрэффекта ТЗ на дропбоксе и схема.

---

Буду рад отзывам и вопросам, «темным» местам, которые я мог пропустить. Постараюсь ответит на все возникшие вопросы.

_{На правах блога «Я пиарюсь». Ищу инвестора для развития сервиса и завоевания вселенной рынка техзаданий.}

Автор: stg34