Технічне завдання (ТЗ) на ІТ-розробку

Система цифрового підписання та обігу документів (університет: студент ↔ посадовці ↔ адміни)

1. Мета

Розробити систему, яка забезпечує:

ініціювання студентом процесу підписання/запиту документа;
маршрутизацію документа по ієрархії посадовців;
підписання/відмову з фідбеком;
зберігання фінальних підписаних документів у БД за правилами процесів.

2. Обсяг робіт (Scope)

Система покриває 4 типи процесів:

Будь-які роботи з титульним аркушем (1 підпис “цілі” + можливий підпис студента)
Отримання довідок (запит → перевірки → формування/підписання → видача студенту → внесення в БД)
Роботи, де потрібно >1 підпис викладачів (приклад: викладач → завідувач кафедри)
Документи з більшою кількістю підписів (вертикальна ієрархія знизу-вверх, каскадні сповіщення при відмові)

3. Ролі та учасники

Студент: ініціює процес, підписує (за потреби), обирає “ціль”, отримує результат/фідбек, завантажує документ.
Ціль (посадовець/викладач): переглядає документ, підписує або відмовляє з причиною.
Адміни: отримують повідомлення про створені/відправлені документи, контролюють процеси.
Відповідальна особа (для довідок): отримує запит, виконує перевірки, прикріплює документ, підписує.
Завідувач кафедри: другий підпис у сценарії з двома підписами.
Інші посадовці: підписанти у багаторівневому маршруті.

4. Загальні принципи (Business Rules)

Документ рухається ієрархічно знизу-вверх (від нижчої ланки до вищої).
На кожному етапі підписант може:
- Підписати (перехід на наступний етап / завершення),
- Відхилити (процес зупиняється, надсилається причина відмови).
У разі відхилення на будь-якому етапі:
- студент отримує відмову та фідбек (причину),
- ієрархічно нижчі ланки отримують сповіщення про причину відмови.
Внесення в БД виконується лише за умовами, визначеними для кожного сценарію (див. розділ 6).

5. Канали сповіщень (поведінка системи)

Система має надсилати нотифікації при подіях:

створення/відправка студентом документа/запиту;
призначення наступного підписанта;
підписання;
відхилення з причиною;
необхідність дії студента (наприклад, “підпиши документ”);
завершення процесу та доступність фінального файлу для завантаження.

(Канали реалізації: push/in-app/email — визначається на етапі проєктування, але логіка подій фіксується в ТЗ.)

6. Опис бізнес-процесів (As-Is → To-Be логіка у вигляді алгоритмів)

6.1. Процес A: Роботи з титульним аркушем (1 “ціль” + адміни)

Передумова: документ потребує титульного аркуша та підписання.

Алгоритм:

Студент натискає кнопку “Підписати та надіслати”, підписує документ і обирає кому надсилати (“ціль”).
Студент надсилає документ — “ціль” та адміни отримують повідомлення.
“Ціль” переглядає документ і вирішує: підписати або відмовити.
Студент отримує:
- або фідбек та відмову (з причиною),
- або підписаний документ.
Якщо документ підписаний:
- студент може завантажити документ;
- якщо документ має обидва підписи (студента і “цілі”) — документ потрапляє у БД.

Умови внесення в БД:

ДБ-статус: COMPLETED
Підписи: student_signed = true AND target_signed = true

6.2. Процес B: Отримання довідок (з перевірками)

Передумова: студент ініціює запит на довідку.

Алгоритм:

Студент натискає кнопку “Запросити довідку”.
Відповідальна особа отримує повідомлення про запит.
Відповідальна особа виконує перевірки необхідних умов. 3.1. Якщо умови незадовільні — запит відхиляється.
3.2. Студенту надсилається відгук з причиною відмови.
Якщо умови задоволені — документ прикріплюється до запиту та підписується відповідальною особою.
Студент отримує готовий документ, який також вноситься до БД.

Умови внесення в БД:

ДБ-статус: COMPLETED
Запит: approved = true
Документ: responsible_signed = true (та інші потрібні підписи, якщо модель довідок це вимагає)

6.3. Процес C: Роботи з >1 підписом (Викладач → Завідувач кафедри)

Передумова: документ потребує підпису викладача та завідувача кафедри.

Алгоритм:

Студент натискає кнопку для запиту і надсилає документ.
Сповіщення отримує викладач.
Викладач приймає рішення: 3.1. У разі підписання — сповіщення отримує завідувач кафедри.
3.2. У разі відмови — студент отримує сповіщення про відмову (з причиною) і процес завершується.
Завідувач кафедри приймає рішення:
- У разі підписання — студент отримує підписаний документ. 4.1. Якщо документ був підписаний студентом — документ вноситься у БД. 4.2. Якщо документ не був підписаний студентом — студент отримує сповіщення про необхідність підписання. 4.3. Після підписання студентом — документ вноситься в БД.

Умови внесення в БД:

ДБ-статус: COMPLETED
Підписи: teacher_signed = true AND head_signed = true AND student_signed = true

6.4. Процес D: Документи з більшою кількістю підписів (ієрархічний маршрут)

Правило маршрутизації:

Сповіщення про необхідність підписання отримують всі необхідні посадовці у вертикальному ієрархічному порядку знизу-вверх.
Якщо на будь-якому етапі документ відхилено:
- процес зупиняється,
- студент отримує відмову з причиною,
- ієрархічно нижчі ланки отримують сповіщення про причину відмови.

Завершення процесу:

Документ вважається завершеним, коли зібрані всі потрібні підписи (включно зі студентом, якщо його підпис обов’язковий для цього типу документу).
Після завершення — документ вноситься у БД відповідно до матриці підписів.

7. Вимоги до даних та станів (мінімальна доменна модель)

7.1. Сутності

Document

id
type (робота з титульним / довідка / інше)
file_original, file_signed_final
created_by_student_id
status (див. 7.2)
required_signers (послідовність ролей/посадовців)
current_signer (хто зараз має дію)
signatures[] (хто/коли/статус/коментар)
created_at, updated_at

Request (для довідок)

id
student_id
status
checks_result (пояснення/протокол перевірок)
attached_document_id
created_at, updated_at

Notification

id
recipient_id
event_type
payload
read_at

7.2. Стани (рекомендована FSM)

DRAFT (за потреби)
SENT (відправлено на підпис)
IN_REVIEW (на розгляді у поточного підписанта)
NEED_STUDENT_SIGNATURE (очікується підпис студента)
SIGNED_PARTIALLY (частково підписаний)
REJECTED (відхилено)
COMPLETED (усі підписи зібрані, фінальний документ готовий)
STORED (внесено у БД, якщо відділяєте від COMPLETED)

8. Функціональні вимоги (FR)

FR-1. Створення та відправка документа студентом

Студент може обрати тип процесу, завантажити/сформувати документ, підписати, обрати “ціль” (коли це потрібно) і відправити.

FR-2. Маршрутизація по ієрархії

Система автоматично визначає наступного підписанта відповідно до required_signers та правил “знизу-вверх”.

FR-3. Розгляд документа підписантом

Підписант може:
- переглянути файл,
- підписати,
- відмовити із зазначенням причини (обов’язкове поле).

FR-4. Зворотний зв’язок студенту

Студент завжди отримує:
- фінальний підписаний документ, або
- відмову з причиною.

FR-5. Внесення у БД за умовами

Система вносить документ у БД лише коли виконані умови відповідного процесу (див. 6.1–6.4).

FR-6. Довідки: перевірки умов та формування документа

Відповідальна особа має інтерфейс для:
- перегляду запитів,
- фіксації результатів перевірок,
- відхилення з причиною,
- прикріплення/формування документа та підписання.

FR-7. Логи та аудит

Для кожної дії (відправка, перегляд, підпис, відмова, внесення в БД) має бути запис в аудит-лог.

9. Нефункціональні вимоги (NFR)

Безпека: контроль доступу за ролями, незаперечність підпису, цілісність файлів.
Надійність: повторна доставка нотифікацій/ретраї, збереження стану процесу.
Масштабованість: можливість додавати нові типи документів та маршрути підписання без переписування ядра (конфігуративні маршрути).
Трасованість: можливість відтворити історію “хто/коли/що зробив”.

10. Критерії приймання (Acceptance Criteria)

Для процесу A студент може пройти ланцюжок “підписав → надіслав → ціль підписала/відхилила → студент отримав результат”, а документ потрапляє в БД тільки при двох підписах.
Для процесу B відхилений запит містить причину, студент її бачить; схвалений — студент отримує підписану довідку, і вона зберігається в БД.
Для процесу C відмова на етапі викладача зупиняє процес; підписання викладачем тригерить завідувача; після підписання завідувачем студент отримує документ; якщо потрібно — система вимагає підпис студента перед внесенням у БД.
Для процесу D маршрутизація йде знизу-вверх; при відмові нижчі ланки та студент отримують причину відмови.
Аудит-лог містить повну хронологію дій.

11. Відкриті питання (для наступної ітерації ТЗ)

Які саме типи документів є в системі (перелік) та які матриці підписів для кожного типу?
Який механізм підпису (КЕП/Дія.Підпис/внутрішній підпис) і які юридичні вимоги до зберігання?
Які канали сповіщень потрібні (in-app / email / Teams / push)?
Чи потрібні шаблони для генерації документів (особливо для довідок)?

Module4 - Digital Signature Тех Завдання

Технічне завдання (ТЗ) на ІТ-розробку

Система цифрового підписання та обігу документів (університет: студент ↔ посадовці ↔ адміни)

1. Мета

2. Обсяг робіт (Scope)

3. Ролі та учасники

4. Загальні принципи (Business Rules)

5. Канали сповіщень (поведінка системи)

6. Опис бізнес-процесів (As-Is → To-Be логіка у вигляді алгоритмів)

6.1. Процес A: Роботи з титульним аркушем (1 “ціль” + адміни)

6.2. Процес B: Отримання довідок (з перевірками)

6.3. Процес C: Роботи з >1 підписом (Викладач → Завідувач кафедри)

6.4. Процес D: Документи з більшою кількістю підписів (ієрархічний маршрут)

7. Вимоги до даних та станів (мінімальна доменна модель)

7.1. Сутності

7.2. Стани (рекомендована FSM)

8. Функціональні вимоги (FR)

FR-1. Створення та відправка документа студентом

FR-2. Маршрутизація по ієрархії

FR-3. Розгляд документа підписантом

FR-4. Зворотний зв’язок студенту

FR-5. Внесення у БД за умовами

FR-6. Довідки: перевірки умов та формування документа

FR-7. Логи та аудит

9. Нефункціональні вимоги (NFR)

10. Критерії приймання (Acceptance Criteria)

11. Відкриті питання (для наступної ітерації ТЗ)

On this page