Структура документа:
Глоссарий
Общие положения
2.1 Предмет разработки
2.2 Назначение документа
- Требования к графическому дизайну сайта
3.1 Требования к дизайну сайта
3.2 Порядок утверждения дизайн-концепции
- Функциональные требования
4.1 Классы пользователей
4.2 Требования к представлению сайта
4.3 Требования к системе управления сайтом
4.4 Требования к разделению доступа
- Требования к видам обеспечения
5.1 Требования к информационному обеспечению
5.2 Требования к программному обеспечению
5.3 Требования к техническому обеспечению
5.4 Требования к лингвистическому обеспечению
5.5 Требования к эргономике и технической эстетике
- Требования к приемке-сдаче проекта
6.1 Требования к наполнению информацией
6.2 Требования к персоналу
6.3 Порядок предоставления дистрибутива
6.4 Порядок переноса сайта на технические средства заказчика
- Глоссарий
| Термин | Описание |
| Сайт | Информационная система, предоставляющая пользователям сети
Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц
|
| Мобильное приложение | Мобильное приложение – это специально разработанное приложение под конкретную мобильную платформу (iOS, Android, Windows Phone). |
| Нативное мобильное приложение | Приложение можно назвать «родным» для операционных систем – Android, IOS, WinPhone . Такие мобильные приложения пишутся на языках программирования, утвержденных разработчиками программного обеспечения под каждую конкретную платформу, а потому органично встраиваются в сами операционные системы. Приложения загружаются через магазины приложений (App Store, Google Play и т.д.) и соответствуют требованиям этих магазинов. |
| Администратор | Лицо, осуществляющее от имени Заказчика информационную поддержку сайта |
| Дизайн веб-сайта | Уникальные для конкретного веб-сайта структура, графическое
оформление и способы представления информации
|
- Общие положения
2.1 Предмет разработки
Рис. Use case
Предметом разработки является
- мобильное приложение с автоматическим наполнением контента;
- Сайт;
Назначение мобильного приложения:
- Предоставление полной информации о местах курортной зоны;
- Возможность осуществлять бронирование развлечений (экскурсий, снаряжения и тд);
- Возможность осуществлять бронирование проживание (тур, отели, дома отдыха, курорты и тд);
- Возможность осуществлять бронирование транспорта (авиа билетов, жд билетов, такси, автобусов);
- Возможность осуществлять бронирование питания (столик в ресторане, вызов кейтеринг и тд);
Назначение сайта
— Вывод рекламной информации о мобильном приложении;
— Осуществление администрирование мобильного приложения;
— Вывод аналитической информации (с возможностью отправить на принтер и на почтовый адрес);
Цель создания мобильного приложения:
— Агрегирование сервисов курортной зоны России в одной месте;
— Возможность бронирования путешествий «в один клик»;
— Обмен сообщениями и отзывами между пользователями;
Целевая аудитория сайта:
— Семейные пары (средний возраст которых родителей 30-35 лет) с маленькими детьми, которые планируют провести отдых на курортных зонах России (Сочи, Крым и тд);
— Молодежь (от 18 до 30 лет), которая планирует отправиться на зимние курортные зоны (Красная поляна, Кавказ и тд.);
— Активные люди, которые любят путешествовать по России и сами планируют свой отпуск;
2.2 Назначение документа
В настоящем документе приводится полный набор требований к реализации мобильного приложения и сайта.
Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:
- Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
- Заказчик согласен со всеми положениями настоящего Технического Задания.
- Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
- Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
- Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
- Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами.
- В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.
- Требования к графическому дизайну сайта
3.1 Требования к дизайну сайта
При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ).
Оформление должно быть разработано в достаточно консервативном ключе.
На страницах недолжно быть большого объема текста.
В дизайне сайта не должны присутствовать:
— мелькающие баннеры;
— много сливающегося текста;
— тёмные и агрессивные цветовые сочетания и графические решения.
Рис. Пример формы авторизации
3.2 Порядок утверждения дизайн-концепции
Под дизайн-концепцией понимается вариант оформления главной страницы и графическая оболочка внутренних страниц, демонстрирующие общее визуальное (композиционное, цветовое, шрифтовое, навигационное) решение основных страниц сайта. Дизайн-концепция представляется в виде файла (нескольких файлов) в растровом формате или в распечатке по согласованию сторон.
Если представленная Исполнителем дизайн-концепция удовлетворяет Заказчика, он должен утвердить ее в течение пяти рабочих дней с момента представления. При этом он может направить Исполнителю список частных доработок, не затрагивающих общую структуру страниц и их стилевое решение. Указанные доработки производятся параллельно с разработкой программных модулей сайта. Внесение изменений в дизайн-концепцию после ее приемки допускается только по дополнительному соглашению сторон. Если представленная концепция не удовлетворяет требованиям Заказчика, последний предоставляет мотивированный отказ от принятия концепции с указанием деталей, которые послужили препятствием для принятия концепции и более четкой формулировкой требований.
В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции (дорабатывает, вносит изменения). Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней. Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений.
- Функциональные требования
4.1 Классы пользователей
- Гость – неавторизованный пользователь, обладает правами:
- Регистрация в мобильном приложении;
- Авторизация: ввод аутентификационных данных;
- Авторизованный пользователь обладает правами:
- Статические разделы – просмотр;
- Разделы новостей – просмотр;
- Новости – просмотр;
- Раздел бронирование билетов – просмотр;
- Раздел бронирования развлечений – просмотр;
- Раздел бронирования путевок – просмотр;
- Раздел бронирования транспорта – просмотр;
- Видеоролики, фотографии – просмотр, добавление отзыва, редактирование собственного отзыва
- Обратная связь – создание письма
- Сообщение в техподдержку – создание заявки
- Комментарии к разделам и подразделам– просмотр, добавление собственных, редактирование собственных
- Подписка на рассылки и уведомления
- Личный кабинет:
- Информация о пользователе – просмотр, редактирование собственной информации
- Статистика писем– просмотр собственных писем
- Список рассылок и уведомлений – просмотр, редактирование, удаление
3) Администратор – пользователь, авторизованный в интерфейсе сайта
- Полный доступ ко всем функциональным возможностям администрирования мобильного приложения:
- Статические разделы — просмотр, добавление, редактирование, удаление
- Разделы новостей — просмотр, добавление, редактирование, удаление
- Новости – просмотр, добавление, редактирование, удаление
- Статьи – просмотр, добавление, редактирование, удаление
- Разделы– просмотр, добавление, редактирование, удаление
- Видеоролики, фотографии – просмотр, добавление, редактирование, удаление
- Личные данные пользователей – просмотр, редактирование
- Список рассылок и уведомлений – просмотр, добавление, редактирование, удаление
- Комментарии к фотографиям, видеороликам, текстам– просмотр, редактирование, удаление
- Группы пользователей – просмотр, добавление, редактирование, удаление
- Пользователь — просмотр, добавление, редактирование, удаление, раздача прав
- Статистика – просмотр
4.2 Требования к представлению мобильного приложения
Требования к представлению главной страницы мобильного приложения.
Главная страница мобильного приложения должна содержать графическую часть, навигационное меню сайта (у пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.), а также контентную область для того, чтобы посетитель мобильного приложения с первой страницы мог получить вводную информацию об актуальных развлечениях, транспорте, питании и путевки, а также ознакомиться с последними новостями.
В нижней части экрана должно располагаться горизонтальное меню и включать разделы: Транспорт, Питание, Развлечение, Проживание.
Контентная часть главной странице мобильного приложения должна включать:
- В верхней части должен присутствовать поиск по всем страницам мобильного приложения
- Слайдер на всю ширину экрана, которые будет включать картинки
- Вкладки: транспорт, развлечение, питание, путевки, новости, фото-видео галерея, форум.
- Недавно просмотренные вкладки;
- Самые популярные направления
Требования к отображению раздела «проживание».
При переходе пользователя на раздел «проживание» пользователю в верхней части экрана
- должен присутствовать поиск (в котором пользователь может задать город, в который он хочет поехать);
- ниже должна быть возможность выбрать дата заезда и дату отъезда;
- рядом должна быть опция выбора количества взрослых, количества номеров и количества детей;
- Разделы с отелями, хостелами, домами, гостиницами;
- Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звездочек, отзывы, соотношение цены и качества, спецпредложение;
- С правой стороны должна отображаться цена, агент (который предоставил информацию, и кнопка посмотреть).
Требования к внутренним страницам раздела проживание.
- стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
- во всю ширину должен располагаться слайдер с фотографиями данного места, справой стороны должна располагаться кнопка поделиться и сохранить в закладки.
- название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте)
- Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).
Требования к отображению раздела «развлечения».
При переходе пользователя на раздел «развлечения» пользователю
- в верхней части экрана должен отображаться поиск (в котором пользователь может задать развлечение, которое он хочет выбрать)
- Должны присутствовать разделы с самыми лучшими развлечениями, раздел с индивидуальными экскурсиями, раздел с общими экскурсиями, раздел с пешими экскурсиями, раздел с экстремальными экскурсиями.
- Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звезд, отзывы, соотношение цены и качества, спецпредложение;
Требования к внутренним страницам раздела «развлечения».
- стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
- во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
- название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте);
- Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).
Требования к разрабатываемому разделу «транспорт»
- Должны присутствовать разделы-выборы авиа-билеты, жд билеты, вызов такси, аренда автобуса;
- В разделе авиабилеты должен быть календарь с выбором дата отчета и прилета, пунктом отправления и пунктом назначения, класс
- В разделе авто должны присутствовать выбор тип авто: эконом, «люкс», «комфорт»
Требования к разрабатываемому разделу «питание»
- Вызов питания на дом
- Заказ столика в ресторане
Требования к внутренним страницам раздела «питание».
- стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
- во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
- название места, количество звездочек, количество отзывов,
- ниже должна быть написана цена.
Требования к внутренним страницам раздела «личный кабинет».
- После регистрации пользователя у него создается личный кабинет.
- У пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.
- Личный кабинет пользователя находится в боковой части экрана. Там должна быть возможность выбрать фотографию пользователю, выбрать перейти в раздел редактирования личного кабинете. Добавления данных кредитной карты, добавления информации, включения галочки пуш уведовлений.
- К личному кабинету прикрепляется мониторинг действий (возможно гугл метрика).
- На основании активности пользователя формируется релевантные предложения
Требования к странице «оплата».
Оплата путевки, тура, экскурсии, снаряжения и тд.
- После добавления элемента (путевки и тд) в корзину, пользователю выводится сообщения о том, хочет ли он продолжить покупку чего-нибудь еще и перейти на оплату.
- После перехода пользователю на вкладку оплаты, если у него не введены данные карты, то ему предлагается вести данные карты (Номер, код, владелец). После введения этих данных пользователь переходит на страницу подтверждения оплаты
- На странице подтверждения оплаты ему выводится список того, что он выбрал, стоимость заказы, налог на данную услугу, комиссия, если она есть, и итоговая стоимость и кнопка оплатить.
- После нажатия на кнопку оплатить. Клиенту выводится сообщение, что его заказ принят и обрабатывается. Если у клиента недостаточно денег, то ему выводится сообщение, о том, что у него недостаточно денег и предлагается ему вести другой номер карты или повторить попытку снова.
- После успешной транзакции на почту клиента приходит чек о совершенной операции.
- Оплата услуг должна производиться с помощью стороннего сервиса — Payonline.
- После оплаты пользователю должно вернуться 6% кеш бека со следующей покупки.
- Передача данных производится внутри приложения с помощь REST или JSON технологии.
Оплата авиа, жд билетов.
- Оплата билетов происходит с помощью iframe, который выводится после нажатия на кнопку оплатить.
- В iframe передаются параметры: фамилия, имя, отчество, данные кредитной карты.
- После оплаты возвращается callback в мобильное приложение.
Требования к структуре сайта
- Сайт создается с целью внесения в ручном режиме информации на сайт.
- Для выгрузки отчетности
Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.
Авторизация
Пользователи могут авторизоваться в мобильном приложении, в форме авторизации должны присутствовать:
- Текстовое поле для ввода логина пользователя
- Кнопка отправки формы.
Данные для доступа (авторизации):
- Логин – адрес электронной почты пользователя
- Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.
Ниже формы располагаются ссылка:
- Забыли пароль
Форма «Забыли пароль» содержит поля:
- Email адрес пользователя, указанный при регистрации
При неудачной попытке авторизации – появляется приглашение для повторной попытки
авторизоваться с формой авторизации.
Списки рассылок и уведомления
Авторизованные пользователи могут управлять своими списками рассылок, а также
просматривать полученные уведомления.
Функциональные требования:
Администратор
- Добавить рассылку
- Удаление рассылку
- Редактирование рассылку
Авторизованный пользователь
- Просмотреть список рассылок
- Подписаться на список рассылок
- Отписать от списка рассылок
- Просмотреть уведомления
4.4 Требования к разделению доступа
После прохождения аутентификации сайт или мобильное приложение должно проверять полномочия пользователя на доступ к запрошенному разделу. Если доступ запрещен, пользователю должно быть выведено сообщение о невозможности доступа в закрытый раздел.
Комментарии к статьям и разделам могут оставлять только зарегистрированные пользователи.
- Требования к видам обеспечения
5.1 Требования к информационному обеспечению
Требования к хранению данных
Все данные сайта должны храниться в структурированном виде под управлением реляционной
СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания
(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД
размещаются ссылки на них.
Наполнение различных сайтов, функционирование которых поддерживается одной и той же
инсталляцией системы, должно храниться под управлением единой СУБД.
Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.
Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).
Для реализации интерактивных элементов клиентской части должны использоваться языки
JavaScript и DHTML.
Для реализации динамических страниц должен использоваться язык PHP.
Для разработки мобильного приложения должен быть использован ReactJS
Требования к организации гиперссылок
Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).
Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть
выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
Требования к объему одной страницы
Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.
5.2 Требования к программному обеспечению
Серверная часть:
- Операционная система семейства Unix (Linux, FreeBSD и пр.)
- Веб-сервер Apache 1.3.18 и выше
- Nginx, модуль mod_accel для Apache
- Набор библиотек и утилит ffmpeg
- PHP 4.2.0 и выше (должен быть собран как модуль Apache)
- СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
- Модули PHP: Mcrypt, FTP, ffmpeg-php
- Библиотеки PHP: Smarty, GeoIP
- Возможность доступа к localhost по FTP протоколу
- 2 пользователя БД
Желательно, чтобы PHP не был запущен в SafeMode.
Клиентская часть:
- Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
- Internet Explorer 6
- Mozilla 1.6 (Firefox 1.0)
- Opera 9
- Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
- расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и
5.3 Требования к техническому обеспечению
Серверная часть:
- Компьютер с процессором Xeon 4 ядерный
- 2 ГГц (рекомендуется от 3 ГГц)
- Оперативная память 4 Гб
- Место на жестком диске от 1 Гб
Точные технически характеристики сервера будут уточнены после завершения системы и
обширного тестирования всех модулей
Клиентская часть:
- Компьютер с процессором i3 ГГц (рекомендуется от 1.5ГГц)
- Оперативная память 256 Мб (рекомендуется от 512 Мб)
5.4 Требования к лингвистическому обеспечению
Сайт должен выполняться на русском языке.
5.5 Требования к эргономике и технической эстетике
Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.
- Требования к приемке-сдаче проекта
6.1 Требования к наполнению информацией
Общие требования к информационному наполнению
Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.
6.3 Требования к персоналу
Для эксплуатации веб-интерфейса сайта от администратора не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и стандартным веб-браузером (например, MS IE 6.0 или выше).
Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word.
Прочие пользователи: уверенный пользователь сети Интернет.
6.4 Порядок предоставления дистрибутива
По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в
составе:
— архив с исходными кодами всех программных модулей и разделов сайта;
— дамп проектной базы данных с актуальной информацией.
Дистрибутив предоставляется на CD-диске в виде файлового архива.
6.5 Порядок переноса сайта на технические средства заказчика
После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем
производится однократный перенос разработанного программного обеспечения в apple store, google market .
Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и
доступ к базе данных сайта.
6.6 Дополнительные требования
Требования к производительности
Работа любого скрипта не должна превышать 60 секунд.
При условии нагрузки на сервер не более
500.000 обращений к страницам портала в сутки.
Требования к безопасности
Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-
код скриптов. Требуется разграничение доступа.
Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен.
На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.
Требования к надежности
Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет
хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить
копию сайта
