Tech Spec Design Schedule - moiaa/College_Management_System GitHub Wiki

Техническое задание на разработку дизайна модуля "Расписание"

Ниже — структура ТЗ (общий шаблон, см. также Getting Started). Команда заполняет каждый раздел своим содержанием; текст в квадратных скобках — подсказка, что писать, а не готовый ответ.

1. Назначение модуля

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

При входе в модуль “расписание” пользователь попадает на главный экран, который сразу дает ему полную картинку его графика. В центре экрана расположен календарь- это основное поле, где отображаются все события.
Каждое событие в расписании представлено в виде блока. В нем указанно событие, время начала и окончания, место проведения, а так же участники( например кто проводит событие и какие группы будут присутствовать). Сверху расположена панель управления. Там находятся фильтры, с помощью которых можно отобразить только нужные события. Рядом расположена строка поиска- по названию события или по имени участника. Это удобно когда расписание обьемное и сложно найти определенное событие. Пользователь в данном модуле выполняет набор действие, которые можно разделить на несколько групп. Самое основное действие это просмотр расписания. Далее он может искать и фильтровать увиденную информацию. Взаимодействует с событием и просматривает его подробности. Пользователь может получать уведомления и экспортируемые данные. Таким образом пользователь в модуле “расписание” не просто смотрит на список событий, а активно управляет своим временем.

2. Функциональные требования

2.1. Экраны и элементы интерфейса

[страница1- главный экран]

Назначение- отображение общего расписания пользователя на выбранный период. Элементы интерфейса;

переключение вида; день\ неделя\месяц
кнопки навигации; назад\вперед
сетка календаря с блоками собтий
линия текущего времени и подсветка “сейчас идет”
панель фильтров и строка поиска. [страница 2- карточка события ] Назначение; просмотр подробной информации о выбранном событии. Элементы интерфейса;
название события и его тип
дата, время начала и окончания
место проведения
описание
кнопки “редактировать” и ”удалить” ( для личных событий)
кнопка “закрыть”

[страница 3- фильтр и поиск]

Назначение; быстрый поиск нужных событий в расписании. Элементы интерфейса;

фильтр по типу события
фильтр по группе\месту
фильтр по периоду
срока поиска по названию
кнопка применить\сбросить

2.2. Пользовательские сценарии

Сценарий 1: [Просмотр расписания на неделю]

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

Сценарий 2: [Поиск конкретного события]

Пользователь открывает модуль "Расписание".
Видит строку поиска в верхней части экрана.
Вводит название события или имя преподавателя.
Видит отфильтрованный список подходящих событий.
Нажимает на нужное и открывается карточка события.
Получает результат: быстро нашел нужное занятие .

Сценарий 3: [Фильтрация событий]

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

Сценарий 4: [Переключение вида календаря]

Пользователь открывает модуль "Расписание".
Видит переключатель видов: "День"/"Неделя"/"Месяц" в верхней части экрана.
Нажимает "Месяц".
Видит обзор всего месяца с кратким отображением событий.
Нажимает "День" и видит подробное расписание на сегодня.
Получает результат: выбрал удобный формат просмотра.

3. Нефункциональные требования

Удобство использования:

Понятность- пользователь выполняет основные действия с первого раза, без обучения.
Эффективность- ключевые функции доступны на главном экране, в 1-2 клика.
Запоминаемость- расположение элементов понятно и предсказуемо.
Устойчивость к ошибкам - перед удалением запрашивается подтверждение, ошибка ввода подсвечивается прямо в поле.
Свобода действий- есть возможность отменить действие или сбросить фильтры.

Отображение на разных экранах:
Поддерживаемые браузеры: [требования, если есть]

4. Интерфейсы

4.1. Ожидаемые API Endpoints

Согласовывается с backend-командой этого же модуля до начала Модуля 2 — что это значит и как оформлять, см. 🔌 API-контракт. Этот раздел должен совпадать с разделом 4.1 в specification-backend.md того же модуля.

Метод	Endpoint	Зачем нужен (какому экрану/действию)
GET	`/api/v1/schedule/...`	[...]
POST	`/api/v1/schedule/...`	[...]

4.2. Макеты / вайрфреймы

[Ссылки на макеты (например, Figma) или эскизы экранов]

5. Критерии приёмки

Все экраны реализованы (frontend/schedule/)
Страницы реально обращаются к backend через согласованный контракт (не через захардкоженные данные)
Ошибки API показываются пользователю понятным сообщением, а не «падением» страницы
Раздел 4.1 согласован с specification-backend.md этого модуля (см. чек-лист в 🔌 API-контракт)
Pull Request создан и принят

6. Приложения

[Скриншоты готового интерфейса]