Поиск и бронирование учебных заведений в России и по всему миру!
Совет-Образования.РФ - Российский стартап проект (бета-тестирование).

Техническое задание проекта EducationAdvisor.Ru
ООО «Викитревел» ООО «Британские-Товары»
Заказчик www.BritishSouvenirs.Ru Британские-Товары.РФ, www.vikitravel.ru,, Викитревел.РФ |
|
Исполнитель Совет-Москвы.РФ www. Moscow-Advosor.Ru |
|||
|
|
|
|||
|
|
|
|||
/VikiTravel.Ru / |
|
|
/MoscowAdvisor.Com/ |
|
|
|
(подпись) |
|
|
(подпись) |
|
М.П. |
|
М.П.
|
Техническое задание проекта EducationAdvisor.Ru в pdf
Термины и определения
Термин |
Определение |
ВУЗ |
Высшее учебное заведение Совет-Образования.РФ www.советобразования.рф |
Заказчик |
ООО «Викитревел» ООО «Британские-Товары» www.британскиетовары.рф |
Исполнитель |
MoscowAdvisor.Com, Совет-Москвы.РФ |
Контент |
Контент (также: наполнение или содержимое) — термин, означающий все виды информации (как текстовой, так и мультимедийной — изображения, аудио, видео и т.п.), составляющей визуализированное для посетителя содержимое сайта. |
Модерация |
Посредническая деятельность по администрированию содержимого сайта, наполняемого пользователями сайта: проверка и одобрение публикации информации, внесённой пользователем. |
ОУ |
Образовательное учреждение |
Сайт |
Разрабатываемый веб-сайт |
СМИ |
Средства массовой информации |
ТЗ |
Техническое задание |
УТП |
Уникальное торговое предложение |
ЦА |
Целевая аудитория |
CMS |
Система управления содержимым (контентом) (англ. Content management system) — информационная система или компьютерная программа, используемая для обеспечения и организации совместного процесса создания, редактирования и управления содержимым сайта. В рамках настоящего ТЗ CMS – это программный продукт 1С-Битрикс в редакции «Стандарт». |
URL |
Единый указатель ресурсов (англ. Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. Служит стандартизированным способом записи адреса ресурса в сети Интернет. |
Оглавление
1.1. Полное наименование сайта и его условное обозначение
1.4. Порядок оформления и предъявления заказчику результатов работ по созданию системы
1.5. Краткие сведения об объекте автоматизации
1.6.1. Общая информация о документе
1.6.2. Чтение дополнительных требований
2.1. Требования к структуре и функционированию сайта
2.4. Требования пользовательским интерфейсам
2.5. Требования по сохранности информации
2.6. Требования к патентной чистоте
2.7. Требования по стандартизации и унификации
2.8. Взаимодействие с социальными сетями
2.9.1. Общие требования к специальным страницам
2.9.4. Перенаправление в личный кабинет
2.9.8. Повторный ввод нового пароля
2.9.9. Учётная запись не активирована
2.9.11. Смена адрес электронной почты
2.10.1. Общие требования к информационным письмам
2.10.2. Инструкции по активации учётной записи
2.10.4. Уведомление о размещении отзыва
3. Требования к функциям сайта
3.1.1. Общие требования к пользователям
3.4. Авторизация и регистрация
3.4.3. Активация учётной записи
3.5.8. Изменить адрес электронной почты
3.7. Образовательные учреждения
3.7.1. Основная страница раздела
3.7.5. Импорт сведений об ОУ из Excel файла
3.11. Часто задаваемые вопросы
4. Требования к обеспечению сайта
4.1. Требования к информационному обеспечению сайта
4.2. Требования к лингвистическому обеспечению сайта
4.3. Требования к программному обеспечению сайта
4.4. Требования к аппаратному обеспечению сайта
5. Подготовка сайта к вводу в действие
1. Общие положения
1.1. Полное наименование сайта и его условное обозначение
Полное наименование сайта: Информационный портал Educationadvisor.ru
Краткое наименование сайта: Educationadvisor.ru
1.2. Назначение сайта
Сайт будет предназначен для создания виртуального сообщества людей, планирующих своё образование, работающих в сфере образования.
1.3. Цели создания сайта
Создание уникального информационного ресурса, содержащего постоянно обновляемую информацию об ОУ со всего мира.
Для реализации поставленных целей сайт должен обеспечить автоматизацию следующих задач:
· Ведение единой базы данных ОУ
· Управление статическим и динамическим содержимым сайта
· Администрирование пользователей и прав доступа
· Модерация информации, вводимой пользователями
1.4. Порядок оформления и предъявления заказчику результатов работ по созданию системы
Система передается в виде функционирующего комплекса из исходных кодов, скриптов, базы данных, установленных на аппаратных средствах, предоставленных Заказчиком (см. раздел 4.4).
Порядок предъявления системы, ее испытаний и окончательной приемки определен в п. 6 настоящего ТЗ.
1.5. Краткие сведения об объекте автоматизации
Объектом автоматизации являются процессы общения пользователей в виртуальном пространстве сайта, процедуры модерации содержимого сайта и процедуры администрирования прав доступа.
1.6. Прочие положения
1.6.1. Общая информация о документе
Настоящий документ создан на основе концепции проекта и устанавливает требования к разрабатываемому сайту.
Требования настоящего ТЗ не устанавливают плановые сроки создания сайта.
Содержимое проекта ограничено требованиями настоящего ТЗ и концепции проекта, на основании которой написано настоящее ТЗ. При написании настоящего ТЗ подразумевается, что не существует каких-либо нормативно-правовых документов, расширяющих или ограничивающих требования, приведённые в настоящем ТЗ.
При упоминании в настоящем ТЗ требований о выводе сообщений, уведомлений или иной информации, а также при отображении любых элементов и программировании характера их поведения в зависимости от событий, следует руководствоваться макетами дизайна или предоставленными статичными шаблонами страницы, если в ТЗ не указано иное.
1.6.2. Чтение дополнительных требований
По тексту настоящего ТЗ можно встретить таблицы вида:
Расширенные требования |
|
Номер |
Требование |
REQ-NAME-ХХ-ХХХХХ |
Текст с описанием требования |
Где:
· REQ – обязательная часть нумерации, обозначающая дополнительное требование. Является постоянным значением.
· NAME – обязательная часть нумерации, обозначающая тему требования. Является задаваемым значением.
· ХХ – старший код требования. Служит для группировки требований в контексте темы требования. Является уникальным цифровым значением в контексте темы. Старшие разряды значения при отсутствии цифр заполняются нулями (пример, 01, 02, 03 и т.д.).
· ХХХХХ – младший код требования. Служит для нумерации требования. Является уникальным цифровым значением в контексте старшего кода требования. Старшие разряды значения при отсутствии цифр заполняются нулями (пример, 00001, 02, 03 и т.д.).
Данная система описания дополнительных требований служит для декомпозиции требований и удобства их ведения в системах учёта задач/ошибок.
Требования следует читать в иерархии, т.е. если указана ссылка на REQ-PAGE, то это означает, что следует соблюсти все требования, входящие в раздел REQ-PAGE.
1.6.3. Макросы
Макрос – есть сущность, которая должна заменяться соответствующим значением, указанным в описании макросы. При описании макросов будут предложены имена. Допускается выбрать своё наименование макроса, но формат макроса должен быть идентичен остальным макросам, используемым на сайтах.
2. Общие требования к сайту
2.1. Требования к структуре и функционированию сайта
Сайт реализуется на базе продукта 1С-Битрикс: Управление сайтом (редакция «Стандарт»).
В состав сайта входят следующие разделы:
· Регистрация
· Личный кабинет
· О сайте
· Поиск
· Рейтинги
· Форум
· Блоги
· Новости
· Часто задаваемые вопросы
· Правила работы с сайтом
· Опросы
· Интервью
· Экспертное мнение
· Партнерам
· Реклама
· Знаменитые люди
Сайт должен функционировать в режиме 24/7[1]. Любые процедуры, выполняемые на сайте не должны приводить к отказу функционала сайта.
На сайте в период опытной эксплуатации должны работать все средства по диагностике, доступные как на уровне веб-сервера, так и на прикладном уровне CMS 1С-Битрикс.
2.2. Показатели назначения
Показатели назначения могут и должны достигаться при оптимальном использовании как программных (функционал, ОС, веб-сервер и т.п.), так и аппаратных средств (серверы, маршрутизаторы и т.п.) сайта.
Время ответа на запрос при одновременном подключении до 1000 пользователей (1000 одновременных запросов) должно составлять не более 5 секунд.
Сайт должен поддерживать хранение и отображение[2] структур данных с объёмом до 2 млн. записей.
2.3. Требования к надежности
Надежность сайта определяется его доступностью и работой функционала в соответствии с требованиями настоящего ТЗ. Надежность сайт должна быть обеспечена оптимальным использованием программных и аппаратных средств.
Сайт должен быть доступен круглосуточно в сети Интернет.
Сбои в серверном обеспечении (выключение, аварийная перезагрузка сервера) не должны влиять на работоспособность сайта после восстановления работы серверного обеспечения.
2.4. Требования пользовательским интерфейсам
Взаимодействие пользователей с сайтом должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы (использование масок ввода, соблюдения последовательности переходов по Tab, автоматическое обновление связанных данных). Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование «мыши», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. П. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании полей экранных форм.
Все тексты сайта должны быть на русском языке, если иное не определяется в настоящем ТЗ или не является контентом, который заполняется пользователем.
Сайт должен обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна выдавать пользователю соответствующие сообщения.
Экранные формы должны проектироваться с учетом требований унификации:
· все экранные формы сайта должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
· для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
· внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.
Функционал сайта также должен корректно обрабатывать нажатие кнопки «Назад» в браузере.
2.5. Требования по сохранности информации
Не допускается частичное изменение или удаление данных в БД при выполнении массовых изменений в БД, т.е. все последовательные запросы, модифицирующие данные, должны выполнять в транзакциях и предусматривать процедуру автоматического отката. Транзакции в момент их исполнения должны позволять осуществлять read-only доступ к данным, которые были до начала транзакции.
При сбое транзакция должна быть отменена (данные не модифицируются).
2.6. Требования к патентной чистоте
Установка сайта в целом, как и установка отдельных частей сайта не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей, кроме программного обеспечения, указанного в разделе 4.3.
2.7. Требования по стандартизации и унификации
При создании макетов и шаблонов страниц, а также при программировании сайта необходимо использовать типы данных, приведённые в данном разделе (см. Таблица 1).
Таблица 1. Типы данных
Тип данных |
Интерпретация на форме |
Дополнительные требования |
Строка |
Текстовое поле в одну строку |
- |
Да/нет |
Чек-бокс |
- |
Дата |
Текстовое поле с одну строку с маской ввода |
- При заполнении поля с типом «Дата» данные должны конвертироваться в формат ДД.ММ.ГГГГ, где ДД – это день в 2-хзначном формате (недостающие символы слева дополняются нулями), ММ – это месяц в 2-хзначном формате (недостающие символы слева дополняются нулями), ГГГГ – это год в 4-хзначном формате - Если фокус в поле типа «Дата», нажатие кнопки «Tab» приводит к переходу следующем порядке (с ДД на ММ, с ММ на ГГГГ, с ГГГГ на следующее поле для ввода данных). При этом все цифры в разделе даты, на который осуществлён переход, должны выделяться. - Рядом с полем типа «Дата» всегда должна присутствовать ссылка на календарь, позволяющий выбрать дату. - Дата должна сохраняться со временем (формат отображения даты на сайте, если не указано иное, остаётся ДД.ММ.ГГГГ) |
Пароль |
Текстовое поле в одну строку |
- Экранируется специальными символами в соответствии с дизайном сайта |
|
Текстовое поле в одну строку |
- При заполнении поля «E-mail» должна проводиться проверка на его соответствие формату e-mail адресов в доменах любого уровня. - Если по результатам проверки выявлено, что e-mail не соответствует формату, необходимо под полем выводить сообщение «Некорректный адрес электронной почты». |
Телефон |
Сочетание двух текстовых полей в одну строку, расположенных на одной линии |
- Всегда идёт с полем «Код» - Поле «Код» всегда сопровождается символом «+» перед ним. - При заполнении поля «Телефон» и поля «Код» допускается ввод только цифр. - При заполнении поля «Телефон» данные должны конвертироваться в формат (ХХХ)_ХХХ-ХХ-ХХ, где «Х» – это вносимый символ, «_» – это пробел. |
Текст |
Многострочное текстовое поле |
- «Мемо» для ввода простого текста |
Список (текст) |
Собственный шаблон |
- Список всегда связан со справочником и может содержать несколько значений из него (при этом в БД сохраняется ссылка на идентификатор, но на сайте отображаются значения указанного поля из справочника) - Список на форме представляет собой сочетание наименования, текстового поля в одну строку, пиктограммы рядом с ним, предназначенных для добавления новых значений, и кнопки «Добавить» а также самого списка, содержащего добавленные значения, и кнопки «Удалить» - Текстовое поле должно «на лету»[3] обрабатывать вводимые в него значения и предлагать до первых 5 релевантных значений, найденные в справочнике с учётом приоритета (сортировки) этих значений в справочнике (по аналогии с поиском в Google или Яндекс) - Пользователь должен иметь возможность выбрать предлагаемое значение и добавить его в список - При нажатии на пиктограмму должно появляться модальное окно, в котором пользователю должна быть предоставлена возможность найти нужное значение, отфильтровав значения в справочнике, введя данные в соответствующие поля - При открытии модального окна необходимо учитывать значение, введённое в текстовом поле, и заранее фильтровать список значений из справочника - В модальном окне необходимо отображать все поля справочника (таблица/grid с поддержкой постраничного вывода до 20 сообщений на страницу и с поддержкой сортировки по любому из полей) - Пользователь должен иметь возможность в модальном окне выбрать любой из доступных элементов справочника и добавить его в список, нажав соответствующую кнопку, или двойным щелчком по левой кнопке мыши - По нажатию Enter в текстовом поле или кнопки «Добавить» должно подставляться значение, найденное в справочнике - Если текстовое поле содержит значение, которого нет в справочнике, то такое значение не должно добавляться - Пользователь должен иметь возможность выбрать любой элемент в списке и удалить его, нажав Delete или кнопку «Удалить» - Все элементы управления должны корректно обрабатывать возможные ошибки пользователя (попытку добавить пустое значение, попытку удалить элементы из списка при их отсутствии и т.д.) |
Список (значение) |
|
- Список всегда связан со справочником и может содержать несколько значений из него (при этом в БД сохраняется ссылка на идентификатор, но на сайте отображаются значения указанного поля из справочника) - Список на форме представляет собой сочетание наименования, выпадающего списка, содержащего элементы справочника, кнопки «Добавить» а также самого списка, содержащего добавленные значения, и кнопки «Удалить» - По нажатию кнопки «Добавить» должно подставляться значение, выбранное в выпадающем списке - Пользователь должен иметь возможность выбрать любой элемент в списке и удалить его, нажав Delete или кнопку «Удалить» - Все элементы управления должны корректно обрабатывать возможные ошибки пользователя (попытку добавить пустое значение, попытку удалить элементы из списка при их отсутствии и т.д.) |
Справочник (текст) |
Текстовое поле в одну строку |
- Справочник на форме представляет собой сочетание наименования, текстового поля в одну строку и пиктограммы рядом с ним - Текстовое поле должно «на лету»[4] обрабатывать вводимые в него значения и предлагать до первых 5 релевантных значений, найденные в справочнике с учётом приоритета (сортировки) этих значений в справочнике (по аналогии с поиском в Google или Яндекс) - Пользователь должен иметь возможность выбрать предлагаемое значение - При нажатии на пиктограмму должно появляться модальное окно, в котором пользователю должна быть предоставлена возможность найти нужное значение, отфильтровав значения в справочнике, введя данные в соответствующие поля - При открытии модального окна необходимо учитывать значение, введённое в текстовом поле, и заранее фильтровать список значений из справочника - В модальном окне необходимо отображать все поля справочника (таблица/grid с поддержкой постраничного вывода до 20 сообщений на страницу и с поддержкой сортировки по любому из полей) - Пользователь должен иметь возможность в модальном окне выбрать любой из доступных элементов справочника и выбрать его, нажав соответствующую кнопку, или двойным щелчком по левой кнопке мыши - Если текстовое поле содержит значение, которого нет в справочнике, то такое значение не должно сохраняться (при этом пользователю необходимо вывести соответствующее сообщение) - Все элементы управления должны корректно обрабатывать попытку сохранить пустое или отсутствующее значение |
Справочник (значение) |
Значение из выпадающего списка |
- Справочник на форме представляет собой сочетание наименования, выпадающего списка, содержащего элементы справочника |
Кнопка |
Кнопка |
- Кнопка может быть заменена изображением, если это явно указано в описании поля в настоящем ТЗ |
WYSWIG |
Визуальный редактор CMS |
- |
Число |
Текстовое поле в одну строку |
- Поле должно поддерживать ввод только цифр |
Дробное число |
Текстовое поле в одну строку |
- Поле должно поддерживать ввод только цифр и знака точка «.» |
Отправка форм происходит посредством нажатия соответствующей кнопки
(указывается в описании формы) или нажатия Enter в соответствующих полях (указываются в описании формы).
Перед отправкой формы должна происходить обязательная проверка на предмет
заполнения обязательных полей. Если результат проверки на заполнение
обязательных полей отрицательный, то под каждым незаполненным полем должно
выводиться сообщение «Поле обязательно для заполнения». Фокус и экран должны
установиться на самом верхнем незаполненном поле. Если результат проверки положительный
(и отсутствуют любые другие проверки), то происходит отправка и последующая
обработка формы на сервере.
2.8. Взаимодействие с социальными сетями
Любое взаимодействие с профилями в социальных сетях, если это указано в требованиях настоящего ТЗ, должно сопровождаться обращением к API соответствующей сети и получением подтверждения о существовании пользователя.
Если Профиль получить не удаётся, нельзя сохранять данные о социальной сети.
2.9. Специальные страницы
2.9.1. Общие требования к специальным страницам
Специальные страницы предназначены для вывода информационных сообщений, сопровождающих выполнение функций сайта.
Специальные страницы должны редактироваться в CMS с использованием визуального редактора и поддерживать макросы.
2.9.2. Ошибка авторизации
Макрос |
Предлагаемое наименование |
Значение |
Форма авторизации |
#AUTHORIZATION_FORM# |
Форма авторизации. На форме авторизации должны быть заполнены значения полей «Имя пользователя» и «Запомнить», полученных при обработке формы. Отправка формы вызывает её обработку. |
2.9.3. Завершение регистрации
Макрос |
Предлагаемое наименование |
Значение |
Ссылка для повторной отправки письма |
#SEND_ACTIVATION_LINK# |
Ссылка для вызова функции отправки письма «Инструкции по активации учётной записи» (см. раздел 2.10.2). |
Например, страница с сообщением «Благодарим Вас за регистрацию. На
указанный Вами адрес электронной почты выслано письмо с инструкцией по
активации учетной записи» и ссылкой «Выслать письмо повторно».
При нажатии ссылки «Выслать письмо повторно» происходит повторная отправка письма с инструкцией по активации учётной записи.
2.9.4. Перенаправление в личный кабинет
Макрос |
Предлагаемое наименование |
Значение |
Ссылка |
# LINK# |
Ссылка, по которой в течение 5 секунд после загрузки страницы должно произойти перенаправление. |
Например, страница с сообщением «Активация Вашей учётной записи
произведена. Сейчас вы будете перенаправлены в Личный кабинет. Если этого не
произошло, нажмите на ссылку».
Через 5 секунд после загрузки пользователь перенаправляется в Личный кабинет.
2.9.5. Повторная активация
Страница не содержит макросов.
2.9.6. Восстановление пароля
Макрос |
Предлагаемое наименование |
Значение |
Форма для ввода электронного адреса |
#EMAIL_FORM# |
См. Таблица 2 |
Сообщение |
#MESSAGE# |
Произвольное текстовое сообщение, заданное пользователем. Не выводится, если параметры формы не передавались на сервер. |
Таблица 2. Форма для ввода электронного адреса
Наименование поля |
Обязательно к заполнению |
Тип поля |
Текстовая подсказка |
Описание |
Введите Ваш адрес электронной почты |
Да |
Пароль |
|
Отправляет форму по Enter |
Восстановить пароль |
|
Кнопка |
|
Кнопка для отправки формы |
Обработка
формы для восстановления пароля
Если пользователь указал адрес электронной почты, который отсутствует в БД пользователей, необходимо повторно вывести данную специальную страницу повторно (макрос «Сообщение» отображается).
Если пользователь указал адрес электронной почты, который присутствует в БД пользователей, необходимо выслать на данный адрес электронной почты письмо «Ввод нового пароля» (см. раздел 2.10.3).
2.9.7. Ввод нового пароля
Макрос |
Предлагаемое наименование |
Значение |
Форма для ввода нового пароля |
#NEW_PASSWORD_FORM# |
См. Таблица 3. |
Сообщение |
#MESSAGE# |
Произвольное текстовое сообщение, заданное пользователем. Не выводится, если параметры формы не передавались на сервер. |
Таблица 3. Список полей на форме для ввода
пароля
Наименование поля |
Обязательно к заполнению |
Тип поля |
Описание |
Пароль |
Да |
Пароль |
Сохраняется в пароль пользователя (см. Таблица 4). |
Подтверждение пароля |
Да |
Пароль |
При заполнении данного поля должна проводиться проверка на соответствие его значения со значением поля «Пароль». Если по результатам проверки выявлено, что значения не совпадают, необходимо вывести сообщение «Пароли не совпадают». Не допускается отправка формы на сервер, если значение данного поля не совпадает со значением поля «Пароль». |
Сохранить |
|
Кнопка |
Кнопка для отправки формы |
Обработка формы
для ввода нового пароля
Пароль пользователя должен заменяться на пароль, введённый на форме, с последующей авторизацией пользователя с новым паролем.
Смена пароля для каждой операции по восстановлению пароля может быть выполнена только 1 раз. При повторном вызове этой функции необходимо отображать страницу «Повторный ввод нового пароля» (см. раздел 2.9.8).
2.9.8. Повторный ввод нового пароля
Страница не содержит макросов.
2.9.9. Учётная запись не активирована
Страница не содержит макросов.
2.9.10. Пароль изменён
Макрос |
Предлагаемое наименование |
Значение |
Ссылка |
# LINK# |
Ссылка, по которой в течение 5 секунд после загрузки страницы должно произойти перенаправление. |
Например, страница с сообщением «Пароль изменён. Сейчас вы будете
перенаправлены в Личный кабинет. Если этого не произошло, нажмите на ссылку».
Через 5 секунд после загрузки пользователь перенаправляется в Личный кабинет.
2.9.11. Смена адрес электронной почты
Макрос |
Предлагаемое наименование |
Значение |
Ссылка для повторной отправки письма |
#SEND_ACTIVATION_LINK# |
Ссылка для вызова функции отправки письма «Инструкции по активации учётной записи» (см. раздел 2.10.2). |
Например, страница с сообщением «Адрес электронной почты изменён.
На новый адрес электронной почты выслано письмо с инструкцией по активации
учетной записи» и ссылкой «Выслать письмо повторно».
При нажатии ссылки «Выслать письмо повторно» происходит повторная отправка письма с инструкцией по активации учётной записи.
2.9.12. Отзыв размещён
Страница не содержит макросов.
2.10. Информационные письма
2.10.1. Общие требования к информационным письмам
Информационные письма предназначены для уведомления пользователя о завершении соответствующих процедур на сайте и/или содержат инструкции по дальнейшим необходимым действиям.
Тексты информационных писем должны редактироваться в CMS и поддерживать макросы.
Адрес электронной почты, с которого будет производиться отправка информационных писем, и имя отправителя должны редактироваться в CMS.
2.10.2. Инструкции по активации учётной записи
Макрос |
Предлагаемое наименование |
Значение |
Имя |
#FIRST_NAME# |
Значение поля «Имя» сущности «Пользователь» |
Отчество |
#SECOND_NAME# |
Значение поля «Отчество» сущности «Пользователь» |
Логин |
#LOGIN# |
Значение поля «Логин» сущности «Пользователь» |
Ссылка для активации |
#ACTIVATION_LINK# |
Значение ссылки для вызова активации выбранного пользователя |
2.10.3.
Ввод нового пароля
Макрос |
Предлагаемое наименование |
Значение |
Имя |
#FIRST_NAME# |
Значение поля «Имя» сущности «Пользователь» |
Отчество |
#SECOND_NAME# |
Значение поля «Отчество» сущности «Пользователь» |
Логин |
#LOGIN# |
Значение поля «Логин» сущности «Пользователь» |
Ссылка для ввода пароля |
#NEW_PASSWORD_LINK#. |
Значение ссылки для вызова страницы «Ввод нового пароля» (см. раздел 2.9.7). |
2.10.4.
Уведомление о размещении отзыва
Макрос |
Предлагаемое наименование |
Значение |
ОУ |
#OU# |
Краткое наименование ОУ, по которому оставлен отзыв |
Пользователь |
#USER# |
Пользователь, который оставил отзыв |
Ссылка на отзыв |
#REF_LINK# |
Значение ссылки для перехода на страницу с отзывом |
3.
Требования к функциям сайта
3.1. Пользователи и роли
3.1.1. Общие требования к пользователям
Для управления пользователями должны использоваться стандартные средства, входящие в CMS. Все разрабатываемые дополнительные компоненты по управлению пользователями должны быть выполнены с использованием подходов, аналогичных применяемым в стандартных средствах CMS.
Таблица 4. Атрибуты пользователя
Атрибут |
Обязательно |
Тип данных |
Описание |
Логин |
Нет |
Строка |
Имя пользователя, используемое для авторизации (логин). |
Пароль |
Нет |
Строка |
Пароль, используемый для авторизации. Не показывается при просмотре атрибутов пользователя через сайт. Экранируется при просмотре атрибутов пользователя в CRM.. |
Имя |
Да |
Строка |
Имя пользователя |
Отчество |
Нет |
Строка |
Отчество пользователя |
Скрыть отчество на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться отчество пользователя в блоках на сайте, в которых это предусмотрено. |
Фамилия |
Нет |
Строка |
Фамилия пользователя |
Скрыть фамилию на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться фамилия пользователя в блоках на сайте, в которых это предусмотрено. |
Дата рождения |
Да |
Дата |
Дата рождения пользователя. |
Скрыть дату рождения |
Да |
Да/нет |
Определяет, будет ли отображаться день рождения пользователя в блоках на сайте, в которых это предусмотрено. |
Адрес электронной почты |
Нет |
Строка |
Адрес электронной почты пользователя |
Скрыть адрес электронной почты на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться адрес электронной почты пользователя в блоках на сайте, в которых это предусмотрено. |
Телефон |
Нет |
|
Телефон пользователя |
Скрыть телефон на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться телефон пользователя в блоках на сайте, в которых это предусмотрено. |
Skype |
Да |
Строка |
Имя пользователя в Skype |
Тип |
Да |
Справочник (значение) |
Тип пользователя в соответствии с п. 3.1.3 |
Роли |
Нет |
Список (значение) |
Список значений из справочника ролей в соответствии с п. 3.1.5 |
ID социальной сети |
Нет |
Строка |
Имя пользователя, используемое для авторизации через социальную сеть. |
Тип авторизации |
Нет |
Список (значение) |
Значение из списка: - Native - Google+ - Вконтакте - Одноклассники - Livejournal - Мой мир |
Google+ |
Нет |
Строка |
Профиль в Google+ |
Вконтакте |
Нет |
Строка |
Профиль в Вконтакте |
Одноклассники |
Нет |
Строка |
Профиль в Одноклассники |
|
Нет |
Строка |
Профиль в Facebook |
Livejournal |
Нет |
Строка |
Профиль в Livejournal |
|
Нет |
Строка |
Профиль в Twitter |
|
Нет |
Строка |
Профиль в LinkedIn |
Мой мир |
Нет |
Строка |
Профиль в Мой мир |
3.1.2.
Профиль пользователя
У каждого пользователя должна быть возможность просмотреть профиль другого пользователя по аналогии с функционалом личного кабинета, но только в режиме чтения. При этом должна соблюдаться логика и семантика наименований (например, нельзя выводить название подраздела «Мой блог» при просмотре профиля другого пользователя, следует выводить «Блог», т.е. необходимо использовать наименования, которые будут соответствовать всем допустимым в настоящем ТЗ ситуациям).
Пользователь должен отображаться в соответствии со следующими правилами:
· Если он зарегистрировался через сайт (Native авторизация), то показывается его имя + логин. Например, Иван (ni9ck1).
· Если она не регистрировался на сайте, но проходил авторизацию через социальную сеть, то показывается пиктограмма его социальной сети + имя.
Отображаемое имя пользователя должно являться ссылкой на его профиль.
3.1.3. Типы пользователей
Типы пользователей нужны для определения возможностей пользователя на сайте и разграничения его доступа к функционалу. У администратора в CMS должна быть возможность управлять типами пользователей (просматривать текущий список, добавлять, редактировать или удалять типы пользователей).
Таблица 5. Атрибуты типов пользователей
Атрибут |
Обязательно |
Тип данных |
Описание |
Наименование |
Да |
Строка |
Наименование типа пользователя. Этот атрибут отображается по умолчанию для всех ситуаций, когда в настоящем ТЗ встречается ссылка на тип пользователя. |
Описание |
Нет |
Текст |
Описание типа пользователя. |
Права доступа |
Да |
Свой шаблон |
Список прав доступа, доступных данному типу пользователя. |
В таблице ниже (см. Таблица 6) приведены предустановленные типы пользователей[5], используемые на сайте.
Таблица 6. Предустановленные типы пользователей
Наименование |
Описание |
Гость |
К этому типу относятся все пользователи, не авторизованные на сайте. Данному типу пользователей недоступна возможность зайти в Личный кабинет, а также осуществлять записи на сайте (оставлять отзывы, добавлять ОУ, задавать вопросы и т.д.) Также к этому типу относятся пользователи, не подтвердившие адрес электронной почты, указанный при регистрации |
Участник |
Имеет доступ ко всему функционалу сайта за исключением доступа в разделы Модератора и Администратора. |
Эксперт |
Имеет доступ ко всему функционалу сайта за исключением доступа в разделы Модератора и Администратора. Также имеет возможность просматривать и отвечать на опубликованные вопросы пользователей, давать рекомендации и т.д. без модерации. |
Модератор |
Имеет доступ ко всему функционалу сайта за исключением доступа в разделы Администратора в CMS. Имеет возможность проверять, исправлять и утверждать все записи, оставленные пользователем. |
Администратор |
Имеет все доступные права на сайте. Данный тип пользователя является исключением из списка: он не может быть удалён или отредактирован через CMS. |
Также необходимо соблюсти требования в таблице ниже:
Расширенные требования |
|
Номер |
Требование |
REQ-USR-01-00100 |
У каждого пользователя может быть только один тип. |
REQ-USR-01-00200 |
Изменение типа пользователей осуществляется средствами CMS и доступно только Администратору, за исключением автоматических смен типа, предусмотренных функционалом сайта и описанных в настоящем ТЗ. |
3.1.4.
Права доступа
Права доступа (см. Таблица 7) дают возможность доступа к специальному функционалу на сайте. У администратора в CMS должна быть возможность назначить любое количество прав доступа любому типу пользователя.
Таблица 7. Список прав доступа
Раздел |
Право |
Сайт[6] |
Поиск |
Поиск |
|
Рейтинги |
Просмотр рейтингов |
Да |
|
Размещение отзывов |
Да |
|
Комментирование отзывов |
Да |
|
Подтверждение отзывов |
Нет |
|
Подтверждение оценок |
Нет |
Форум |
Просмотр форумов |
Да |
|
Создание новых тем |
Да |
|
Редактирование своих сообщений |
Да |
|
Редактирование сообщений других пользователей |
Да |
|
Редактирование тем |
Да |
Блоги |
Просмотр блогов |
Да |
|
Возможность оставлять комментарии в чужих блогах |
Да |
|
Возможность вести свой блог |
Да |
Новости |
Чтение новостей |
Да |
Часто задаваемые вопросы |
Просмотр часто задаваемых вопросов |
Да |
|
Возможность задать вопрос |
Да |
Опросы |
Просмотр опросов |
Да |
|
Участие в опросах |
Да |
|
Создание опросов |
Нет |
|
Закрытие опросов |
Нет |
Интервью |
Просмотр интервью |
Да |
Экспертное мнение |
Просмотр экспертных мнений |
Да |
|
Добавление экспертных мнений |
Нет |
3.1.5.
Роли пользователей
Роли пользователей выставляются на основе информации, вносимой пользователем при регистрации, и подтверждённой модератором. Роли расширяют права доступа на сайте в контексте ОУ. У пользователя может быть несколько ролей. Каждая роль, принадлежащая пользователю, должна быть связана, как минимум, с одним ОУ. Для каждого связанного ОУ может быть выставлен признак «Бывший» (по умолчанию этот признак снят). Также допускается ситуация, когда у пользователя нет ролей (например, сторонний наблюдатель, которому интересна информация об ОУ).
У каждой роли должен быть вес (дробное число), который влияет на вес оценки, оставленной пользователем – обладателем роли, при расчёте рейтинга. У администратора в CMS должна быть возможность задать вес для каждой роли.
Ниже представлен пример распределения ролей у пользователя (см. .
Схема 1. Пример распределения ролей пользователя.
Ниже представлены роли пользователей, разделённые по видам:
Таблица 8. Виды ролей пользователей.
Вид роли |
Описание |
Вес по умолчанию |
Руководитель ОУ или его назначенный представитель. Обладатель данной роли такого вида может править любую информацию о связанном с ним ОУ. |
0,5 |
|
Преподаватель |
Может редактировать информацию об ОУ с премодерацией. |
0,8 |
Служащий |
Может редактировать информацию об ОУ с премодерацией. |
0,9 |
Учащийся |
Обычный пользователь с дополнительной ролью, отображающей принадлежность к ОУ. Может добавлять фото и видео об ОУ. |
1 |
Родитель |
Обычный пользователь с дополнительной ролью, отображающей принадлежность к ОУ. Может добавлять фото и видео об ОУ. |
1,1 |
3.2. Карта сайта
Сайт должен содержать следующие разделы:
· Главная (см. раздел 3.3)
· Регистрация (см. раздел 3.4.2)
- Авторизация (см. раздел 3.4.1)
· Личный кабинет (см. раздел 3.5)
· О сайте (WYSWIG страница)
- Правила работы с сайтом (WYSWIG страница)
- Реклама на сайте (WYSWIG страница)
- Партнерам (WYSWIG страница)
· Рейтинги (см. раздел 3.7)
- Как рассчитывается рейтинг (WYSWIG страница)
- Информация для образовательных учреждений
· Общение
- Форум (см. раздел 3.8)
· Правила общения (WYSWIG страница)
- Блоги (см. раздел 3.9)
· Правила ведения блога (WYSWIG страница)
- Вопрос-ответ (см. раздел 3.11)
· Страницы с вопросами (WYSWIG страница)
- Опросы (см. раздел 3.12)
· Поиск (см. раздел 3.6)
· Новости (см. раздел 3.10)
· Интервью (см. раздел 3.13)
· Статьи (WYSWIG страница)
- Экспертное мнение (см. раздел 3.14)
- Где учились знаменитые люди? (см. раздел 3.15)
· Администрация (WYSWIG страница)
3.3. Главная страница
Главная страница должна содержать лого, главное меню, специальное содержимое (см. Схема 2) и футер.
Главное меню: О сайте, Рейтинги, Общение, Интервью, Статьи, Новости
Схема 2. Специальное содержимое главное страницы
Популярные образовательные учреждения
(ОУ с самым высоким рейтингом) ТОП-1 крупным планом фото и срез информации (краткое наименование, рейтинг, страна) ТОП-2-5 списком (превью, краткое наименование, рейтинг, страна) |
Новости
Последние новости. Количество отображаемых новостей должно выбираться исходя из размера блока с популярными образовательными учреждениями |
|
Интервью (последнее по дате интервью: картинка, название, анонс) |
Экспертное мнение (последнее по дате мнение) |
Где учились знаменитые люди?
|
Популярные блоги
Самые читаемые блоги с названиями и ссылками на профили авторов. Количество элементов выбирается исходя из размера формы подписки по вертикали |
Обсуждения на Форуме
Последние обсуждаемые темы на форуме. Количество элементов выбирается исходя из размера формы подписки по вертикали |
Форма подписки |
Часто задаваемые вопросы
|
Опрос |
|
Текст для СЕО |
3.4.
Авторизация и регистрация
3.4.1. Авторизация
Авторизация должна осуществляться посредством ввода имени пользователя и пароля на форме, оформленной в соответствии с дизайном сайта. Рекомендуется в качестве основы использовать стандартные компоненты CMS.
Если у пользователя сохранены Cookie с данными, необходимыми для авторизации, то необходимо производить автоматическую авторизацию пользователя.
Таблица 9. Список полей на форме авторизации
Поле |
Тип поля |
Обязательно |
Описание |
Имя пользователя |
Строка |
Да |
Текстовое поле для ввода имени пользователя. Отправляет форму по Enter. |
Пароль |
Пароль |
Да |
Текстовое поле для ввода пароля. Отправляет форму по Enter. Экранируется маской ввода в соответствии с дизайном сайта. |
Запомнить |
Да/нет |
|
По умолчанию «Нет». |
Забыл пароль |
Ссылка |
|
Ссылка для перехода на страницу восстановления пароля (см. раздел 3.4.4). |
Авторизация через социальные сети |
|
|
Специальный блок для вызова API соответствующих сервисов социальных сетей. Представляет собой список социальных сетей в соответствии с дизайном. При нажатии на элемент списка происходит вызов API соответствующей сети. |
Вход |
Кнопка |
|
Кнопка для отправки формы |
Обработка
формы авторизации на сайте
При верном вводе пары логин/пароль должна происходить авторизация пользователя на сайте. Если установлен чек-бокс «Запомнить», следует использовать Cookie для сохранения данных пользователя, необходимых для авторизации при повторном заходе на сайт. Блок авторизации авторизованным пользователям не показывается.
При неверном вводе пары логин/пароль должна выводиться специальная страница «Ошибка авторизации» (см. раздел 2.9.2).
Допускается авторизация пользователя через следующие социальные сети:
· Facebook (facebook.com)
· В Контакте (vk.com)
· Google Plus (plus.google.ru)
· Одноклассники (odnoklassniki.ru)
· Live Journal (livejournal.com)
· Twitter (twitter.com)
· LinkedIn (linkedin.com)
· Мой мир (my.mail.ru)
При использовании механизма авторизации через социальные сети (и только в случаях успешной авторизации через API социальных сетей) необходимо проводить автоматическую регистрацию пользователя согласно схеме ниже (см. Схема 3).
Схема 3. Алгоритм авторизации пользователя через социальные сети
Начало |
Проверка на уровне социальной сети |
Пользователь разрешил использовать свои данные? |
Проверка на существование в БД сайта |
Пользователь существует в БД сайта? |
Создание нового пользователя |
Авторизация на сайте |
Конец |
Вывод сообщения об ошибке |
Нет |
Нет |
Да |
Да |
Пользователь существует в социальной сети? |
Нет |
Да |
Процессы, используемые в схеме алгоритма, описаны в таблице ниже
(см. Таблица 10).
Таблица 10. Процессы, используемые при авторизации пользователя через социальные сети.
Процесс |
Описание |
Проверка на уровне социальной сети |
Происходит обращение к странице авторизации в выбранной социальной сети, если пользователь еще не авторизовался там. При необходимости вводятся данные для авторизации в социальной сети, далее происходит запрос на разрешение использования его данных. |
Проверка на существование в БД сайта |
Проводится проверка на наличие пользователя, у которого совпадают следующие атрибуты (см. Таблица 4): - атрибут «ID социальной сети» и ID, полученный от социальной сети в соответствии с введённым именем пользователя и паролем; - атрибут «Тип авторизации» и выбранная социальная сеть. |
Создание нового пользователя |
Создаётся новый пользователь. На основе данных, полученных из социальной сети, заполняются следующие атрибуты (при их наличии и возможности их получить): - Имя (если нет, вставляем логин социальной сети) - Отчество - Фамилия - Дата рождения - Адрес электронной почты. |
Авторизация на сайте |
Происходит авторизация пользователя на сайте, фиксируется ID сессии. Если пользователь выбрал признак «Запомнить» на форме авторизации, то выдаются Cookie.Далее пользователь попадает в личный кабинет (см. раздел 3.5). |
Вывод сообщения об ошибке |
Вывод сообщения об ошибке соответствующей ситуации: - Нет в социальной сети: Сообщение не показывается, т.к. всё взаимодействие реализуется функционалом социальной сети. - Не предоставлен доступ к данным: «Извините, авторизация без предоставления доступа к данным невозможна» |
3.4.2.
Регистрация
Регистрация необходима для пользователей типа «Гость». Прохождение регистрации позволяет получить доступ к ранее недоступному функционалу, например, возможности оставить отзыв об ОУ и поставить оценку.
Регистрация представляет собой ссылку на каждой из страниц сайта, которая ведёт на форму регистрации. Ссылка на форму регистрации должна показываться только неавторизованным пользователям.Таблица 11. Список полей на форме регистрации
Поле |
Обязательно |
Тип поля |
Текстовая подсказка |
Описание |
Зачем это нужно? |
Да |
Ссылка |
|
Ссылка на WYSWIG страницу |
Имя |
Да |
Строка |
|
Сохраняется в имя пользователя (см. Таблица 4). |
Отчество |
Нет |
Строка |
|
Сохраняется в отчество пользователя (см. Таблица 4). |
Фамилия |
Нет |
Строка |
|
Сохраняется в фамилию пользователя (см. Таблица 4). |
Дата рождения |
Да |
Дата |
|
К полю предъявляются дополнительные требования (см. REQ-REG-04). |
Логин |
Да |
Строка |
Логин должен содержать только латинские буквы и цифры. |
Сохраняется в логин пользователя (см. Таблица 4). К полю предъявляются дополнительные требования (см. REQ-REG-03). |
Пароль |
Да |
Пароль |
|
Сохраняется в пароль пользователя (см. Таблица 4). |
Подтверждение пароля |
Да |
Пароль |
|
К полю предъявляются дополнительные требования (см. REQ-REG-01). |
Ваш адрес электронной почты |
Да |
|
Внимание! На указанный Вами адрес электронной почты будет отправлена ссылка для активации. |
Сохраняется в адрес электронной почты пользователя (см. Таблица 4). К полю предъявляются дополнительные требования (см. REQ-REG-02). |
Подтвердите Ваш адрес электронной почты |
Да |
|
|
К полю предъявляются дополнительные требования (см. REQ-REG-02). |
Телефон |
Нет |
Телефон |
|
Сохраняется в телефон пользователя (см. Таблица 4). |
Введите цифры |
Да |
Строка |
|
Сопровождается функционалом Captcha. |
Подписаться на новости |
Да |
Да/нет |
|
По умолчанию «Да». |
Примечание |
|
|
Нажав на кнопку «Регистрация», вы соглашаетесь с Правилами работы с сайтом. |
Наименование поля не отображается (выводится только текстовая подсказка). |
Регистрация |
Да |
Кнопка |
|
Кнопка для отправки формы |
Расширенные требования |
|
Номер |
Требование |
REQ-REG-01-00100 |
При заполнении поля «Подтверждение пароля» должна проводиться проверка на соответствие значений полей «Подтверждение пароля» и «Пароль». Если по результатам проверки выявлено, что значения не совпадают, необходимо вывести сообщение «Пароли не совпадают». |
REQ-REG-02-00100 |
При заполнении поля «Подтвердите Ваш адрес электронной почты» должна проводиться проверка на соответствие значений полей «Ваш адрес электронной почты» и «Подтвердите Ваш адрес электронной почты». Если по результатам проверки выявлено, что значения не совпадают, необходимо вывести сообщение «Указанные Вами адреса электронной почты не совпадают». |
REQ-REG-03-00100 |
При заполнении поля «Логин» должны производиться проверка на наличие пользователя с таким логином в БД сайта. Если пользователь с таким логином уже существует в БД сайта, необходимо выводить сообщение «Логин занят». |
REQ-REG-04-00100 |
Не допускается выбор даты выше текущей. |
Обработка формы регистрации
Перед отправкой формы помимо обязательных проверок, также должна проводиться проверка на соблюдение требований REQ-REG.
Значение, внесённое в поле «Введите цифры», должно соответствовать цифрам, изображенным в блоке Captcha. Если цифры не совпадают, должен произойти возврат на форму регистрации с выводом сообщения «Введённые цифры не совпадают с теми, что на картинке». Если есть возможность реализовать проверку по Captcha до отправки формы на сервер, то лучше выбрать именно такой способ.
Если проверка по Captcha прошла, необходимо создать нового пользователя в базе.
Таблица 12. Порядок заполнения атрибутов пользователя, в том числе на основе данных, полученных с формы регистрации.
Атрибут |
Вносимое значение |
Логин |
Значение поля «Логин» с формы регистрации |
Пароль |
Значение поля «Пароль» с формы регистрации |
Имя |
Значение поля «Имя» с формы регистрации |
Отчество |
Значение поля «Отчество» с формы регистрации |
Скрыть отчество на сайте |
Да |
Фамилия |
Значение поля «Фамилия» с формы регистрации |
Скрыть фамилию на сайте |
Да |
Дата рождения |
Значение поля «Дата рождения» с формы регистрации |
Скрыть дату рождения |
Да |
Адрес электронной почты |
Значение поля «Ваш адрес электронной почты» с формы регистрации |
Скрыть адрес электронной почты на сайте |
Да |
Телефон |
Значение поля «Телефон» с формы регистрации |
Скрыть телефон на сайте |
Да |
Подписан на новости |
Значение поля «Подписка на новости» с формы регистрации |
Skype |
|
Тип пользователя |
Гость |
Роли |
|
ID социальной сети |
|
Тип авторизации |
Native |
Google+ |
|
Вконтакте |
|
Одноклассники |
|
|
|
Livejournal |
|
После создания пользователя необходимо:
· выслать письмо «Инструкции по активации учётной записи» (см. раздел 2.10.2) на адрес электронной почты, указанный при регистрации
· отобразить пользователю форму для добавления ОУ и роли (см. Таблица 13)[7]
· после пропуска предыдущего шага или заполнения формы отобразить специальную страницу «Завершение регистрации» (см. раздел 2.9.3)
Таблица 13.
Поле |
Обязательно |
Тип данных |
Описание |
ОУ |
Да |
Справочник (текст) |
|
Роль |
Да |
Справочник (значение) |
|
Бывший |
Да |
Да/нет |
|
Обработка формы на сервере
Для текущего пользователя должна добавиться роль по отношению к ОУ по аналогии с функционалом личного кабинета (см. раздел 3.5.6).
3.4.3. Активация учётной записи
Активация учётной записи (далее в этом разделе – Активация) выполняется по ссылке, высланной на адрес электронной почты, указанные пользователем при регистрации.
Активация должна менять тип пользователя «Гость» на «Пользователь». После активации должна происходить автоматическая авторизация на сайте и переход на специальную страницу «Перенаправление» (см. раздел 2.9.4).
Расширенные требования |
|
Номер |
Требование |
REQ-REG-10-00110 |
Ссылка для активации учётной записи должна быть уникальной и однозначно идентифицировать пользователя, учётную запись которого необходимо активировать. |
REQ-REG-15-00120 |
Не допускается в ссылке использовать в явном виде данные пользователя, указанные им при регистрации. |
REQ-REG-15-00130 |
Активация учётной записи может быть выполнена только 1 раз. При повторном вызове активации необходимо отображать специальную страницу «Повторная активация» (см. раздел 2.9.5). |
3.4.4.
Восстановление пароля
Восстановление пароля должно быть доступно по ссылке «Забыл пароль» на форме авторизации (см. Таблица 9).
Восстановление пароля должно осуществляться с использованием специальной страницы «Восстановление пароля» (см. раздел 2.9.6).
3.5. Личный кабинет
3.5.1. Общие требования
В своём личном кабинете зарегистрированный пользователь может отредактировать личные данные и настройки их видимости, а также перейти в следующие разделы личного кабинета:
· Мой блог (ссылка на личный блог)
· Мои сообщения (см. раздел 3.5.4)
· Мои отзывы и оценки (см. раздел 3.5.5)
· Мои ОУ (см. раздел 3.5.6)
· Изменить пароль (см. раздел 3.5.7)
· Изменить адрес электронной почты (см. раздел 3.5.8)
Если пользователь входит в любой из разделов личного кабинета с не активированной учётной записью, необходимо выводить специальную страницу «Учётная запись не активирована» (см. раздел 2.9.9).\
3.5.2. Профиль пользователя
В профиле пользователя выводится форма с личными данными (см. Таблица 14).
Таблица 14. Форма с личными данными пользователя
Поле |
Обязательно |
Тип данных |
Описание |
Имя |
Да |
Строка |
Имя пользователя |
Отчество |
Нет |
Строка |
Отчество пользователя |
Фамилия |
Нет |
Строка |
Фамилия пользователя |
Дата рождения |
Да |
Дата |
Дата рождения пользователя. |
Телефон |
Нет |
Телефон |
Телефон пользователя |
Skype |
Да |
Строка |
Имя пользователя в Skype |
Google+ |
Нет |
Ссылка |
Профиль в Google+ |
Вконтакте |
Нет |
Ссылка |
Профиль в Вконтакте |
Одноклассники |
Нет |
Ссылка |
Профиль в Одноклассники |
|
Нет |
Ссылка |
Профиль в Facebook |
Livejournal |
Нет |
Ссылка |
Профиль в Livejournal |
|
Нет |
Ссылка |
Профиль в Twitter |
|
Нет |
Ссылка |
Профиль в LinkedIn |
Мой мир |
Нет |
Ссылка |
Профиль в Мой мир |
Расширенные требования |
|
Номер |
Требование |
REQ-ACC-10-00110 |
Каждое значение для социальной сети является ссылкой на профиль пользователя в социальной сети |
REQ-ACC-10-00120 |
У пользователя должна быть возможность отредактировать принадлежность к социальной сети |
REQ-ACC-10-00130 |
При редактировании принадлежность к социальной сети должна проходить соответствующая проверка (см. раздел 2.8). |
Обработка формы с личными данными
Обработка производится путём записи значений полей формы в одноимённые атрибуты пользователя (см. раздел 3.1.1).
3.5.3. Настройки видимости
В настройках видимости выводится форма с настройками видимости атрибутов пользователе (см. Таблица 15).
Таблица 15. Форма с настройками видимости атрибутов пользователей
Поле |
Обязательно |
Тип данных |
Описание |
Скрыть отчество на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться отчество пользователя в блоках на сайте, в которых это предусмотрено. |
Скрыть фамилию на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться фамилия пользователя в блоках на сайте, в которых это предусмотрено. |
Скрыть дату рождения |
Да |
Да/нет |
Определяет, будет ли отображаться день рождения пользователя в блоках на сайте, в которых это предусмотрено. |
Скрыть адрес электронной почты на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться адрес электронной почты пользователя в блоках на сайте, в которых это предусмотрено. |
Скрыть телефон на сайте |
Да |
Да/нет |
Определяет, будет ли отображаться телефон пользователя в блоках на сайте, в которых это предусмотрено. |
Обработка формы с настройками видимости
Обработка производится путём записи значений полей формы в одноимённые атрибуты пользователя (см. раздел 3.1.1).
3.5.4. Мои сообщения
3.5.4.1. Общие требования к разделу
Данный раздел личного кабинета позволяет пользователю обмениваться личными сообщениями с другими пользователями сайта. Раздел содержит 2 подраздела (Водящие и Исходящие) и функционал «Новое сообщение». При входе в раздел отображается подраздел «Входящие».
Таблица 16. Атрибуты сообщений для хранения в БД
Атрибут |
Обязательно |
Тип данных |
Описание |
Отправитель |
Да |
Справочник (текст) |
Отправитель сообщения |
Получатель |
Да |
Справочник (текст) |
Получатель сообщения |
Дата отправки |
Да |
Дата |
Дата отправки сообщения |
Дата прочтения |
Нет |
Дата |
Дата открытия сообщения получателем |
Тема |
Да |
Строка |
Тема сообщения |
Текст сообщения |
Да |
Текст |
|
Удалено |
Да |
Да/нет |
|
3.5.4.2.
Новое сообщение
При обращении к функционалу «Новое сообщение» пользователю показывается незаполненная форма сообщения (см. Таблица 17).
Таблица 17. Форма сообщения
Поле |
Обязательно |
Тип данных |
Описание |
Получатель |
Да |
Справочник (текст) |
Поиск по логину пользователя |
Тема |
Да |
Строка |
|
Текст сообщения |
Да |
Текст |
|
Отправить |
Да |
Кнопка |
Кнопка для отправки формы. |
Обработка формы сообщения
При обработке формы сообщения необходимо сохранить сообщение в БД, распределив данные с формы (см. Таблица 17) по соответствующим атрибутам сообщения (см. Таблица 16).
Таблица 18. Порядок заполнения атрибутов сообщения данными с формы сообщения
Атрибут |
Вносимое значение |
Отправитель |
Пользователь, отправивший сообщение |
Получатель |
Значение поля «Получатель» с формы сообщения |
Дата отправки |
Дата и время нажатия кнопки «Отправить» на форме сообщения |
Дата прочтения |
Не заполняется |
Тема |
Значение поля «Тема» с формы сообщения |
Текст сообщения |
Значение поля «Текст сообщения» с формы сообщения |
Удалено |
Нет |
3.5.4.3.
Входящие
Во входящих должны отображаться все сообщения, в которых получателем является текущий пользователь с признаком «Удалено» равным «Нет». Сообщения должны отображаться в форме таблицы (grid), которые содержит следующие поля:
· «От» (Логин отправителя)
· «Имя» (Имя отправителя)
· «Дата отправки»
· «Тема»
Страница «Входящие» должна поддерживать постраничный вывод сообщений (по 20 сообщений на страницу с возможностью выбрать количество отображаемых сообщений на странице: 20, 50, 100). Таблица должна позволять пользователю сортировать сообщения по любому из своих полей с учётом всего объёма записей.
Все непрочитанные сообщения (с пустой датой прочтения) должны подсвечиваться жирным шрифтом. Пользователь должен иметь возможность открыть сообщение в режиме только для чтения (см. Таблица 19).
Таблица 19. Форма для просмотра входящих сообщений
Поле |
Обязательно |
Тип данных |
Описание |
Отправитель |
Да |
Справочник (текст) |
Логин отправителя |
Имя |
Да |
Справочник (текст) |
Имя отправителя |
Дата отправки |
Да |
Дата |
Дата отправки сообщения в формате ДД.ММ.ГГГГ ЧЧ:МН, где ЧЧ – час отправки сообщения в 24-х часовом формате, МН – минуты отправки сообщения (недостающие символы слева дополняются нулями). |
Тема |
Да |
Строка |
|
Текст сообщения |
Да |
Текст |
|
Обработка формы просмотра входящего сообщения
Форма не может быть отправлена и обработана на сервере.
Расширенные требования |
|
Номер |
Требование |
REQ-MSG-10-00100 |
Перед показом формы сообщения (см. Таблица 19) необходимо установить значение атрибута сообщения «Дата прочтения» равным текущем дате и времени. |
3.5.4.4.
Исходящие
В исходящих должны отображаться все сообщения, в которых отправителем является текущий пользователь с признаком «Удалено» равным «Нет». Сообщения должны отображаться в форме таблицы (grid), которые содержит следующие поля:
· «Кому» (Логин получателя)
· «Имя» (Имя получателя)
· «Дата отправки»
· «Дата прочтения»
· «Тема»
Страница «Исходящие» должна поддерживать постраничный вывод сообщений (по 20 сообщений на страницу с возможностью выбрать количество отображаемых сообщений на странице: 20, 50, 100). Таблица должна позволять пользователю сортировать сообщения по любому из своих полей с учётом всего объёма записей.
Пользователь должен иметь возможность открыть сообщение в режиме только для чтения (см. Таблица 20).
Таблица 20. Форма для просмотра исходящих сообщений
Поле |
Обязательно |
Тип данных |
Описание |
Получатель |
Да |
Справочник (текст) |
Логин получателя |
Имя |
Да |
Справочник (текст) |
Имя получателя |
Дата отправки |
Да |
Дата |
Дата отправки сообщения в формате ДД.ММ.ГГГГ ЧЧ:МН, где ЧЧ – час отправки сообщения в 24-х часовом формате, МН – минуты отправки сообщения (недостающие символы слева дополняются нулями). |
Дата прочтения |
|
|
Дата прочтения сообщения (см. REQ-MSG-10-00100) в формате ДД.ММ.ГГГГ ЧЧ:МН, где ЧЧ – час отправки сообщения в 24-х часовом формате, МН – минуты отправки сообщения (недостающие символы слева дополняются нулями). |
Тема |
Да |
Строка |
|
Текст сообщения |
Да |
Текст |
|
Обработка формы просмотра входящего сообщения
Форма не может быть отправлена и обработана на сервере.
3.5.5. Мои отзывы и оценки
В данном разделе у пользователя должна быть возможность просмотреть список оставленных им отзывов и оценок. Отзывы должны выводиться в том же формате, что и в соответствующем разделе (см. раздел 3.7.4), но с условием того, что автором отзывов является текущий пользователь.
У пользователя также должна быть возможность просмотреть оставленные им отзывы. Правила отображения отзывов см. в разделе 3.7.4.2.
3.5.6. Мои ОУВ данном разделе пользователь должен иметь возможность просмотреть список выбранных им ОУ и отредактировать свои роли по отношению к этим ОУ.
Таблица 21. Атрибуты связи ОУ с пользователями
Атрибут |
Обязательно |
Тип данных |
Описание |
Пользователь |
Да |
Справочник (текст) |
По умолчанию текущий пользователь |
ОУ |
Да |
Справочник (текст) |
|
Роль |
Да |
Справочник (значение) |
|
Бывший |
Да |
Да/нет |
|
Подтверждено |
Да |
Да/нет |
По умолчанию «Нет». Доступно только администратору или модератору в CMS |
Список ОУ должен выводиться в форме таблицы (grid) с набором следующих полей:
· ОУ (Полное наименование ОУ)
· Роль
· Бывший
В данном разделе у пользователя должна быть возможность добавить, отредактировать и удалить свои роли в отношении ОУ.
У модератора и администратора в CMS должна быть возможность задать значение для признака «Подтверждено». До подтверждения роли, никакие дополнительные права и функции, связанные с этой ролью, не должны работать.
3.5.7. Изменить пароль
Для изменения пароля пользователь должен заполнить специальную форму (см. Таблица 22).
Таблица 22. Список полей на форме изменения пароля
Поле |
Обязательно |
Тип поля |
Описание |
Текущий пароль |
|
|
|
Новый пароль |
Да |
Пароль |
|
Подтверждение нового пароля |
Да |
Пароль |
При заполнении данного поля должна проводиться проверка на соответствие его значения со значением поля «Новый пароль». Если по результатам проверки выявлено, что значения не совпадают, необходимо вывести сообщение «Пароли не совпадают». Не допускается отправка формы, в котором значение данного поля не совпадает со значением поля «Новый пароль». |
Обработка формы изменения пароля
Если текущий пароль не соответствует значению, введённому на форме, необходимо вывести форму для изменения пароля (см. Таблица 22) с сообщением «Неверный текущий пароль». Если текущий пароль соответствует значению, введённому на форме, необходимо заменить текущий пароль на новый, и отобразить страницу «Пароль изменён» (см. раздел 2.9.10).
3.5.8. Изменить адрес электронной почты
Для изменения пароля пользователь должен заполнить специальную форму (см. Таблица 23).
Таблица 23. Список полей на форме изменения адрес электронной почты
Поле |
Обязательно |
Тип поля |
Описание |
Текущий пароль |
|
|
|
Новый адрес электронной почты |
Да |
|
|
Подтверждение нового адрес электронной почты |
Да |
|
При заполнении данного поля должна проводиться проверка на соответствие его значения со значением поля «Новый адрес электронной почты». Если по результатам проверки выявлено, что значения не совпадают, необходимо вывести сообщение «Адрес не совпадают». Не допускается отправка формы, в которой значение данного поля не совпадает со значением поля «Новый адрес электронной почты». |
Обработка формы изменения пароля
Если текущий пароль не соответствует значению, введённому на форме, необходимо вывести форму для изменения пароля (см. Таблица 23) с сообщением «Неверный текущий пароль». Если текущий пароль соответствует значению, введённому на форме, необходимо заменить текущий адрес электронной почты на новый, и отобразить страницу «Смена адрес электронной почты» (см. раздел 2.9.11).
3.6. Поиск
Поиск должен осуществляться по всем разделам сайта.
Результаты поиска должны выводиться с отображением раздела, к которому они относятся, и ссылки для перехода в ту часть раздела, в которой обнаружен релевантный текста.
Пользователь должен иметь возможность отфильтровать результаты поиска по разделам.
3.7. Образовательные учреждения
3.7.1. Основная страница раздела
На этой странице выводится ТОП-50 образовательных учреждений с наивысшим рейтингом в форме таблицы (grid) со следующими полями:
· ОУ (полное наименование ОУ, ссылка на карточку ОУ)
· Тип ОУ
· Регион (фактический регион расположения ОУ)
· Рейтинг ОУ
· Количество отзывов (количество отзывов по ОУ, ссылка на страницу с отзывами об ОУ)
· Проблем решено (количество отзывов по ОУ с признаком «Проблема решена»)
· Нравится (кол-во like)
Страница должна содержать ссылку на полный список ОУ. Полный список ОУ выводится постранично в таблице (grid) с тем же набором полей, что и ТОП-50 ОУ.
Таблица должна поддерживать возможность сортировки по любому из полей. У пользователя должна быть возможность отфильтровать список ОУ согласно списку критериев (см. Таблица 24).
Также на данной странице пользователь должен иметь возможность просмотреть карточку ОУ (см. раздел 3.7.2) и отзывы о ОУ (см. 3.7.4).
Таблица 24. Форма критериев для отбора ОУ
Поле |
Тип данных |
Требования и порядок применения |
Наименование ОУ |
Строка |
- Отбирает по вхождению введённого значения в значения полей «Полное наименование ОУ» и «Сокращённое наименование ОУ» - Не зависит от регистра введённых символов |
Регион |
Справочник (текст) |
- Отбирает по точному соответствию значения поля «Регион» выбранному значению |
Действующее ОУ |
Да/Нет |
- По умолчанию «Да» - Отбирает по точному соответствию значения поля «Действует» введённому значению |
Вид ОПФ |
Справочник (значение) |
- Отбирает по точному соответствию значения поля «Организационно-правовая форма» введённому значению |
Тип ОУ |
Справочник (значение) |
- Отбирает по точному соответствию значения поля «Тип» введённому значению |
Вид ОУ |
Справочник (значение) |
- Если выбрано значение для типа ОУ, то список доступных значений должен быть ограничен выбранным типом ОУ - Отбирает по точному соответствию значения поля «Вид» введённому значению |
Рейтинг выше |
Число |
- Отбирает по значению поля «Рейтинг», превышающему введённое значение |
3.7.2.
Карточка ОУ
3.7.2.1. Общие требования
У каждого образовательного учреждения должен быть набор базовых атрибутов (см. Таблица 25).
Таблица 25. Базовые атрибуты ОУ
Группа |
Атрибут |
Тип данных |
Описание |
Общая информация |
Код |
Строка |
|
Полное наименование |
Строка |
|
|
Сокращённое наименование |
Строка |
|
|
Действует |
Да/нет |
|
|
В настоящий момент |
Список (текст) |
Ссылка на действующее ОУ |
|
Виза |
Справочник (значение) |
Виза, необходимая для поступления в ОУ |
|
Страна происхождения |
Справочник (значение) |
См. раздел 3.7.3.4 |
|
Главное фото |
Изображение |
|
|
Юридические сведения |
Организационно-правовая форма |
Справочник (значение) |
См. раздел 3.7.3.1 |
Головное ОУ |
Справочник (текст) |
|
|
Тип |
Справочник (значение) |
См. раздел 3.7.3.2 |
|
Вид |
Справочник (значение) |
См. раздел 3.7.3.2 |
|
Год основания |
Число |
Четырёхзначное число |
|
ОГРН |
Строка |
|
|
ИНН |
Строка |
|
|
КПП |
Строка |
|
|
Популярность |
Рейтинг |
Дробное число |
Недоступно для редактирования Округляется до сотых |
Нравится |
Число |
Недоступно для редактирования Количество like |
|
Юридический адрес |
Страна |
Справочник (значение) |
См. раздел 3.7.3.4 |
Регион |
Справочник (текст) |
См. раздел 3.7.3.4 |
|
Город |
Справочник (текст) |
См. раздел 3.7.3.4 |
|
Адрес |
Строка |
|
|
Фактический адрес |
Страна |
Справочник (значение) |
См. раздел 3.7.3.4 |
Регион |
Справочник (текст) |
См. раздел 3.7.3.4 |
|
Город |
Справочник (текст) |
См. раздел 3.7.3.4 |
|
Адрес |
Строка |
|
|
Контакты |
Телефоны |
Строка |
|
Факсы |
Строка |
|
|
|
Строка |
|
|
E-mail для уведомлений |
|
Отображается только действующему подтверждённому официальному представителю ОУ |
|
Веб-сайт |
Строка |
|
|
Дополнительная информация |
Люди |
Список (текст) |
См. описание после таблицы |
Здесь учились |
Свой шаблон |
Список знаменитых людей (см. п. 3.15) |
|
Достижения |
WYSWIG |
|
|
Фото |
Свой шаблон |
|
|
Видео |
Свой шаблон |
|
|
Социальные сети |
Google+ |
Строка |
Профиль в Google+ |
Вконтакте |
Строка |
Профиль в Вконтакте |
|
Одноклассники |
Строка |
Профиль в Одноклассники |
|
|
Строка |
Профиль в Facebook |
|
Livejournal |
Строка |
Профиль в Livejournal |
|
|
Строка |
Профиль в Twitter |
|
|
Строка |
Профиль в LinkedIn |
|
Мой мир |
Строка |
Профиль в Мой мир |
Вся выводимая информация об ОУ должна быть сгруппирована по
группам. Значения полей «Рейтинг» и «Нравится» должны выделяться и выводиться
рядом с полным наименованием ОУ. Социальные сети должны отображаться
соответствующими пиктограммами (при наличии подтвержденных ID профилей) и
также должны выводиться рядом с полным наименованием ОУ.
Список людей, должен быть разбит на роли:
· Первым идёт официальный представитель со ссылкой на его профиль
· Далее выводится информация об остальных ролях (см. Таблица 26) с ограничением по 10 человек на роль. Если ограничение превышено, необходимо выводить ссылку (переход по ссылке раскрывает список).
Таблица 26. Вывод информации о людях, связанных с ОУ
Преподаватели |
Служащие |
Учащиеся |
Родители |
Александр (nick1) |
Фёдор (nick4) |
Артём (nick31) |
Ольга (nick41) |
Иван (nick15) |
Фёдор (nick4) |
Александр (nick56) |
Пётр (nick98) |
Елена (nick13) |
Фёдор (nick4) |
Марат (nick122) |
Ольга (nick41) |
Александр (nick1) |
Фёдор (nick4) |
Артём (nick31) |
Пётр (nick98) |
Иван (nick15) |
Фёдор (nick4) |
Александр (nick56) |
Ольга (nick41) |
Елена (nick13) |
Фёдор (nick4) |
Марат (nick122) |
Пётр (nick98) |
Александр (nick1) |
Фёдор (nick4) |
Артём (nick31) |
Ольга (nick41) |
Иван (nick15) |
Фёдор (nick4) |
Александр (nick56) |
Пётр (nick98) |
Елена (nick13) |
Фёдор (nick4) |
Марат (nick122) |
Ольга (nick41) |
Елена (nick13) |
Фёдор (nick4) |
Марат (nick122) |
Пётр (nick98) |
Ещё преподаватели… |
Ещё служащие… |
Еще учащиеся… |
Ещё родители… |
В CMS должна быть возможность для выбранного типа ОУ:
· задать набор дополнительных полей (добавить, удалить, отредактировать) с указанием типа используемых данных
· задать собственную группу для каждого из дополнительных полей (добавить, удалить, отредактировать)
Если для ОУ в соответствии с его типом заданы дополнительные поля, у пользователей также должна быть возможность заполнить значения для дополнительных полей, как при доступе в контексте ролей через сайт (см. раздел 3.1.5), так и при доступе через CMS (путём администрирования).
При этом на поля должны распространяться требования раздела 2.7.
3.7.2.2. Фото и видео
Фото (или видео) в карточке ОУ должны быть представлены в своей группе (фото в фото, видео в видео) и отображаться в форме превью. При этом и фото и видео также должны быть сгруппированы по типам ролей загрузивших их пользователей. При клике по превью в модальном окне должна открываться более крупная версия фото (или видео) с атрибутами. У пользователя должна быть возможность листать список фото (или видео), как при просмотре в модальном окне, так и при просмотре превью в карточке ОУ. Порядок отображения и размер превью, а также размеры укрупненной версии фото (или видео) должны быть выбраны таким образом, чтоб органично вписываться в дизайн. Превью должен создаваться автоматически при загрузке фото (или видео) на сайт.
У каждого пользователя, имеющего принадлежность к ОУ, должна быть возможность загрузить новое фото (или видео) или заменить добавленное, а также задать описание фото (или видео) в соответствии с атрибутами (см. Таблица 27).
На фото (или видео), в соответствии с типом роли добавившего их пользователя, также распространяются правила редактирования и модерации.
Таблица 27. Атрибуты фото (или видео)
Атрибут |
Обязательно |
Тип данных |
Описание |
Пользователь |
Да |
Справочник (текст) |
По умолчанию текущий пользователь. Служебное поле. |
ОУ |
Да |
Справочник (текст) |
Служебное поле. |
Название |
Да |
Строка |
|
Описание |
Нет |
Текст |
|
3.7.3.
Справочники
3.7.3.1. Организационно-правовая форма
Справочник организационно-правовых форм (см. Таблица 28) заполняется при импорте сведений об ОУ из файла (см. раздел 3.7.5) и должен быть доступен для редактирования в CMS.
Таблица 28. Атрибуты справочника организационно-правовых форм образовательных учреждений
Атрибут |
Обязательно |
Тип данных |
Описание |
ОПФ |
Да |
Строка |
|
Страна |
Да |
Справочник (значение) |
Первый уровень значений из справочника стран и регионов (см. раздел 3.7.3.4) |
При выборе ОПФ в соответствующих формах должен производиться автоматический анализ страны, к которой принадлежит ОУ, и замена доступных значений ОПФ для этой страны, чтобы пользователь видел и имел возможность выбрать только ОПФ, соответствующие стране происхождения ОУ.
3.7.3.2. Типы ОУ
Справочник типов (см. раздел Таблица 29) заполняется при импорте сведений об ОУ из файла (см. раздел 3.7.5) и должен быть доступен для редактирования в CMS.
Таблица 29. Атрибуты справочника типов образовательных учреждений
Атрибут |
Обязательно |
Тип данных |
Описание |
Наименование |
Да |
Строка |
|
Страна |
Да |
Список (значение) |
Первый уровень значений из справочника стран и регионов (см. раздел 3.7.3.4) |
При выборе типа в соответствующих формах должен производиться автоматический анализ страны, к которой принадлежит ОУ, и замена доступных значений типов для этой страны, чтобы пользователь видел и имел возможность выбрать только типы ОУ, соответствующие стране происхождения ОУ.
3.7.3.3. Виды ОУ
Справочник видов ОУ (см. раздел Таблица 30) заполняется при импорте сведений об ОУ из файла (см. раздел 3.7.5) и должен быть доступен для редактирования в CMS.
Таблица 30. Атрибуты справочника типов и видов образовательных учреждений
Атрибут |
Обязательно |
Тип данных |
Описание |
Наименование |
Да |
Строка |
|
Тип |
Да |
Список (значение) |
Ссылка на тип ОУ (см. раздел 3.7.3.2) |
При выборе вида в соответствующих формах должен производиться автоматический анализ типа и замена доступных значений видов, чтобы пользователь видел и имел возможность выбрать только виды ОУ, соответствующие типу ОУ.
3.7.3.4. Страны и регионы
Справочник стран и регионов (см. раздел Таблица 31) заполняется при импорте сведений об ОУ из файла (см. раздел 3.7.5) и должен быть доступен для редактирования в CMS.
Страны – это значения первого уровня. Регионы – это значения второго уровня. Справочник должен быть строго двухуровневым.
Таблица 31. Атрибуты справочника стран и регионов
Атрибут |
Обязательно |
Тип данных |
Описание |
Наименование |
Да |
Строка |
|
Родитель |
Да |
Список (значение) |
Ссылка на список значений с 1-го уровня этого же справочника |
При выборе региона в соответствующих формах должен производиться
автоматический анализ страны, к которой принадлежит ОУ, и замена доступных
значений регионов для этой страны, чтобы пользователь видел и имел возможность
выбрать только регионы, соответствующие стране происхождения ОУ.
3.7.3.5. Визы
Справочник виз (см. Таблица 32) должен быть доступен для редактирования в CMS.
Таблица 32. Атрибуты справочника организационно-правовых форм образовательных учреждений
Атрибут |
Обязательно |
Тип данных |
Описание |
Виза |
Да |
Строка |
|
3.7.4.
Отзывы и рейтинги
3.7.4.1. Общие требования к отзывам
Каждый[8] пользователь, просматривая информацию об ОУ должен иметь возможность увидеть текущий рейтинг ОУ и оставить отзыв об ОУ. Все отзывы должны сохраняться в БД (см. Таблица 33).
Таблица 33. Атрибуты отзыва об ОУ
Атрибут |
Обязательно |
Тип данных |
Описание |
Заголовок |
Да |
Строка |
|
Текст |
Да |
Текст |
|
Опубликован |
Да |
Да/нет |
Если значение данного поля равно «Нет», то отзыв не должен быть доступен для просмотра |
Оценка |
Да |
Число |
Оценка о десятибалльной шкале. |
Оценка учтена |
Да |
Да/нет |
|
Жалоба |
Да |
Да/нет |
|
Проблема решена |
Да |
Да/нет |
|
Вес оценки |
Да |
Дробное число |
|
Пользователь |
Да |
Список (текст) |
|
ОУ |
Да |
Список (текст) |
|
Дата |
Да |
Дата |
|
3.7.4.2.
Просмотр отзывов
При просмотре отзыва необходимо выводить следующие данные:
· Заголовок
· Текст
· Оценка (если она учтена)
· Ссылку на профиль пользователя
· Дата (со временем размещения отзыва)
· Комментарии (см. раздел 3.7.4.4)
Если выводиться весь список отзывов об ОУ, в заголовке страницы должно выводиться краткое наименование ОУ (ссылка на карточку ОУ), для которого оставлен отзыв, и тексты отзывов должны быть поданы кратко с возможностью перейти к просмотру отзыва. Остальная информация по каждому отзыву должна соответствовать заявленному выше списку атрибутов.
3.7.4.3. Размещение отзывов
При размещении отзыва об ОУ пользователь должен заполнить соответствующую форму (см. Таблица 34).
Таблица 34. Поля формы отзыва об ОУ
Поле |
Тип данных |
Текстовая подсказка |
Требования и порядок применения |
Заголовок |
Строка |
|
- Не более 50 символов |
Текст |
Текст |
|
- |
Оценка |
Свой шаблон |
|
- Оценка о десятибалльной шкале - При разработке дизайна следует использовать подходящее для этого решение (радио-кнопки, ползунок и т.п.) - У пользователя должна быть возможность отказаться ставить оценку |
Жалоба |
Да/нет |
Выбор данного поля увеличивает вес оценки до того, пока проблема не будет решена представителем ОУ и подтверждена пользователем через соответствующий комментарий. Если вы не имеете возможности выбрать это поле, значит у официальный представитель ОУ пока не зарегистрирован на сайте |
- По умолчанию «Нет» - Поле не активно, если у ОУ нет пользователя с ролью «Официальный представитель» |
Обработка формы на сервере
При получении формы необходимо сохранить отзыв (см. Таблица 35).
Таблица 35. Обработка данных с формы отзыва об ОУ
Атрибут |
Значение |
Заголовок |
С соответствующего поля на форме |
Текст |
С соответствующего поля на форме |
Опубликован |
Да |
Оценка |
С соответствующего поля на форме Если пользователь отказался ставить оценку, то 0. |
Оценка учтена |
Нет |
Жалоба |
С соответствующего поля на форме |
Проблема решена |
Нет |
Вес оценки |
0,75 – если это жалоба вне зависимости от роли пользователя. В остальных случаях 1. Также меняется при расчёте рейтинга (см. раздел 3.7.4.5). |
Пользователь |
Текущий пользователь |
ОУ |
ОУ, для которого оставляли отзыв |
Дата |
Текущая дата |
После сохранения отзыва пользователю должно выводиться специальная
страница (см. раздел 2.9.12).
Официальному представителю ОУ (при его наличии) должно отправляться
соответствующее письмо (см. раздел 2.10.4).
3.7.4.4. Комментарии к отзывам
У каждого отзыва может быть список комментариев (см. Таблица 36).
Таблица 36. Атрибуты комментария к отзыву об ОУ
Атрибут |
Обязательно |
Тип данных |
Описание |
Отзыв |
Да |
Список (текст) |
См. раздел 3.7.4 |
Текст |
Да |
Текст |
|
Опубликован |
Да |
Да/нет |
|
Проблема решена |
Да |
Да/нет |
|
Пользователь |
Да |
Список (текст) |
См. раздел 3.1 |
Дата |
Да |
Дата |
|
У пользователя должна быть возможность оставить комментарий к
отзыву, заполнив соответствующую форму (см. Таблица 37).
Таблица 37. Форма комментария к отзыву об ОУ
Поле |
Тип данных |
Требования и порядок применения |
Текст |
|
- |
Проблема решена |
Да/нет |
- Доступно только пользователю, который оставил отзыв |
Обработка формы на сервере
При получении формы необходимо сохранить комментарий (см. Таблица 38).
Таблица 38. Обработка данных с формы комментария к отзыву
Атрибут |
Значение |
Отзыв |
Отзыв, для которого оставляется комментарий |
Текст |
С соответствующего поля на форме |
Опубликован |
Да |
Проблема решена |
Нет, или с соответствующего поля на форме |
Пользователь |
Пользователь, разместивший комментарий |
Дата |
Текущая дата |
3.7.4.5.
Расчёт рейтинга
При расчёте рейтинга к учёту принимаются только отзывы:
· с учтёнными оценками;
· с оценкой больше 0;
· с датой не ранее текущая дата минус 2 года.
Каждый день рейтинг всех ОУ должен быть пересчитан по следующему алгоритму:
· Для отзывов с признаками «Жалоба» и «Проблема решена» равны «Да» вес оценки должен быть установлен в соответствии с ролью пользователя[9]. Для остальных отзывов вес не пересчитывается.
· Рейтинг ОУ равен среднему арифметическому произведений оценки и её веса.
3.7.5. Импорт сведений об ОУ из Excel файла
У администратора в CMS должна быть возможность выбрать Excel файл для загрузки с диска компьютера, запустить импорт в асинхронном режиме и отслеживать ход его выполнения (видеть порядковый номер текущей обрабатываемой записи из Excel файла).
Во время импорта должны действовать следующие правила:
· редактирование любой обновляемой информации об ОУ должно быть запрещено;
· уникальность записи должна определяться по следующим признакам:
- полное наименование;
- код[g3] ;
- юридический адрес: регион;
· должны соблюдаться требования к целостности данных при массовых операциях (см. раздел 2.5);
· импорт с каждого листа производится согласно описаниям в соответствующих таблицах:
- с листа «ОУ федеральные» - Таблица 40;
- с листа «ОУ региональные» - Таблица 41;
· операция с каждой записью должна определяться на основании соответствия условиям (см. Таблица 39):
- наличие совпадений в БД: найдена такая же запись в БД;
- уже обновлено или добавлено: если ранее в процессе импорта такая запись уже была обновлена или добавлена;
- протоколирование: ведётся запись в лог;
· по результатам импорта должно выводиться результат:
- «Импорт завершен», если в процессе импорта лог не формировался;
- «Импорт завершён с ошибками», если в процессе импорта сформирован лог;
· записи об ОУ не должны удаляться из БД.
Таблица 39. Правила импорта из Excel файла
Совпадение есть |
Обновлено или добавлено |
Протоколирование |
Операция |
Нет |
Нет |
Нет |
Добавить |
Нет |
Да |
Да |
Нет |
Да |
Нет |
Нет |
Обновить |
Да |
Да |
Да |
Нет |
К протоколированию информации предъявляются следующие требования:
· протокол ведётся только по результатам последнего импорта;
· протокол хранится в БД сайта;
· в протокол должна вноситься следующая информация:
- дата фиксации записи;
- характер записи (обновление или добавление)
- полная информация о записи из Excel файла (позиция, список полей со значениями);
- ссылка на найденное ОУ из БД сайта.
· просмотр записей протокола должен быть доступен в CMS с возможностью отфильтровать по характеру записи и/или ссылке на ОУ в БД сайта;
Таблица 40. Импорт ОУ из Excel файла с листа «ОУ федеральные»
Имя поля в Excel |
Атрибут ОУ |
Правила импорта |
Идентификатор |
|
- Не обрабатывается |
Код ОУ (уникальный в рамках региона) |
Код |
- |
Полное наименование ОУ |
Полное наименование |
- |
Сокращенное наименование ОУ |
Сокращённое наименование |
- |
Действует (функционирует) |
Действует |
- |
Ссылка на актуальное ОУ |
В настоящий момент |
- |
Вид организационно-правовой формы |
Организационно-правовая форма |
- |
Тип ОУ |
|
- Не обрабатывается |
Наименование типа ОУ |
Тип |
- |
Вид ОУ |
|
- Не обрабатывается |
Наименование вида ОУ |
Вид |
- |
Категория образовательного учреждения |
|
- Не обрабатывается |
Филиал |
|
- Не обрабатывается |
Головное образовательное учреждение |
Головное ОУ |
- |
Вышестоящая организация |
|
- Не обрабатывается |
Юридический адрес ОУ |
Юридический адрес: Адрес |
- |
Фактический адрес ОУ |
Фактический адрес: Адрес |
- |
Должность руководителя ОУ |
|
- Не обрабатывается |
ФИО руководителя ОУ |
|
- Не обрабатывается |
Телефоны ОУ |
Телефоны |
- |
Факсы ОУ |
|
- |
E-mail ОУ |
|
- |
Адрес сайта ОУ |
Веб-сайт |
- |
Номер государственной регистрации в ЕГРЮЛ (ОГРН) |
ОГРН |
- |
ИНН |
ИНН |
- |
КПП |
КПП |
- |
Субъект РФ |
Юридический адрес: Регион Юридический адрес: Страна |
- |
Адреса мест осуществления образовательной деятельности |
|
- Не обрабатывается |
Подчинение |
|
- Не обрабатывается |
Таблица 41. Импорт ОУ из Excel файла с
листа «ОУ региональные»
Имя поля в Excel |
Атрибут ОУ |
Правила импорта |
Идентификатор |
|
- Не обрабатывается |
Код ОУ (уникальный в рамках региона) |
Код |
- |
Полное наименование ОУ |
Полное наименование |
- |
Сокращенное наименование ОУ |
Сокращённое наименование |
- |
Действует (функционирует) |
Действует |
- |
Ссылка на актуальное ОУ |
В настоящий момент |
- |
Вид организационно-правовой формы |
Организационно-правовая форма |
- |
Тип ОУ |
|
- Не обрабатывается |
Наименование типа ОУ |
Тип |
- |
Вид ОУ |
|
- Не обрабатывается |
Наименование вида ОУ |
Вид |
- |
Категория образовательного учреждения |
|
- Не обрабатывается |
Филиал |
|
- Не обрабатывается |
Головное образовательное учреждение |
Головное ОУ |
- |
Вышестоящая организация |
|
- Не обрабатывается |
Юридический адрес ОУ |
Юридический адрес: Адрес |
- |
Фактический адрес ОУ |
Фактический адрес: Адрес |
- |
Должность руководителя ОУ |
|
- Не обрабатывается |
ФИО руководителя ОУ |
|
- Не обрабатывается |
Телефоны ОУ |
Телефоны |
- |
Факсы ОУ |
|
- Не обрабатывается |
E-mail ОУ |
|
- |
Адрес сайта ОУ |
Веб-сайт |
- |
Номер государственной регистрации в ЕГРЮЛ (ОГРН) |
ОГРН |
- |
ИНН |
ИНН |
- |
КПП |
КПП |
- |
Субъект РФ |
Юридический адрес: Регион Юридический адрес: Страна |
- |
Адреса мест осуществления образовательной деятельности |
|
- Не обрабатывается |
Подчинение |
|
- Не обрабатывается |
3.8.
Форум
Данный раздел реализуется стандартным функционалом 1С-Битрикс: http://www.1c-bitrix.ru/products/cms/features/forums.php.
Форум должен быть отдельным модулем, тесно интегрированным с сайтом (автоматическая авторизация на форуме при авторизации на сайте, встройка в дизайн, аналогичное отображение профиля и т.п.)
Форум должен поддерживать:
· отображение списка пользователей на сайте онлайн с указанием дат рождения (без года)
· отображение профилей пользователей (см. раздел 3.1.2)
· отображение количества сообщений, оставленных пользователем рядом со ссылкой на его профиль
· форматирование жирным и курсивом при написании сообщений
· загрузку фото в сообщениях
· добавление видео с использованием iframe
· использование смайликов в сообщениях
· использование иконок в сообщениях и темах
У пользователя сайта должны быть следующие возможности:
· создание темы
· написание ответа в теме
· цитирование сообщения другого пользователя в теме при написании ответа в той же теме
У администратора сайта должны быть следующие возможности:
· создание, редактирование и удаление разделов форума
· назначение модераторов для выбранных разделов форума
· редактирование и удаление тем и сообщений пользователя в темах
· установка или снятие запрета для пользователя на создание тем и сообщений в форуме
У модератора сайта должны быть следующие возможности:
· редактирование и удаление сообщений пользователя в темах форума в тех разделах, на которые он назначен модератором
· установка или снятие запрета для пользователя на создание тем и сообщений в форуме в тех разделах, на которые он назначен модератором
3.9. Блоги
Модуль предоставляет возможность каждому пользователю вести свой дневник и читать дневники других пользователей.
Данный раздел реализуется стандартным функционалом 1С-Битрикс: http://www.1c-bitrix.ru/products/cms/features/blog.php.
Блог должен поддерживать отображение профилей пользователей (см. раздел 3.1.2).
У пользователя должны быть следующие возможности:
· создать свой блог
· создавать, редактировать и удалять записи в блоге
· оставлять комментарии к записям в своём и чужих блогах
· подписывать блоги в ленту и удалять их из ленты
· читать ленту, сформированную на основе добавленных в неё блогов
· фильтровать ленту по дате (выбирать дату, за которую он хочет просмотреть записи из подписанных блогов)
У администратора должна быть возможность:
· скрывать записи из любых блогов
· удалять записи из любых блогов
· скрывать любые блоги
· удалять любые блоги
3.10. Новости
В раздел выводятся новости (см. Таблица 42).
Таблица 42. Атрибуты новостей
Атрибут |
Обязательно |
Тип данных |
Описание |
Дата публикации |
Да |
Дата |
По умолчанию подставляется текущая дата |
Превью |
Да |
Изображение |
|
Изображение |
Да |
Изображение |
|
Заголовок |
Да |
Строка |
|
Анонс |
Да |
Текст |
|
Текст новости |
Да |
WYSWIG |
|
Активность |
Да |
Да/нет |
Определяет, отображается ли новость на сайте. По умолчанию «Да» |
Данный раздел реализуется стандартным функционалом 1С-Битрикс: http://www.1c-bitrix.ru/products/cms/features/infoblocks.php.
Управление списком новостей (добавление, удаление, редактирование) осуществляется с использованием CMS.
Отображение новостей осуществляется постранично по 20 элементов на страницу с сортировкой по дате публикации по убыванию с учётом всего объёма данных. В список выводятся дата публикации, превью, заголовок и анонс.
При клике по заголовку пользователь должен иметь возможность перейти на страницу новости. На странице новости должны показываться дата публикации, изображение, заголовок и текст новости.
3.11. Часто задаваемые вопросы
В раздел должен выводиться список заголовков страниц, заполняемых в CMS. Список должен быть отсортирован по приоритету. Каждый заголовок должен являться ссылкой на соответствующую страницу. У администратора в CMS должны быть возможность сформировать список часто задаваемых вопросов и страниц с ответами, а также задать приоритеты для сортировки. Каждая страница заполняется в CMS с использованием средств визуального редактирования.
На странице со списком вопросов и страницах, содержащих ответы на вопросы, должна присутствовать форма «Задать вопрос».
Таблица 43. Поля формы «Задать вопрос»
Поле |
Обязательно |
Тип данных |
Требования и порядок применения |
Тема |
Да |
Строка |
- |
Вопрос |
Да |
Текст |
- |
Обработка формы «Задать вопрос»
Все вопросы должны сохраняться в БД сайта и быть доступны для просмотра администратором.
3.12. Опросы
В раздел должен выводиться весь список опросов, проведённых или идущих в текущий момент на сайте. В списке опросов должен отображаться статус опроса (активный или архив).
Данный раздел реализуется стандартным функционалом 1С-Битрикс: http://www.1c-bitrix.ru/products/cms/features/polls.php.
У администратора в CMS должна быть возможность создать новый опрос или перевести в архив уже созданные опросы. Все создаваемые опросы по умолчанию должны являться активными.
В процессе создания/редактирования опроса у администратора должны быть возможности по редактированию атрибутов опроса (см. Таблица 44).
Таблица 44. Атрибуты опросов
Атрибут |
Обязательно |
Тип данных |
Описание |
Вопрос |
Да |
Строка |
|
Описание |
Да |
Текст |
|
Ответы |
Да |
Список (текст) |
У администратора должна быть возможность сформировать произвольный список из текстовых значений |
Дата завершения |
Да |
Дата |
|
Тип |
Да |
Список (значение) |
Один из вариантов опроса: - Один ответ - Множественный выбор |
При наступлении дня, следующего за датой завершения опроса,
необходимо закрывать пользователям возможность участия в опросе.
Каждый пользователь может голосовать только 1 раз.
На главной странице должен быть блок с опросом, в котором выводится информация по последнему активному опросу:
· если пользователь уже голосовал, ему должны быть показаны результаты опроса содержащие:
- перечень вариантов ответа;
- количество голосов, отданных за каждый вариант ответа;
- диаграмму, отражающую количество отданных голосов за каждый вариант ответа;
· если пользователь ещё не голосовал, у него должна быть возможность выбрать варианты ответа и отдать свой голос (с последующим обновлением блока опросов на главной странице).
3.13. Интервью
В данный раздел должен выводиться список проведённых интервью с руководителем ОУ или деканами факультетов. У пользователя должна быть возможность отфильтровать список по наименованию ОУ. Каждый элемент списка является ссылкой на соответствующую текстовую страницу. Каждая страница заполняется в CMS с использованием средств визуального редактирования.
3.14. Экспертное мнение
В данный раздел должен выводиться список мнений экспертов по определённым вопросам. Каждый элемент списка является ссылкой на соответствующую текстовую страницу. Каждая страница заполняется в CMS с использованием средств визуального редактирования.
3.15. Знаменитые люди
В данный раздел должен выводиться список знаменитых людей (см. Таблица 45).
Таблица 45. Атрибуты знаменитых людей
Атрибут |
Обязательно |
Тип данных |
Описание |
ФИО |
Да |
Строка |
При просмотре списка является ссылкой на соответствующую текстовую страницу |
Описание |
Да |
WYSWIG |
|
Фото |
Да |
Изображение |
|
ОУ |
Да |
Список (текст) |
Является ссылкой на ОУ |
4.
Требования к обеспечению сайта
4.1. Требования к информационному обеспечению сайта
Уровень хранения данных должен быть построен на основе современных реляционных или объектно-реляционных СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.
Доступ к данным должен быть предоставлен только авторизованным пользователям с учетом их прав доступа.
Структура базы данных должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в базе данных сайта.
Структура и механизмы взаимодействия с базой данных должны быть ориентированы на стандартные типы данных и использовать простой SQL (без учёта специфики конкретной СУБД), что позволит подключить любую СУБД из следующего списка:
· MySQL
· PostgreSQL
· MS SQL Server
· Oracle
4.2. Требования к лингвистическому обеспечению сайта
Все прикладное программное обеспечение системы для организации взаимодействия с пользователем должно использовать русский язык.
Все статические тексты, которые должны быть «зашиты» в код и использоваться на сайте, необходимо помещать с отдельный файл. Логику подключения такого файла необходимо программировать только в одном месте и таким образом, чтобы его можно было заменить на другой аналогичный файл путём добавления или изменения до 10 строк кода (например, для динамической смены языка сайта).
4.3. Требования к программному обеспечению сайта
Сайт должен быть разработан с использованием 1С-Битрикс: Управление сайтом.
В остальном используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах. На используемых серверах (см. раздел 4.4) должно быть установлено следующее программное обеспечение:
· Веб-сервер (рекомендуется Apache 2.x)
· Почтовый-сервер (на усмотрение разработчика)
· Защита от спама (на усмотрение разработчика)
4.4. Требования к аппаратному обеспечению сайта
Все сервера, используемые в архитектуре должны быть объединены одной локальной сетью, с пропускной способностью не менее 100 Мбит. Допускается использовать один сервер (для БД и веб) при соблюдении требований к показателям назначения (см. раздел 2.2).
Требования к техническим характеристикам серверов:
· Процессор – 2 х Intel Xeon 3 ГГц;
· Объем оперативной памяти – 16 Гб;
· Дисковая подсистема – 2 х 2 Тб;
· Сетевой адаптер – 100 Мбит.
Также на серверах должна быть поддержка бесплатного безлимитного трафика и возможность настроить резервное копирование по заданному расписанию.
К серверам должен быть предоставлен полный (удалённый) доступ с правами администратора.
Допускается арендовать сервер у соответствующих провайдеров при соблюдении требований настоящего раздела.
5. Подготовка сайта к вводу в действие
Перед запуском сайта необходимо:
· заполнить все справочники в CMS (см. раздел 3.7.3)
· настроить все шаблоны специальных страниц (см. раздел 2.9)
· настроить все шаблоны рассылаемых писем (см. раздел 2.10)
· провести первичный импорт ОУ (см. раздел 3.7.5)
· проанализировать возможные ошибки импорта (см. раздел 3.7.5)
· провести выверку базы ОУ на предмет корректности импорта (сопоставление ОУ, сопоставление справочников)
· смоделировать ситуации с автономным ведением файла ОУ (добавить новые ОУ, отредактировать и удалить несколько ОУ)
· при необходимости внести правки в код
· назначить ответственных модераторов и администраторов
· выделить экспертов
· заполнить содержимое всех страниц, где контент вносится только средствами CMS (новости, интервью, правила и т.п.)
6. Порядок приёмки сайта
При приёмке сайта всё должно соответствовать требованиям настоящего ТЗ. Сайт должен пройти опытную эксплуатацию в течение 2 рабочих недель. Заказчик должен выделить пользователей, которые будут осуществлять активное взаимодействие с сайтов и использование доступного им функционала, в том числе и использовать сайт, как представители ОУ (тестировать все возможные роли и ситуации). Все несоответствия и пожелания должны регистрироваться в соответствующей системе учёта задач, предоставленной Исполнителем.
В течение 5 рабочих дней после завершения опытной эксплуатации Исполнитель должен устранить все выявленные несоответствия и обновить код сайта, а Заказчик в течение 3 дней подтвердить, что все несоответствия устранены, принять сайт и оплатить проект в соответствии с договорённостями.
Все пожелания и несоответствия, не выявленные в ходе опытной эксплуатации должны устраняться в рамках следующего проекта по развитию сайта.
ООО «ВИКИТРЕВЕЛ» www.vikitravel.ru, www.викитревел.рф
ООО «БРИТАНСКИЕ-ТОВАРЫ» www.britishsouvenirs.ru, www.британские-товары.рф
[1] 24 часа в сутки, 7 дней в неделю. Т.е. всегда. Это следует учитывать при выборе хостинга.
[2] Допускается постраничный вывод информации.
[3] Без перезагрузки страницы.
[4] Без перезагрузки страницы.
[5] Далее: Все пользователи обозначаются в соответствии с типами. Пользователь типа «Гость» = Гость, Пользователь типа «Администратор» = Администратор и т.д.
[6] Возможность взаимодействовать через сайт (без использования панели управления CMS).
[7] У пользователя должна быть возможность пропустить заполнение данной формы
[8] Здесь, ранее и далее: при наличии соответствующих прав (см. раздел 3.1.4)
[9] Если ролей несколько, то берётся минимальный вес. Если ролей нет, то вес равен 1
[g1]Есть замечание, которое возможно было в ТЗ, но я не увидел: у представителя ОУ должна быть возможность изменения почты для поступления уведомлений о проблемах с его ОУ. (то есть в карточке ОУ одна почта, а для уведомлений может быть другая)
Да, учли это требование.
В карточке ОУ есть специальное поле «E-mail для уведомлений», которое должны быть видно только действующему подтверждённому официальному представителю ОУ
[g3]Нужна будет пояснялка для контент-менеджеров, чтобы им не путаться.
Cryptoboss Казино: Вход через актуальное зеркало за минуту - mp3monger.ru ...»
Казино Cryptoboss: Официальное зеркало для стабильного доступа - mp3monger.ru ...»
Казино Vodka Bet – популярный игрок на рынке онлайн-гемблинга ...»
dolgovita ...»