https://pastein.ru/t/T3B
Загрузка данных
ТЕХНИЧЕСКОЕ ЗАДАНИЕ (ТЗ)
на разработку системы «СУРВ-IT»
(Система учёта рабочего времени, отпусков и командировок для IT-компаний)
1. ОБЩИЕ СВЕДЕНИЯ
1.1. Полное наименование системы
Система учёта рабочего времени, отпусков и командировок для IT-компаний (с поддержкой удалённой и гибридной занятости).
1.2. Условное обозначение
СУРВ-IT
1.3. Шифр темы или номер договора
Определяется при подписании договора между заказчиком и разработчиком.
Шаблон: КИТЭК/СУРВ-IT/2026-001.
1.4. Заказчик
- Наименование: ООО «КИТЭК»
- Адрес: 27-я Северная ул., 69, Омск, 644073
- Контактное лицо: Шпраер Андрей Александрович (директор по IT / руководитель проекта со стороны заказчика)
- Телефон / e-mail: (указать при заключении договора)
1.5. Разработчик (предварительно)
- Наименование: определяется по итогам тендера / назначения
- Адрес: 5 Кордная, 59, Омск (базовый офис разработки)
- Контактное лицо: будет назначено после утверждения команды
1.6. Нормативно-техническая база
При создании системы используются следующие документы (уточнённый перечень):
| № | Тип документа | Назначение |
|---|---------------|-------------|
| 1 | Техническое задание (данный документ) | Базовое соглашение о целях, функциях и объёме |
| 2 | Спецификация требований к системе (SRS) | Детализация каждого функционального требования |
| 3 | Технический проект | Архитектура, выбор технологий, БД |
| 4 | Диаграммы UML (Use Case, Activity, Sequence, ERD) | Визуализация процессов и данных |
| 5 | План проекта (WBS, диаграмма Ганта) | Сроки, ресурсы, контрольные точки |
| 6 | Тестовая документация (тест-кейсы, чек-листы) | Подтверждение работоспособности |
| 7 | Документация по использованию системы (пользовательская и административная) | Эксплуатация |
| 8 | Документы по безопасности и защите данных (политика паролей, журналы, шифрование) | Соответствие 152-ФЗ (при обработке персональных данных) |
1.7. Плановые сроки
- Начало работ: 13 апреля 2026 г.
- Окончание разработки (готовность к опытной эксплуатации): 13 июля 2026 г.
- Промышленная эксплуатация: с 01 августа 2026 г.
- Гарантийное сопровождение: 3 месяца (до 01 ноября 2026 г.)
1.8. Источники финансирования
Собственные средства заказчика — ООО «КИТЭК».
1.9. Порядок оформления результатов
Результаты предъявляются в виде:
- работающего веб-приложения (доступ по HTTPS);
- исходного кода (репозиторий Git, переданный заказчику);
- развёрнутой базы данных (структура + тестовые данные);
- комплекта документации (электронные PDF/DOCX).
2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1. Назначение системы
Система предназначена для централизованного, прозрачного и автоматизированного учёта:
- фактически отработанного времени сотрудниками IT-компании (офис + удалёнка);
- всех видов отпусков (ежегодный, дополнительный, без сохранения содержания, учебный);
- служебных командировок (внутренних и зарубежных, с контролем сроков и оплаты).
Система не заменяет бухгалтерскую/зарплатную систему, но предоставляет данные для расчёта зарплаты и аналитики.
2.2. Цели создания системы
| № | Цель | Ожидаемый эффект |
|---|------|------------------|
| 1 | Исключить ручной учёт в Excel / Google Таблицах | Снижение ошибок на 80% |
| 2 | Обеспечить руководителям отдела и HR единый календарь отсутствий | Предотвращение коллизий (два сотрудника в отпуске одновременно в критический момент) |
| 3 | Автоматическое согласование заявок на отпуск и командировки | Сокращение времени согласования с 3 дней до 2 часов |
| 4 | Формирование аналитических отчётов по переработкам, невыходам, загрузке команд | Оптимизация штатной численности |
| 5 | Интеграция с корпоративным календарём (Outlook/Google) | Удобство планирования встреч |
| 6 | Соблюдение трудового законодательства РФ (ст. 91, 115, 166 ТК РФ) | Снижение юридических рисков |
2.3. Целевые показатели эффективности (KPI системы)
| Показатель | Целевое значение |
|------------|------------------|
| Время заполнения табеля на одного сотрудника в неделю | ≤ 2 минуты |
| Время получения отчёта по отпускам за месяц | ≤ 3 секунды |
| Доступность системы (uptime) | 99,5% (кроме плановых работ) |
| Максимальное количество одновременных пользователей | 100 (на старте), масштабируемо до 500 |
| Время реакции интерфейса (95% операций) | ≤ 1 секунда |
3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
3.1. Объект автоматизации
Объектом автоматизации являются бизнес-процессы ООО «КИТЭК», связанные с учётом персонала.
3.1.1. Перечень автоматизируемых процессов
1. Ежедневная регистрация прихода / ухода сотрудников (офис+удалёнка).
2. Внесение корректировок в отработанное время (опоздания, уходы раньше).
3. Создание и согласование заявок на отпуск.
4. Ведение графика отпусков (на год).
5. Создание и согласование заявок на командировки.
6. Формирование отчётов для бухгалтерии и HR.
7. Контроль остатков дней отпуска.
8. Контроль лимитов командировочных расходов (интеграция с будущей системой расходов — опционально).
3.2. Характеристика существующей организации труда (до автоматизации)
- Учёт времени — в Excel файлах, которые сотрудники заполняют еженедельно.
- Отпуска — заявки через e-mail, согласование директором/руководителем вручную.
- Командировки — приказ в 1С (не всегда своевременно).
- Отсутствует единая история отсутствий.
- HR тратит до 8 часов в месяц на сверку данных.
3.3. Условия эксплуатации
3.3.1. Платформа и совместимость
- Клиентская часть: любой современный браузер (последние 2 версии) — Google Chrome, Mozilla Firefox, Microsoft Edge, Safari (macOS/iPadOS).
- Серверная часть: Linux (Ubuntu 22.04 LTS) или Windows Server 2022 (на выбор заказчика, но рекомендуется Linux).
- Мобильные устройства: адаптивный веб-интерфейс для смартфонов (Android / iOS) — заявки на отпуск, просмотр графика.
3.3.2. Требования к аппаратному обеспечению (сервер минимальный)
| Компонент | Требование |
|-----------|-------------|
| CPU | 2 x86-64 ядра (2 ГГц), например Intel Xeon E5 или AMD EPYC |
| RAM | 8 ГБ (рекомендовано) или 4 ГБ (минимально для 20 пользователей) |
| Диск | SSD 50 ГБ (система + БД + логи) |
| Сеть | 100 Мбит/с, статический IP (или домен) |
3.3.3. Программное окружение
- СУБД: PostgreSQL 14+ или MySQL 8+
- Веб-сервер: Nginx (рекомендуется) или Apache
- Интерпретатор: PHP 8.1+ или Python 3.10+ (на этапе архитектуры утверждается стек)
- HTTPS-сертификат (Let's Encrypt или коммерческий)
3.3.4. Требования к безопасности данных (начальные)
- Все пароли хранятся в хешированном виде (bcrypt / Argon2).
- SSL/TLS 1.2+ обязателен для всех соединений.
- Доступ к системе только после аутентификации.
- Логирование всех критических действий (одобрение/отклонение заявок, изменение прав).
3.4. Характеристики окружающей среды
- Тип развертывания: на выделенном сервере заказчика (on‑premise) или в облаке Yandex Cloud / Selectel.
- Температурный режим для сервера: +10…+30 °C (стандарт офисного ЦОД).
- Влажность: 20%–80% без конденсата.
- Электропитание: рекомендуется источник бесперебойного питания с автономностью 15+ минут.
4. ТРЕБОВАНИЯ К СИСТЕМЕ
4.1. Требования к системе в целом
4.1.1. Архитектурные требования
- Микросервисная или модульная монолитная архитектура – допускается монолит с чёткими модулями (для простоты развёртывания).
- Модули:
- `auth` – аутентификация и управление доступом (RBAC).
- `time_tracking` – учёт рабочего времени.
- `vacation` – отпуска.
- `business_trip` – командировки.
- `reporting` – отчёты.
- `admin` – администрирование (справочники, пользователи).
- API – внутреннее REST API (для интеграции в будущем).
4.1.2. Интеграция с базой данных
- Использование ORM (Eloquent для Laravel / SQLAlchemy для Django).
- Поддержка миграций схемы данных.
- Автоматическое резервное копирование БД (cron + скрипты) с ротацией (7 ежедневных, 4 еженедельных).
4.1.3. Графический интерфейс пользователя (UI/UX требования)
- Навигация в виде бокового меню (для сотрудника, руководителя, HR).
- Календарный вид для отпусков и командировок.
- Формы с валидацией полей.
- Поддержка тёмной и светлой темы (опционально).
- Адаптивность: сетка 12 колонок, шрифты не менее 14px на мобильных.
4.1.4. Контроль остатков и лимитов
- Автоматический пересчёт остатка дней отпуска на начало каждого года.
- Учёт неиспользованных дней переносится на следующий год (если не противоречит локальному акту).
- Лимит дней командировок в год (например, 30 дней) – опционально, настраивается администратором.
4.2. Требования к функциям системы (детализация по ролям)
4.2.1. Ролевая модель
| Роль | Права |
|------|-------|
| **Сотрудник** | Просмотр своего графика, создание заявок на отпуск/командировку, отметка прихода/ухода (вручную или по кнопке), просмотр своего остатка отпуска, редактирование своих заявок до согласования |
| **Руководитель отдела** | Всё, что у сотрудника + согласование/отклонение заявок подчинённых, просмотр календаря отсутствий отдела, создание отчётов по отделу |
| **HR / Администратор системы** | Всё, что у руководителя + управление сотрудниками (добавление/блокировка), настройка норм рабочего времени, импорт/экспорт данных по всем сотрудникам, просмотр всех отчётов |
| **Администратор БД / IT** (отдельная роль) | Доступ к настройкам сервера, резервным копиям, восстановлению, просмотр логов |
4.2.2. Функциональные требования: учёт рабочего времени
| ID | Требование | Приоритет |
|----|------------|------------|
| TR-01 | Сотрудник может отметить начало и окончание рабочего дня (кнопкой «Пришёл» / «Ушёл»). Система фиксирует время с точностью до минуты. | Высокий |
| TR-02 | Возможность ручного ввода отработанных часов (при удалённой работе без интернета) с комментарием. Изменения проходят согласование с руководителем. | Высокий |
| TR-03 | Система автоматически рассчитывает норму часов за день (по графику: 5/2, 40 часов в неделю). Переработка помечается особым цветом. | Высокий |
| TR-04 | Руководитель может скорректировать время подчинённого (исправление ошибок, опозданий). Каждая корректировка логируется. | Средний |
| TR-05 | Возможность прикрепить подтверждающий документ (скриншот, фото пропуска) к событию времени. | Низкий |
4.2.3. Функциональные требования: отпуска
| ID | Требование |
|----|------------|
| VA-01 | Сотрудник создаёт заявку на отпуск с указанием дат начала и окончания, типа отпуска (ежегодный, за свой счёт, учебный). |
| VA-02 | Система проверяет остаток дней отпуска перед отправкой на согласование. Если недостаточно – блокирует отправку с уведомлением. |
| VA-03 | Заявка последовательно согласуется: руководитель отдела → HR (опционально). У каждого этапа есть таймаут 48 часов, по истечении – автоматическое напоминание. |
| VA-04 | Одобренные отпуска автоматически попадают в корпоративный календарь (экспорт iCal). |
| VA-05 | HR может вручную списать дни отпуска (например, без заявки, по заявлению на бумаге). |
4.2.4. Функциональные требования: командировки
| ID | Требование |
|----|------------|
| BT-01 | Создание заявки на командировку: город, даты, цель, планируемые расходы. |
| BT-02 | Одобрение руководителем, после чего формируется номер приказа (форма Т-9). |
| BT-03 | Дни командировки не считаются отпуском, но исключаются из табеля как «К» (командировка). |
| BT-04 | Возможность прикрепить сканы билетов, гостиничных чеков (для последующего авансового отчёта). |
4.2.5. Отчётность (обязательные отчёты)
| Отчёт | Содержание |
|-------|-------------|
| Табель учёта рабочего времени (форма Т-13) | За месяц по сотруднику или отделу в разрезе дней (явка, отпуск, командировка, больничный, прогул) |
| Остатки отпусков | На текущую дату с учётом утверждённых заявок |
| Календарь отпусков и командировок | Годовой план отсутствий |
| Сводка по переработкам | Суммарно за период (месяц, квартал) |
| Экспорт в Excel / PDF | Все отчёты должны выгружаться в двух форматах |
4.2.6. Функциональные требования: учёт временной нетрудоспособности (больничные листы)
| ID | Требование | Приоритет |
|----|------------|------------|
| SL-01 | Сотрудник или HR может зарегистрировать больничный лист с указанием периода (дата начала и окончания), номера листа нетрудоспособности (опционально). | Средний |
| SL-02 | Система автоматически исключает дни больничного из отработанного времени и не учитывает их в переработках. | Средний |
| SL-03 | При пересечении больничного с ранее согласованным отпуском — отпуск автоматически прерывается, неиспользованные дни возвращаются в остаток (с уведомлением сотрудника и руководителя). | Средний |
| SL-04 | Отчёт «Табель» отображает дни больничного кодом «Б». | Высокий |
| SL-05 | Возможность загрузить скан электронного больничного (для архива). | Низкий |
4.2.7. Функциональные требования: настройки и справочники
Система должна предоставлять администратору (HR/IT) возможность настройки следующих параметров:
| Параметр | Описание |
|----------|----------|
| **Графики работы** | 5/2 (40 ч), 5/2 (36 ч), 6/1, сменный график, индивидуальный график (настраивается для каждого сотрудника). |
| **Норма рабочих часов** | За день, неделю, месяц (с учётом праздников – ручной импорт производственного календаря). |
| **Типы отпусков** | Ежегодный основной (28 дней), дополнительный (за вредность/ненормированный), без сохранения содержания, учебный, по уходу за ребёнком. |
| **Лимиты командировок** | Максимальное количество дней в год, суточные (информационно). |
| **Пороги согласования** | Количество уровней согласования (1 или 2), таймаут напоминания (часы). |
| **Роли и права** | Назначение руководителей отделов, смена HR-администратора. |
**Требования к импорту производственного календаря:**
- Поддержка загрузки файла в формате CSV / XLSX со структурой: дата, тип дня (рабочий, выходной, предпраздничный сокращённый).
- При отсутствии загрузки – система использует встроенный алгоритм (суббота/воскресенье – выходной).
4.2.8. Интеграционные требования
| ID | Требование | Приоритет |
|----|------------|------------|
| INT-01 | Экспорт утверждённых отпусков и командировок в формате iCal (подписка через URL). Пользователи смогут добавить календарь в Outlook, Google Календарь, Apple Calendar. | Высокий |
| INT-02 | Импорт сотрудников из корпоративного справочника (Active Directory / LDAP или CSV-файл). Поддерживается синхронизация: ФИО, email, должность, отдел, руководитель. | Средний |
| INT-03 | Экспорт табеля учёта рабочего времени за месяц в формат, совместимый с 1С:ЗУП (XML / XLSX по шаблону заказчика). | Высокий |
| INT-04 | REST API для внешних систем (чтение графика отсутствий сотрудника, запись события прихода/ухода). API документируется (Swagger/OpenAPI). | Низкий (в версии 2.0) |
| INT-05 | Webhook при изменении статуса заявки (одобрено/отклонено) – для интеграции с Telegram / Slack / корпоративным чатом (опционально). | Средний |
### 4.3. Требования к видам обеспечения
#### 4.3.1. Программное обеспечение
**Серверное ПО (стек на выбор разработчика, утверждаемый заказчиком):**
| Компонент | Рекомендованный вариант | Альтернативный вариант |
|-----------|------------------------|------------------------|
| Операционная система | Ubuntu 22.04 LTS | Windows Server 2022 |
| Веб-сервер | Nginx 1.24+ | Apache 2.4+ |
| СУБД | PostgreSQL 15+ | MySQL 8+ |
| Интерпретатор / среда | PHP 8.2 + Laravel 10 | Python 3.11 + Django 4 |
| Кэширование | Redis 7+ | Memcached |
| Фоновые задачи | Laravel Queue / Supervisor | Celery (для Django) |
**Клиентское ПО:**
- Браузер: последние версии Chrome, Firefox, Edge, Safari (на мобильных — аналоги).
- Не требуется установка дополнительных плагинов (кроме разрешения на JavaScript, cookies, localStorage).
**Инструменты разработки и контроля версий (для передачи заказчику):**
- Git-репозиторий (GitLab или GitHub).
- Docker-сборка для локального развёртывания (опционально, но приветствуется).
#### 4.3.2. Аппаратное обеспечение
**Для пилотной эксплуатации (до 50 активных сотрудников):**
| Сервер | CPU | RAM | Диск | Сеть |
|--------|-----|-----|------|------|
| Приложение + БД | 2 vCPU | 4 GB | SSD 40 GB | 100 Mbps |
**Для промышленной эксплуатации (до 200 сотрудников, плановое масштабирование):**
| Сервер | CPU | RAM | Диск | Примечание |
|--------|-----|-----|------|-------------|
| Веб/приложение | 4 vCPU | 8 GB | SSD 50 GB | Можно отдельно |
| БД | 4 vCPU | 8 GB | SSD 100 GB | Отдельная ВМ или контейнер |
| Резервное копирование | 1 vCPU | 2 GB | HDD 200 GB | NAS или облако |
**Клиентские рабочие места:**
- Минимальные: любой ПК с разрешением 1024x768, 1 ГБ свободной RAM для браузера.
- Рекомендуемые: 1920x1080, 4 ГБ RAM, подключение к интернету от 1 Мбит/с.
#### 4.3.3. Телекоммуникационные требования
- Доступ к веб-серверу по HTTPS (порт 443) из внутренней сети компании и (при необходимости удалённой работы) через VPN или публичный IP с ограничением по IP-адресам.
- Внутри локальной сети допускается HTTP (порт 80) с автоматическим редиректом на HTTPS.
- Сервер должен иметь синхронизированное время (NTP).
#### 4.3.4. Информационное обеспечение (данные)
- Структура базы данных нормализована (3 нормальная форма).
- Обязательные справочники: сотрудники, отделы, должности, типы отпусков, типы командировок, графики работы.
- Хранение истории изменений всех заявок (кто, когда, какое действие).
- Журнал авторизаций (успешные/неудачные попытки).
### 4.4. Требования к надёжности, безопасности и производительности
#### 4.4.1. Надёжность
| Параметр | Значение |
|----------|----------|
| Время наработки на отказ (MTBF) | ≥ 720 часов (30 дней) |
| Время восстановления после отказа (MTTR) | ≤ 2 часа (регламентированное) |
| Доступность (Uptime) | 99,5% в месяц (допустимо не более 3,6 часов простоя) |
| Резервное копирование | Ежедневно в 02:00, хранение 30 дней. Автоматическая проверка целостности бэкапа раз в неделю. |
| План восстановления | Документирован: восстановление из бэкапа на том же или новом сервере за 4 часа. |
#### 4.4.2. Безопасность (развёрнуто)
**Аутентификация:**
- Минимальная длина пароля — 8 символов (буквы в разных регистрах, цифры, спецсимволы — рекомендация).
- Блокировка учётной записи на 15 минут после 5 неудачных попыток ввода пароля.
- Поддержка двухфакторной аутентификации (TOTP) — опционально (для администраторов).
**Разграничение доступа (RBAC):**
- Каждый запрос к API/странице проверяет права на уровне контроллера.
- Отсутствие доступа к чужим данным (сотрудник не видит график другого сотрудника, если нет роли руководителя).
**Защита данных:**
- Все соединения — TLS 1.2/1.3.
- Пароли хранятся в БД с использованием bcrypt (cost factor 10+).
- Персональные данные (ФИО, email) обрабатываются в соответствии с 152-ФЗ. Заказчик обеспечивает правовое основание.
**Логирование аудита:**
- Логируются: вход/выход, создание/изменение/удаление заявок, изменение остатков, изменение прав, экспорт отчётов.
- Логи хранятся 12 месяцев, защищены от подделки.
#### 4.4.3. Производительность (нагрузочные требования)
| Сценарий | Время отклика (95 перцентиль) | Требование |
|----------|-------------------------------|-------------|
| Открытие дашборда сотрудника | ≤ 1.5 с | Без тяжёлых отчётов |
| Сохранение заявки на отпуск | ≤ 1 с | С проверкой остатка |
| Формирование табеля за месяц по отделу (30 человек) | ≤ 3 с | В пилотной версии |
| Одновременная работа пользователей | 50 чел. (пилот) / 200 чел. (пром) | Без деградации более чем на 20% |
**Пороги нагрузки:**
- Система должна корректно работать при 100 запросах в минуту к API отчётов.
### 4.5. Требования к пользовательскому интерфейсу (UI/UX)
#### 4.5.1. Общие принципы
- Единый стиль оформления (фирменные цвета заказчика – согласовываются на этапе макетирования).
- Навигация: левое вертикальное меню (свёртываемое на мобильных).
- Хлебные крошки (breadcrumbs) на всех страницах, кроме главной.
- Поддержка русского и английского языков (переключатель) – опционально, но приветствуется.
#### 4.5.2. Экран «Мой табель» (сотрудник)
- Отображение текущего месяца в виде сетки (календарь).
- Каждая ячейка: число, тип дня (рабочий/выходной), фактическое время (часы), отметка о приходе/уходе.
- Кнопка «Отметить приход» и «Отметить уход» (с подтверждением).
- Возможность добавить комментарий к дню (например, «удалёнка»).
#### 4.5.3. Экран «Заявки на отпуск»
- Список своих заявок (статус: черновик, на согласовании, одобрена, отклонена).
- Кнопка «Новая заявка» → форма: тип отпуска, даты, комментарий.
- Калькулятор дней отпуска (автоматический подсчёт количества календарных/рабочих дней в зависимости от типа).
- Отображение текущего остатка дней до отправки.
#### 4.5.4. Экран «Календарь отсутствий» (руководитель, HR)
- Календарь (месяц/неделя) с цветовой индикацией: отпуск (зелёный), командировка (синий), больничный (серый).
- Фильтр по отделам / сотрудникам.
- При клике на событие – всплывающая карточка с деталями (ФИО, даты, статус согласования).
#### 4.5.5. Экран «Согласование заявок» (руководитель)
- Список входящих заявок на согласование (отпуска, командировки).
- Кнопки: «Одобрить», «Отклонить» (с обязательным комментарием при отклонении).
- Возможность массового согласования (выбрать несколько и нажать «Одобрить»).
#### 4.5.6. Экран «Отчёты» (HR, руководитель)
- Выбор типа отчёта (табель, остатки отпусков, сводка по переработкам).
- Выбор периода (месяц, квартал, год, произвольный интервал).
- Выбор формата выгрузки (на экран, Excel, PDF).
- Кнопка «Сформировать» – асинхронно (при большом объёме – прогресс-бар).
#### 4.5.7. Адаптивная мобильная версия
- Для экранов шириной до 768px меню превращается в гамбургер-меню.
- Календарь отображается в упрощённом виде (список дней).
- Кнопки достаточно крупные (44x44 pt для касания).
---
## 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ
### 5.1. Общая структура работ
| Этап | Наименование | Длительность (рабочие дни) |
|------|--------------|----------------------------|
| 1 | Анализ требований и утверждение концепции | 5 дн. |
| 2 | Проектирование (архитектура, БД, прототипы интерфейса) | 10 дн. |
| 3 | Разработка (спринты по 2 недели) | 40 дн. |
| 4 | Тестирование и отладка (включая нагрузочное и безопасность) | 15 дн. |
| 5 | Документирование | 10 дн. |
| 6 | Внедрение и обучение | 5 дн. |
| 7 | Опытная эксплуатация и приёмка | 10 дн. |
| 8 | Гарантийное сопровождение (3 месяца) | параллельно |
### 5.2. Этап 1. Анализ требований
**Цель:** сформулировать и утвердить полный перечень функциональных и нефункциональных требований.
**Работы:**
1. Проведение интервью с заинтересованными лицами (HR, руководители отделов, директор, бухгалтерия).
2. Анализ текущих процессов (Excel-табели, бумажные заявки).
3. Определение ролей и прав доступа.
4. Формирование спецификации требований к системе (SRS) в виде таблицы с приоритетами (Must have / Should have / Could have).
5. Согласование SRS с заказчиком.
**Результат этапа:**
- Утверждённая SRS (подписанная сторонами).
- Диаграмма вариантов использования (UML Use Case).
- План проекта с вехами (WBS).
**Критерий приёмки:** заказчик подтвердил, что требования покрывают все его ключевые бизнес-процессы.
### 5.3. Этап 2. Проектирование системы
**Цель:** создать техническую документацию, достаточную для начала разработки.
**Работы:**
- Проектирование логической и физической модели базы данных (ER-диаграмма).
- Выбор технологического стека (утверждение с заказчиком).
- Разработка архитектуры приложения (модули, взаимодействие).
- Создание прототипов экранов (макеты UI в Figma или аналогичном инструменте).
- Утверждение дизайн-системы (цвета, шрифты, отступы, компоненты).
- Документирование API (если планируется) в формате OpenAPI.
**Результат этапа:**
- Технический проект (PDF) включая:
- ER-диаграмму.
- Схему развёртывания (деплоймент-диаграмму).
- Макеты всех основных экранов.
- Утверждённый прототип интерфейса (кликабельный макет).
**Критерий приёмки:** заказчик протестировал макеты на соответствие сценариям использования.
### 5.4. Этап 3. Разработка (итерационная)
Разработка ведётся спринтами по 10 рабочих дней (2 недели). Каждый спринт включает анализ, реализацию, внутреннее тестирование.
**Спринт 1 (фундамент)**
- Настройка репозитория, CI/CD (если требуется).
- Создание каркаса приложения (маршруты, шаблоны).
- Реализация аутентификации и ролевой модели (RBAC).
- Базовое администрирование (справочники сотрудников, отделов).
**Спринт 2 (учёт рабочего времени)**
- Функционал отметки прихода/ухода.
- Календарь сотрудника.
- Ручной ввод часов с согласованием.
- Контроль нормы часов.
**Спринт 3 (отпуска)**
- Создание заявок на отпуск.
- Проверка остатков.
- Маршрут согласования.
- Календарь отпусков (для руководителя).
- Отображение остатков отпуска у сотрудника.
**Спринт 4 (командировки и больничные)**
- Заявки на командировки, согласование.
- Отражение в календаре и табеле.
- Учёт больничных листов.
- Экспорт iCal.
**Спринт 5 (отчёты и интеграции)**
- Табель Т-13.
- Отчёт по остаткам отпусков.
- Отчёт по переработкам.
- Экспорт Excel/PDF.
- Экспорт в 1С (формирование файла).
- REST API (базовое).
**Спринт 6 (доработки и полировка)**
- Улучшение интерфейса (адаптивность).
- Исправление ошибок, найденных при внутреннем тестировании.
- Настройка резервного копирования и логов.
**Результат этапа:** рабочая версия системы, развёрнутая на тестовом сервере, доступная для внутреннего тестирования разработчиком и заказчиком.
### 5.5. Этап 4. Тестирование и отладка
| Тип | Методика | Инструменты (пример) |
|-----|----------|----------------------|
| Модульное (unit) | Тестирование каждого метода/функции | PHPUnit / pytest |
| Интеграционное | Проверка взаимодействия модулей | Постман (API) |
| Функциональное (ручное) | Прохождение всех user story | Тест-кейсы в TestRail / Qase |
| Нагрузочное | Имитация 50-100 одновременных пользователей | JMeter / k6 |
| Безопасности | Проверка OWASP Top 10 (SQLi, XSS, CSRF) | ZAP, ручной аудит |
| UI/UX | Удобство интерфейса, соответствие макетам | Экспертная оценка |
| Совместимости | Браузеры: Chrome, Firefox, Edge, Safari (мобильная версия) | Вручную |
**Результат этапа:**
- Отчёт о тестировании (перечень найденных дефектов с приоритетами).
- Исправление всех критических и высокоприоритетных ошибок.
- Система готова к опытной эксплуатации (релиз-кандидат).
### 5.6. Этап 5. Документирование
**Состав документации:**
1. **Техническая документация (для IT-отдела заказчика):**
- Архитектура приложения (компоненты, потоки данных).
- Инструкция по развёртыванию на сервере (пошаговая).
- Схема базы данных (описание таблиц).
- Инструкция по резервному копированию и восстановлению.
- Описание API (если реализовано).
2. **Пользовательская документация (для сотрудников, руководителей, HR):**
- Краткое руководство (2-3 страницы) для всех ролей.
- Подробное руководство с картинками (отдельно для каждой роли).
- Часто задаваемые вопросы (FAQ).
3. **Тестовая документация (передаётся заказчику для проведения приёмочных испытаний):**
- Приёмочные тест-кейсы (покрытие всех требований из SRS).
- Чек-лист для приёмочного тестирования.
**Формат документов:** PDF (для чтения) + исходные DOCX (при необходимости).
### 5.7. Этап 6. Внедрение и обучение
- Установка системы на целевой сервер заказчика (или облачную среду).
- Начальное заполнение справочников (сотрудники, отделы, руководители).
- Интеграция с Active Directory (если требуется – вручную или автоматически).
- Проведение обучающего вебинара (1 час) для сотрудников, руководителей и HR.
- Запись обучающего видео (скринкаст) с базовыми действиями.
- Предоставление инструкций в печатном/электронном виде.
**Результат:** система запущена в опытную эксплуатацию, пользователи прошли обучение.
### 5.8. Этап 7. Опытная эксплуатация и приёмка
**Длительность:** 10 рабочих дней (2 календарных недели).
**Порядок:**
- В опытной эксплуатации участвуют не менее 10 сотрудников (включая руководителей и HR).
- Фиксируются все замечания (в трекере задач – Jira, Trello или таблице).
- Разработчик в течение 48 часов исправляет критические ошибки.
- По истечении 10 дней формируется акт о результатах опытной эксплуатации.
**Критерий перехода к промышленной эксплуатации:**
- Нет открытых критических ошибок (блокирующих работу).
- Заказчик подтверждает, что система соответствует требованиям.
### 5.9. Этап 8. Гарантийное сопровождение (3 месяца)
**Обязательства разработчика в гарантийный период:**
- Бесплатное исправление любых ошибок в системе, возникших не по вине заказчика.
- Консультации по эксплуатации (по e-mail или мессенджеру, время реакции – 1 рабочий день).
- Устранение критических ошибок в течение 24 часов.
- Предоставление патчей без остановки системы (если возможно).
**Не входит в гарантию:**
- Доработки нового функционала (оцениваются отдельно).
- Сбои, вызванные неправильной работой серверного ПО или сетевой инфраструктуры заказчика.
---
## 6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
### 6.1. Общие положения
Приёмка системы осуществляется поэтапно и окончательно.
Контроль качества включает: проверку документации, функциональное тестирование, проверку производительности и безопасности.
**Участники приёмки:**
- Со стороны заказчика: Шпраер Андрей Александрович (или уполномоченное лицо), HR-менеджер, руководитель IT (при наличии).
- Со стороны разработчика: руководитель проекта, ведущий разработчик, тестировщик.
### 6.2. Этапы контроля и приёмки
| Этап | Что проверяется | Документ по итогу |
|------|----------------|-------------------|
| Приёмка этапа «Анализ требований» | SRS утверждена, диаграммы согласованы | Протокол согласования |
| Приёмка этапа «Проектирование» | Технический проект, макеты интерфейса | Акт приёмки проектной документации |
| Приёмка этапа «Разработка» (по спринтам) | Демонстрация рабочего инкремента заказчику | Протокол демонстрации (e-mail подтверждение) |
| Приёмка этапа «Тестирование» | Отчёт об исправленных ошибках, система стабильна | Отчёт о тестировании |
| Приёмка этапа «Документирование» | Полнота и качество документации | Акт передачи документации |
| Приёмка опытной эксплуатации | Система отработала 10 дней без критических сбоев | Акт опытной эксплуатации |
| **Окончательная приёмка** | Все пункты ТЗ выполнены, система введена в действие | **Акт сдачи-приёмки работ** |
### 6.3. Критерии качества для окончательной приёмки
Система считается принятой, если выполнены **все** следующие условия:
1. **Полнота функций:** Реализованы все требования с приоритетом «Высокий» и «Средний» из раздела 4.2 (более 95% тест-кейсов успешно пройдено).
2. **Стабильность:** В ходе опытной эксплуатации не произошло ни одного сбоя, приведшего к потере данных или недоступности системы более 1 часа.
3. **Производительность:** Время отклика интерфейса при одновременной работе 50 пользователей (на эталонном сервере) не превышает порогов из п. 4.4.3.
4. **Безопасность:** Отсутствуют критические уязвимости (SQL-инъекции, XSS, подделка межсайтовых запросов, обход аутентификации).
5. **Документация:** Передана в полном объёме, пользователи могут выполнять операции, следуя инструкциям.
6. **Обучение:** Проведено, не менее 90% опрошенных пользователей могут самостоятельно создать заявку на отпуск.
### 6.4. Процедура приёмочных испытаний
1. **Подготовка тестовой среды** – заказчик предоставляет доступ к среде, приближенной к промышленной (или разработчик разворачивает демо-стенд).
2. **Проведение тестирования по предварительно согласованному чек-листу** (см. приложение к ТЗ – «Приёмочные тест-кейсы»).
3. **Фиксация результатов** – заполняется протокол испытаний (таблица: тест-кейс, ожидаемый результат, фактический результат, отметка о прохождении).
4. **Если все тест-кейсы пройдены успешно** – подписывается Акт сдачи-приёмки.
5. **Если есть отклонения** – составляется перечень дефектов с указанием сроков исправления (не более 5 рабочих дней). После исправления проводится повторное тестирование только по непройденным пунктам.
### 6.5. Особые условия приёмки
- Заказчик имеет право отказаться от приёмки, если система содержит критический дефект, делающий невозможным выполнение хотя бы одной основной функции (учёт времени, создание отпуска, формирование табеля).
- Подписание Акта сдачи-приёмки означает переход системы в промышленную эксплуатацию и начало гарантийного периода.
---
## 7. ТРЕБОВАНИЯ К ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ
### 7.1. Ответственные и исполнители
| Мероприятие | Исполнитель | Срок (до даты ввода) |
|-------------|-------------|----------------------|
| Проверка аппаратного обеспечения (сервер, сеть) | IT-специалист заказчика | за 10 дней |
| Установка операционной системы и необходимого ПО (СУБД, веб-сервер) | Заказчик (или разработчик по договорённости) | за 7 дней |
| Настройка сетевого доступа (HTTPS, брандмауэр, DNS) | Заказчик | за 7 дней |
| Установка и настройка системы СУРВ-IT | Разработчик | за 3 дня |
| Контрольная проверка работоспособности | Разработчик + заказчик | за 2 дня |
| Загрузка начальных данных (сотрудники, отделы, остатки отпусков) | Заказчик (HR) при поддержке разработчика | за 2 дня |
| Обучение пользователей (вебинар, инструкции) | Разработчик | за 1 день |
| Назначение ответственных за эксплуатацию (администратор системы) | Заказчик | до дня ввода |
| Подписание акта готовности к вводу | Заказчик | в день ввода |
### 7.2. Детализация ключевых мероприятий
#### 7.2.1. Подготовка аппаратного и системного ПО (со стороны заказчика)
- Убедиться, что сервер соответствует минимальным требованиям (раздел 4.3.2).
- Установить ОС (Ubuntu 22.04 / Windows Server 2022) и настроить автоматические обновления безопасности.
- Настроить файрвол (разрешить порты 80, 443, 22 (SSH) с ограничением по IP).
- Обеспечить наличие сертификата SSL (можно Let’s Encrypt).
- Назначить учётную запись для развёртывания (не root).
- Настроить ежедневное резервное копирование всей системы (на уровне гипервизора или отдельный скрипт). Разработчик предоставит скрипты для БД.
#### 7.2.2. Подготовка персонала и организационных данных (заказчик)
- Назначить системного администратора (или ответственного за поддержку).
- Подготовить список сотрудников (ФИО, email, должность, отдел, руководитель).
- Подготовить данные по остаткам отпусков на начало текущего года или на дату внедрения.
- Определить производственный календарь на текущий и следующий год (праздничные дни).
#### 7.2.3. Действия разработчика при внедрении
- Развернуть код и БД на сервере заказчика.
- Выполнить миграции и загрузить начальные справочники.
- Настроить права доступа (минимум – администратор системы от заказчика получает полные права).
- Провести дымовое тестирование (проверить логин, создание заявки, просмотр отчёта).
- Передать пароли администратору в защищённом виде (после смены временного пароля).
### 7.3. Формальный акт готовности
Перед началом промышленной эксплуатации составляется **«Акт готовности объекта автоматизации к вводу системы в действие»** по следующей структуре:
- Перечень проверенных пунктов (железо, ПО, данные, обучение).
- Отсутствие замечаний, препятствующих запуску.
- Подписи: представитель заказчика (Шпраер А.А.) и руководитель разработки.
**Без подписанного акта система не переводится в промышленную эксплуатацию.**
### 7.4. План на случай сбоев при вводе
- **Резервная среда:** Заказчик может сохранить старые процессы (Excel) как запасной вариант на первые 2 недели.
- **Откат:** Разработчик предоставляет инструкцию по откату к предыдущей версии (или удалению системы с сохранением данных).
- **Точка контакта:** Назначенный инженер разработчика доступен в рабочие дни (10:00–18:00 по Омску) в первую неделю после ввода.
---
## 8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
### 8.1. Общие требования к документации
- Все документы предоставляются в электронном виде (PDF и исходный формат DOCX/ODT).
- Документация должна быть структурированной, иметь оглавление, нумерацию страниц, версию и дату последнего изменения.
- Язык документации — русский. Допускается использование английских терминов (API, UI, RBAC) с пояснением при первом упоминании.
- Термины должны соответствовать глоссарию (раздел 11).
### 8.2. Состав документации (обязательный минимум)
| № | Наименование документа | Целевая аудитория | Формат | Ориентировочный объём (страниц) |
|---|------------------------|-------------------|--------|--------------------------------|
| 1 | Техническая документация (включая описание архитектуры, БД, развёртывания) | IT-администраторы, разработчики (наследники) | PDF | 30–40 |
| 2 | Руководство администратора системы | HR, системный администратор | PDF | 20–25 |
| 3 | Руководство пользователя (сотрудник) | Все сотрудники | PDF | 15–20 |
| 4 | Руководство пользователя (руководитель) | Руководители отделов | PDF | 15–20 |
| 5 | Руководство пользователя (HR) | HR-менеджер | PDF | 20–25 |
| 6 | Инструкция по быстрому старту (шпаргалка, 2 страницы) | Все пользователи | PDF / печать | 2 |
| 7 | Приёмочные тест-кейсы (для проведения приёмки) | Заказчик, тестировщик | PDF / Excel | 10–15 |
| 8 | Описание API (если реализовано) | Разработчики внешних систем | PDF / OpenAPI | 10–15 |
### 8.3. Содержание ключевых документов (краткое описание)
#### 8.3.1. Техническая документация
- Архитектура приложения (схема компонентов, потоки данных).
- Инструкция по развёртыванию (чистая установка, обновление, миграция БД).
- Структура базы данных (ER-диаграмма, описание каждой таблицы, полей, индексов).
- Настройка резервного копирования и восстановления (скрипты, cron).
- Перечень конфигурационных файлов и переменных окружения.
- Инструкция по мониторингу (логи, метрики).
#### 8.3.2. Руководство администратора системы
- Управление пользователями (добавление, блокировка, смена роли, сброс пароля).
- Настройка справочников (отделы, должности, графики работы, типы отпусков).
- Импорт/экспорт данных (сотрудники, производственный календарь).
- Просмотр и анализ логов.
- Настройка прав доступа (кастомизация RBAC).
- Управление системными параметрами (лимиты, пороги согласования).
#### 8.3.3. Руководство пользователя (объединённая версия для всех ролей, но с разделами)
- Вход в систему, восстановление пароля.
- Для сотрудника: отметка времени, создание заявки на отпуск/командировку, просмотр остатков, редактирование профиля.
- Для руководителя: согласование заявок, просмотр календаря отдела, отчёты по отделу.
- Для HR: все вышеперечисленное + управление справочниками, массовые операции, отчёты по компании.
- Экспорт отчётов в Excel/PDF.
- Часто задаваемые вопросы.
### 8.4. Порядок согласования и утверждения документации
- Проекты документов передаются заказчику не позднее, чем за 5 рабочих дней до окончания этапа «Документирование».
- Заказчик в течение 3 рабочих дней предоставляет замечания или утверждает документы.
- После исправления замечаний документы считаются согласованными.
- Окончательные версии подписываются сторонами (электронной подписью или сканами) и включаются в состав результата работ.
### 8.5. Обновление документации в гарантийный период
- При исправлении ошибок, влияющих на функционал или порядок действий пользователя, документация обновляется.
- Новые версии документов передаются заказчику с уведомлением об изменениях.
---
## 9. ИСТОЧНИКИ РАЗРАБОТКИ
### 9.1. Источники финансирования
- Единственный источник — собственные средства **ООО «КИТЭК»**.
- Бюджет проекта определяется отдельным соглашением (смета) и не является частью данного ТЗ.
- Форма оплаты: по этапам (авансирование + постоплата) или по факту выполнения — по договорённости.
### 9.2. Источники трудовых ресурсов (кто выполняет работы)
| Роль | Количество (мин.) | Ответственность |
|------|------------------|-----------------|
| Руководитель проекта (с заказчика) | 1 чел. | Приёмка, согласование, предоставление данных |
| Руководитель проекта (с разработчика) | 1 чел. | Планирование, отчётность |
| Аналитик | 1 чел. | Требования, SRS, прототипы |
| Разработчик (бэкенд) | 1-2 чел. | Реализация логики, API, БД |
| Разработчик (фронтенд) | 1 чел. | Интерфейс, адаптивность |
| Тестировщик | 1 чел. | Тест-кейсы, функциональное, нагрузочное тестирование |
| Технический писатель | 1 чел. (частичная занятость) | Документация |
*Примечание: допускается совмещение ролей (например, аналитик + руководитель проекта с разработчика), но должно быть обеспечено качество.*
### 9.3. Информационные источники (документы и данные, предоставляемые заказчиком)
Заказчик обязуется предоставить:
- Штатное расписание (структура компании, отделы, должности).
- Список сотрудников с указанием руководителей.
- Данные об остатках отпусков на начало текущего года (по каждому сотруднику).
- Производственный календарь на текущий и следующий год (при наличии).
- Примеры используемых в компании форм табеля, заявлений (для адаптации отчётов).
- Политики безопасности (требования к паролям, времени сессии), если они строже, чем в ТЗ.
- Доступ к тестовому серверу или выделенной ВМ для развёртывания.
### 9.4. Идейные источники (нормативная база)
- Трудовой кодекс РФ (главы 15, 19, 24) – нормы рабочего времени, отпусков, командировок.
- Постановление Госкомстата РФ от 05.01.2004 №1 (формы Т-12, Т-13) – формат табеля.
- Приказ Минтруда от 19.05.2021 № 350н – электронный документооборот в кадровом учёте (рекомендации).
- Учётная политика ООО «КИТЭК» (внутренние локальные акты).
---
## 10. ПОРЯДОК ИЗМЕНЕНИЯ И ДОПОЛНЕНИЯ ТЕХНИЧЕСКОГО ЗАДАНИЯ
### 10.1. Основания для изменений
- Выявление существенных упущений в требованиях на этапе анализа или разработки.
- Изменение законодательства, влияющее на порядок учёта времени/отпусков.
- Письменное предложение любой из сторон, обоснованное производственной необходимостью.
### 10.2. Процедура внесения изменений
1. Инициатор оформляет **Запрос на изменение (Change Request)** в произвольной форме, но с обязательными полями: описание изменения, причина, влияние на сроки и стоимость.
2. Запрос рассматривается руководителями проекта с обеих сторон (максимум 3 рабочих дня).
3. При согласовании составляется **Дополнительное соглашение** к ТЗ (или к договору), в котором фиксируются новые требования и, при необходимости, корректируются сроки/бюджет.
4. ТЗ обновляется до новой версии (например, версия 1.1), предыдущая версия сохраняется в архиве проекта.
5. Все изменения должны быть отражены в документации (соответствующие разделы перевыпускаются).
### 10.3. Изменения, не требующие формального Дополнительного соглашения
- Исправление орфографических и грамматических ошибок, не меняющих смысла.
- Уточнение формулировок без расширения функциональности.
- Корректировка контактных данных сторон.
Такие изменения вносятся по уведомлению (e-mail) и фиксируются в реестре версий ТЗ.
---
## 11. ГЛОССАРИЙ (ОСНОВНЫЕ ТЕРМИНЫ)
| Термин | Определение |
|--------|-------------|
| **СУРВ-IT** | Система учёта рабочего времени, отпусков и командировок для IT-компаний – разрабатываемый продукт. |
| **Рабочее время** | Время, в течение которого сотрудник исполняет трудовые обязанности. Фиксируется в часах. |
| **Табель учёта рабочего времени** | Отчётный документ (форма Т-13), содержащий отметки о явках, неявках, переработках. |
| **Отпуск** | Время отдыха, предоставляемое сотруднику ежегодно с сохранением места работы и среднего заработка (основной). А также другие виды (без сохранения зарплаты и т.д.). |
| **Командировка** | Поездка сотрудника по распоряжению работодателя для выполнения служебного поручения вне места постоянной работы. |
| **Больничный лист (листок нетрудоспособности)** | Документ, подтверждающий временную нетрудоспособность работника. |
| **Согласование** | Процедура утверждения заявки руководителем (HR). Заявка считается действительной после согласования. |
| **Остаток отпуска** | Количество дней неиспользованного отпуска на текущую дату с учётом плановых заявок. |
| **HR** | Human Resources – отдел кадров / менеджер по персоналу. |
| **RBAC** | Role-Based Access Control – модель управления доступом на основе ролей. |
| **API** | Application Programming Interface – интерфейс для взаимодействия с системой программными средствами. |
| **Опытная эксплуатация** | Этап проверки системы в реальных условиях на ограниченной группе пользователей перед полноценным запуском. |
| **Критическая ошибка** | Дефект, который делает невозможным выполнение основной функции системы (например, вход, создание заявки). |
---
## 12. ПРИЛОЖЕНИЯ (ШАБЛОНЫ, ПЕРЕЧНИ)
### Приложение А. Форма акта сдачи-приёмки работ (шаблон)
(Предоставляется отдельным файлом, но в составе ТЗ описывается структура)
**Акт №___ от «__» ______ 20__ г.**
о сдаче-приёмке работ по разработке системы СУРВ-IT
| Пункт | Содержание |
|-------|-------------|
| 1 | Заказчик: ООО «КИТЭК» |
| 2 | Разработчик: [наименование] |
| 3 | Основание: Договор №___ от ____ |
| 4 | Выполненные работы: согласно п.5 ТЗ |
| 5 | Результат: веб-приложение, документация, исходные коды (репозиторий) |
| 6 | Замечания: _____ (если есть) |
| 7 | Решение: Работы приняты / приняты с доработками |
Подписи.
### Приложение Б. Шаблон заявки на отпуск (форма внутри системы)
Поля:
- Сотрудник (ФИО – автоматически)
- Тип отпуска (выпадающий список)
- Дата начала, дата окончания
- Количество дней (рассчитывается автоматически)
- Комментарий (опционально)
- Прикреплённый файл (например, заявление скан)
### Приложение В. Пример экспорта табеля (формат для 1С)
Столбцы: Табельный номер, ФИО, Дата, Код явки (Я/ОТ/К/Б), Часы (например, 8 или 0).
Файл: XLSX, первая строка – заголовки.
### Приложение Г. Перечень приёмочных тест-кейсов (сокращённый пример)
| ID | Тест-кейс | Ожидаемый результат | Приоритет |
|----|-----------|---------------------|------------|
| TC-01 | Сотрудник с ролью «Сотрудник» входит в систему | Доступна страница «Мой табель» | High |
| TC-02 | Сотрудник создаёт заявку на отпуск при достаточном остатке | Заявка сохраняется, статус «На согласовании» | High |
| TC-03 | Руководитель одобряет заявку | Статус меняется на «Одобрена», остаток уменьшается | High |
| ... (всего не менее 30 кейсов) | ... | ... | ... |
Полный перечень передаётся отдельным файлом на этапе тестирования.
### Приложение Д. Список сокращений
- СУРВ – Система учёта рабочего времени
- ТЗ – техническое задание
- SRS – Software Requirements Specification
- БД – база данных
- НСД – несанкционированный доступ
- ХР – человеко-ресурсы (персонал)
---
## 13. ЛИСТ СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ
**Техническое задание разработано в соответствии с требованиями заказчика и подлежит утверждению.**
| Должность | ФИО | Подпись | Дата |
|------------|-----|---------|------|
| Заказчик: руководитель проекта (ООО «КИТЭК») | Шпраер Андрей Александрович | (подпись) | ______ |
| Разработчик: руководитель проекта | (назначенный) | (подпись) | ______ |
---
**Документ готов к подписанию и передаче в разработку.**
