# Введение
## Цели
> В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.

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

**UML** **(Unified Modeling Language)** – унифицированный язык моделирования – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.

**RBAC** **(Role Based Access Control)**- Управление доступом на основе ролей — развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учётом специфики их применения, образуя роли.

**CMS** - Система управления контентом

**CRUD** - тут описание

**GraphQL** - тут описание

**OpenAPI** - тут описание

**REST API** - тут описание

**SPA** - тут описание

## Ссылки на источники
> В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.

# Общее описание
## Видение продукта
> В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.

## Функциональность продукта
> Тут мы пишем основные фичи проекта и в разделе System Features
- Модуль Авторизации;
- Модуль управления группами / учениками;
- Модуль Диагностики;
- Модуль Конструктора Профиля
- Модуль Хранилища Материалов
- Модуль Персонального Учебника
- Модуль Онбординга

## Инфраструктура
> Тут описаны все микросервисы, что делает, зачем это нужно и требования (для каждого сервиса и структуры в целом)

Приложение будет состоять из нескольких составных частей:

- **Server** - сервер,
- **DB** - база данных
- **Backend** - cерверная часть приложения
- запускается на сервере
- предоставление внешнего интерфейса **API**
- взаимодействия с **БД**
- взаимодействие с внешними сервисами
- рассылку **почты**
- **Frontend** - клиентская часть приложения
- запускается в браузере
- **CMS** - админка

## Операционная среда
> Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.

### Server
- nginx
- linux
- docker

### Backend
- **Node.js** (JavaScript / **TypeScript**)
- **Koa 2** / Express - Основная библиотека
- **Strapi** - Фреймворк построенный на Koa 2 и генераторах.
- Дает возможность быстро создавать сущности БД, их связи;
- Есть “админка”, визуальный интерфейс для разработчиков и методистов внутри команды;
- Весь системный контент и его управление будет создаваться при помощи этого инструмента;

### DB
**MongoDB** / **Postgres** - тут для нас нет особой разницы так как мы будем использовать типизацию на уровне серверной части приложения, однако MongoDB проще конечный выбор стека будет зависеть от опыта привлеченного в команду Backend-разработчика).

## Рамки, ограничения, правила и стандарты
> Данный раздел гнусный :). Он ограничивает полет мысли разработчика налагая стандарты разработки. Такими ограничениями могут быть, например, такие вещи:
> - **JavaScript** / TypeScript / Flow - Язык программирования
> - **mongo** / posgre - База данных
> - prettyfier - Стандарты кодирования
> - OpenAPI / GraphQL / REST - Стандарты обмена данными
> - RBAC
> - Ограничения накладываемые Operational Enviroment, допустим совместимость только с ФФ
> - Ограничения которые могут быть наложены бизнес-логикой проекта

## Документация пользователя
> Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.

OnBoarding??

# Функциональность системы

## Функциональный блок X (таких блоков может быть несколько)
> Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»

### Описание и приоритет
> Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения?.. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.

### Процессы
> Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор

### Функциональные требования
> Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд

# External interface requirements
> Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
- подгрузка школы и тд

# Не функциональные требования
> Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.

## Требования к производительности
> Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.

## Критерии качества программного обеспечения
> Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?
- Структура проекта по своим принципам соответствует современным стандартам и не сильно отличается от аналогов (Ruby on Rails / Django / Yii2 / Laravel / Spring MVC);
- Автоматически генерируемая документация (Open API / GraphQL / REST API / Swagger).
- **OpenAPI** (REST Api)
- **CRUD**
- Linter
- Documentation

## Требования к безопасности системы
> Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп

- Есть система управления доступом на основе ролей (RBAC);
- SSL
- Защита персональных данных

---

# Appendix A: Glossary
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.

# Appendix B: Analysis Models
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы

# Appendix C: Issues list
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.

# Общие требования

Тут описаны все микросервисы, что делает, зачем это нужно и требования (для каждого сервиса и структуры в целом)

Приложение будет состоять из нескольких составных частей:
- **Backend** - серверная часть приложения
- Frontend **SPA** - клиентская часть приложения
- **CMS** - админка
- **DataBase** - база данных
- **Server** - сервер

Общение между сервисами будет осуществляться по протоколу **https** посредством **API**

Требования:
- **GraphQL / REST API**
- **Open API**

## CI / CD (Сборка / Деплой)
Код должен храниться системой контроля версий **GitLab**. Сборка и деплой осуществляться посредством **GitLab piplines**.

# Сервисы
Подробнее о сервисах
## Backend (серверная часть приложения)
Серверная часть приложения, отвечающие за
- предоставление внешнего интерфейса **API**
- взаимодействия с **БД**
- взаимодействие с внешними сервисами
- рассылку **почты**
- миграции **БД**
- etc...

Это часть системы также будет поделена на несколько модулей, соответственно функциональным частям системы, например:
- Авторизация
- Конструктор заданий
- Диагностика
- Календарь занятий
- etc...

**Требования:**
- **OpenAPI** (REST Api)
- **CRUD**
- **RBAC**

**Стек:**
- **Node.js** (JavaScript / **TypeScript**) - Язык программирования
- **Koa 2** / Express - Основная библиотека
- **Strapi CDS** - Фреймворк

## CMS (Админка)
Визуальный интерфейс для управления серверной части приложения. Созданный для сотрудников компании (программистов / методистов / поддержки и тд)

**Стек:**
- **React** - библтотека
- **Next** - SSR Library
- **Strapi CDS** - Фреймворк

## Frontend SPA (Клиентская часть приложения)
Клиентская часть приложения, визуальный интерфейс отвечающий за интерфейс и взаимодействие конечного пользователя с системой, например:
- Личный кабинет **педагога**
- Личный кабинет **студента**
- Личный кабинет **родителя**

**SPA** будет взаимодействовать с **бекендом** по средствам **API**.

Это часть системы также будет поделена на **несколько** **модулей**, соответственно **функциональным** **частям** системы, например:
- Авторизация
- Конструктор заданий
- Диагностика
- Календарь занятий
- etc...

Также, совместно с дизайнером будет разработана **компонентная база**, набор атомарных частей из которых будет конструироваться приложение (кнопки / поля ввода / шрифты). За основу будет взята одна из популярных **UI** библиотек.

Стек:
- Vue / **React**
- JavaScript / **TypeScript**
- **GraphQL** / RestAPI
- **SCSS** / Stylus

## DataBase
База данных. Место где хранятся все данные.
- **MongoDB** / Postgres

## Server
Сервер на котором будет исполняться наше приложение.
- Linux (ubuntu 18.04 LTS)- операционная система
- **nginx**
- **Docker** / PM2
- SSL
- mydomain.ru
- teacher.mydomain.ru
- child.mydomain.ru
- teacher.mydomain.ru

## Analytics
* GA / YAM / etc...
* Redis / ClickHouse ??
* Sentry.IO ??

# Диаграмма взаимодейсвия

> coming
> soon

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

Бизнес-процессы (модули)
- Авторизация
- email / vk / fb / inst
- login / registration / reset pass
- Управление группами / учениками
- Управление диагностикой
- Конструктор профиля
- Персональный учебник

Относительно каждого модуля будет составлен отдельный документ со следующими данными:
- описание функционала
- структура БД
- Макет в ProtoPie

# Тестирование
????

# список ожидаемых изменений (что вообще может быть)

- Конструктор занятия
- Конструктор плана занятий
- ЛК Ребенка
- ЛК Родителя

# Риски и ограничения

# Структура БД
## Сущности
## Onboarding

## Роли
Что такое RBAC.
* Педагог
* Новичек
* Наблюдатель
* Сертифицированный
* Родитель
* Ученик
*
* Методист
* Админ

# RoadMap

# Общее описание
## Видение продукта
> В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.

## Функциональность продукта
> Тут мы пишем основные фичи проекта и в разделе System Features
- Модуль Авторизации;
- Модуль управления группами / учениками;
- Модуль Диагностики;
- Модуль Конструктора Профиля
- Модуль Хранилища Материалов
- Модуль Персонального Учебника
- Модуль Онбординга

## Инфраструктура
> Тут описаны все микросервисы, что делает, зачем это нужно и требования (для каждого сервиса и структуры в целом)
## Операционная среда
## Рамки, ограничения, правила и стандарты
## Документация пользователя

# Функциональность системы
## Функциональный блок X (таких блоков может быть несколько)
### Описание и приоритет
### Процессы
### Функциональные требования

# External interface requirements
> Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
- подгрузка школы и тд

# Не функциональные требования
## Требования к производительности
## Критерии качества программного обеспечения
## Требования к безопасности системы