Tech Spec Design Student portal

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

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

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

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

Главные задачи интерфейса:

• Обеспечить быструю навигацию по ежедневно используемым сервисам (расписание пар, успеваемость, долги).

• Упростить процесс заказа академических справок и загрузки учебных материалов (курсовые, лабораторные).

• Снизить количество ошибок при заполнении форм за счёт понятной валидации и подсказок.

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

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

1. Главный экран (Дашборд) Назначение: Быстрый обзор текущего учебного дня и важных событий.

Ключевые элементы:

• Виджет «Расписание на сегодня» (список пар, время, аудитория, статус: идет сейчас / следующая).

• Виджет «Ближайшие дедлайны» (сдача курсовых, тестов, лабораторных).

• Блок «Академический статус» (средний балл GPA, текущий семестр, отсутствие задолженностей).

• Лента последних уведомлений (изменения в расписании, новые оценки).

2. Экран «Расписание занятий» Назначение: Детальный просмотр графика занятий.

Ключевые элементы:

• Переключатель режимов отображения: День / Неделя / Семестр.

• Фильтры по типам занятий (лекция, практика, лабораторная, экзамен) и четности недели (числитель/знаменатель).

• Карточка занятия: название предмета, время, тип, ФИО преподавателя (с кликабельной ссылкой), номер аудитории/корпуса или кнопка «Подключиться» (для онлайн-пар).

3. Экран «Успеваемость и Зачётка» Назначение: Отслеживание оценок, баллов БРС (балльно-рейтинговой системы) и истории сессий.

Ключевые элементы:

• Переключатель семестров (выпадающий список или табы).

• Итоговый блок: средний балл за семестр, суммарный балл БРС.

• Интерактивная таблица дисциплин: название предмета, формат контроля (экзамен/зачёт), количество часов/ECTS, текущий балл, итоговая оценка.

• Цветовая индикация статусов: «Сдано» (зеленый), «Задолженность» (красный), «В процессе» (синий).

4. Экран «Заказ справок и документов» Назначение: Подача и отслеживание электронных заявок в деканат.

Ключевые элементы:

• Каталог доступных справок в виде карточек (справка об обучении, для налогового вычета, выписка оценок).

• Пошаговая форма (Modal / Stepper) заказа справки.

• Таблица «Мои заявки»: дата, тип документа, текущий статус («Создана», «В работе», «Готова к выдаче»), кнопка скачивания электронного образца (PDF).

5. Экран «Загрузка работ / Портфолио» Назначение: Отправка курсовых и лабораторных работ на проверку.

Ключевые элементы:

• Зона Drag-and-Drop для перетаскивания файлов (с указанием ограничений: PDF/DOCX, до 20 МБ).

• Прогресс-бар загрузки файла.

• История загрузок с указанием даты, версии файла и статуса проверки преподавателем.

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

Сценарий 1: Просмотр расписания на завтра с мобильного телефона

• Пользователь открывает: Приложение / веб-версию кабинета на смартфоне.

• Видит: Главный экран (Дашборд) с расписанием на сегодня.

• Вводит / выбирает: Нажимает на таб «Завтра» или свайпает виджет расписания влево.

• Получает результат: Карточки занятий на завтрашний день с четким указанием времени, аудиторий и типов предметов.

Сценарий 2: Подача заявки на справку об обучении

• Пользователь открывает: Раздел «Заказ справок».

• Видит: Список доступных справок и карточку «Справка об обучении в ВУЗе».

• Вводит / выбирает:

1. Нажимает «Заказать».

2. Во всплывающем окне выбирает количество экземпляров и способ получения (электронный PDF / бумажный в деканате).

3. Нажимает «Отправить заявку».

• Получает результат: Модальное окно с подтверждением «Заявка №1234 успешно создана». Заявка появляется вверху списка «Мои заявки» со статусом «В обработке».

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

Удобство использования (UX & UI):

• Концепция «Mobile First»: Интерфейс должен быть спроектирован с приоритетом под мобильные устройства, так как более 70% студентов заходят с телефонов.

• Минимализм и фокус: Соблюдение правила 3 кликов для доступа к ключевым функциям (расписание, зачётка, справки).

• Доступность (Accessibility):

Контрастность текста по стандарту WCAG 2.1 (уровень AA) для комфортного чтения.

Поддержка Темной темы (Dark Mode) для удобной работы в вечернее время.

Поддержка управления с клавиатуры и экранных дикторов (Screen Readers).

• Состояние элементов: Для всех интерактивных элементов (кнопки, поля ввода, карточки) должны быть прорисованы состояния: Default, Hover, Active, Focus, Disabled, Error.

Отображение на разных экранах (Breakpoints): Интерфейс должен быть полностью адаптивным и корректно отображаться на следующих разрешениях:

• Mobile: 360px – 480px (вертикальная ориентация).

• Tablet: 768px – 1024px.

• Desktop: 1280px, 1440px, 1920px и выше.

Требования к передаче макетов (Deliverables):

• Инструмент: Figma.

• Дизайн-система / UI Kit: Все компоненты (кнопки, инпуты, модальные окна, шрифты, цветовые палитры) должны быть вынесены в единую библиотека компонентов Figma (с использованием Auto Layouts, Components, Variants).

• Интерактивный прототип: Кликовые прототипы основных пользовательских сценариев для передачи фронтенд-разработчикам.

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

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

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

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

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

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

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

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

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

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