# Запити зацікавлених осіб

# Вступ

У цьому документі сформульовано основні вимоги до функціональності, практичності, надійності, продуктивності та експлуатаійної придатності застосунку. Також наведено короткий огляд можливих сценаріїв його використання.

# Мета

Розробити вимоги, згідно з якими у подальшому можна буде створити робочу карту проєкту та якими можна буде керуватися надалі; надати зацікавленим особам інформацію про функціонал застосунку.

# Контекст

Документ містить вимоги та перелік необхідого функціоналу проєкту "Система аналізу текстових даних"

# Основні визначення та скорочення

Необхідні визначення наведені на сторінці Аналіз предметної області (opens new window)

# Короткий зміст

  1. Характеристика ділових процесів: перелік можливих сценаріїв користування застосунком
  2. Короткий огляд продукту: опис можливостей системи
  3. Функціональність - вимоги до функціоналу застосунку
  4. Практичність - вимоги до зручності користування
  5. Надійність - вимоги до надійності та безпеки
  6. Продуктивність - вимоги до швидкодії
  7. Експлуатаційна придатність - вимоги до зручності подальшої підтримки проєкту

# Характеристика ділових процесів

Опис бізнес-сценаріїв взаємодії бізнес-акторів, робітників і інформаційної системи:

# Користувач

# Створення нового облікового запису

ID: USER.REG
НАЗВА: Реєстрація в системі
УЧАСНИКИ: Користувач, Система
ПЕРЕДУМОВИ: Користувач не зареєстрований у системі
РЕЗУЛЬТАТ: Новий обліковий запис
ВИКЛЮЧНІ СИТУАЦІЇ: Відхилення запиту на реєстрацію (USER.REG_DENY)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Користувач вводить реєстраційні дані
2. Система перевіряє передані реєстраційні дані
3. Система створює новий обліковий запис, використовуючи введені дані
4. Система надає користувачу інформацію про створення облікового запису
5. Користувач завершує взаємодію з системою

# Авторизація користувача

ID: USER.LOG
НАЗВА: Авторизація користувача в системі
УЧАСНИКИ: Користувач, Система
ПЕРЕДУМОВИ: 1. Користувач зареєстрований у системі
2. Користувач не зареєстрований у системі
РЕЗУЛЬТАТ: Авторизація в системі
ВИКЛЮЧНІ СИТУАЦІЇ: Такого користуавача не існує (USER.LOG_DENY)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Користувач вводить авторизаційні дані
2. Система ідентифікує користувача
3. Система авторизує користувача
4. Система надає користувачу авторизацію у системі
5. Користувач завершує взаємодію з системою

# Запит на пошук даних

ID: USER.D_SRCH
НАЗВА: Користувач надає запит на знаходження тексту
УЧАСНИКИ: Користувач, Система
ПЕРЕДУМОВИ: Користувач авторизований в системі
РЕЗУЛЬТАТ: Дані знайдено і виведено на екран користувача
ВИКЛЮЧНІ СИТУАЦІЇ: Відхилення запиту користувача на пошук даних (RQS.DENY)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Користувач відправляє запит на пошук
2. Система виводить форму для заповнення користувачем
3. Користувач заповнює форму
4. Система проводить пошук по базам даних заданих ресурсів
5. Система виводить результат на екран користувача

# Запит на право редагування

ID: USER.EDIT_RQST
НАЗВА: Користувач надає запит на право редагування тексту
УЧАСНИКИ: Користувач, Система
ПЕРЕДУМОВИ: Користувач авторизований в системі
РЕЗУЛЬТАТ: Передано запит на право редагування тексту адміністратору
ВИКЛЮЧНІ СИТУАЦІЇ: Максимальна кількість редакторів досягнута (MAX.EDIT.REACHED)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Користувач відправляє запит на редагування
2. Система передає запит адміністратору

# Редактор

# Редагування розмітки даних

ID: EDITOR.TXT_ANNOTATION_CHNG
НАЗВА: Редагування розмітки
УЧАСНИКИ: Користувач, Система
ПЕРЕДУМОВИ: Користувач отримав право редагування
РЕЗУЛЬТАТ: Запит на змінення розмітки файлу до адміністратора
ВИКЛЮЧНІ СИТУАЦІЇ: Відхилення запиту користувача на пошук даних (RQS.DENY)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Користувач робить розмітку тексту в редакторі
2. Користувач відправляє адміністратору запит на затвердження змін

# Адміністратор

# Завантажити текстовий файл в систему

ID: ADM.FILE_UPLOAD
НАЗВА: Завантажити текстовий файл в систему
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Адміністратор Авторизувався в системі
РЕЗУЛЬТАТ: Файл завантажено у систему
ВИКЛЮЧНІ СИТУАЦІЇ: Відхилення запиту адміністратора на завантаження файлу (RQS.FILE_UPLOAD_DENY)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор обирає файл для завантаження
2. Адміністратор надсилає запит системі на завантаження файлу

# Надати право редагування

ID: ADM.ADD_EDITOR
НАЗВА: Додати редактора файлу
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Адміністратор отримав запит на редагування
РЕЗУЛЬТАТ: Нового редактора додано
ВИКЛЮЧНІ СИТУАЦІЇ: Адміністратор відхилив запит (ADM.RQS.DENY)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор переглядає запит на редагування
2. Адміністратор приймає або відхиляє запит

# Запит на видалення редактора

ID: ADM.DELETE_EDITOR
НАЗВА: Адміністратор надає запит на право видалення редактора
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: У файла є редактор
РЕЗУЛЬТАТ: Надіслано запит на видалення редактора
ВИКЛЮЧНІ СИТУАЦІЇ: -
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор обирає редактора
2. Адміністратор надсилає запит на видалення редактора

# Видалити текстовий файл

ID: ADM.FILE_DELETE
НАЗВА: Видалити текстовий файл з системи
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Адміністратор Авторизувався в системі
РЕЗУЛЬТАТ: Файл видалено
ВИКЛЮЧНІ СИТУАЦІЇ: Файл не існує (RQS.FILE_NOT_EXIST)
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор обирає файл для видалення
2. Адміністратор надсилає запит системі на видалення файлу

# Змінити розмітку даних

ID: ADM.ADMT_TXT_ANNOTATION_CHNG
НАЗВА: Змінити розмітку даних
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Редактор відправляє адміністратору запит на затвердження змін розмітки даних
РЕЗУЛЬТАТ: Приймаються зміни до розмітки даних
ВИКЛЮЧНІ СИТУАЦІЇ: -
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор приймає або не приймає зміни розмітки даних
2. Адміністратор відправляє системі запит на зміну розмітки даних

# Переглянути історію змін файлу

ID: ADM.VIEW_HISTORY
НАЗВА: Переглянути історію змін файлу
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Адміністратор Авторизувався в системі
РЕЗУЛЬТАТ: Система надала адміністратору доступ до історії змін
ВИКЛЮЧНІ СИТУАЦІЇ: -
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор надсилає запит на перегляд історії змін
2. Система виводить історію змін файлу

# Переглянути гілку змін редактора

ID: ADM.VIEW_BRANCH
НАЗВА: Переглянути гілку змін файлу
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Адміністратор Авторизувався в системі
РЕЗУЛЬТАТ: Система надала адміністратору доступ до історії змін певного редактора
ВИКЛЮЧНІ СИТУАЦІЇ: -
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністартор обирає редактора
2. Адміністратор надсилає запит на перегляд гілки змін обраного редактора
3. Система виводить гілку змін файлу

# Завершити редагування файлу

ID: ADM.ADMT_TXT_ANNOTATION_FINAL
НАЗВА: Завершити розмітку даних
УЧАСНИКИ: Адміністратор, Система
ПЕРЕДУМОВИ: Файл повністю анотовано
РЕЗУЛЬТАТ: Анотований файл готовий до завантаження
ВИКЛЮЧНІ СИТУАЦІЇ: -
ОСНОВНИЙ СЦЕНАРІЙ: 1. Адміністратор відправляє запит на завершення редагування
2. Система формує вихідний файл у відповідному форматі

# Система

# Забрати право редагування

ID: SYS.DELETE_EDITOR
НАЗВА: Прибрати редактора файлу
УЧАСНИКИ: Система, Редактор
ПЕРЕДУМОВИ: Система отримала запит на видалення
РЕЗУЛЬТАТ: Редактора вилучено
ВИКЛЮЧНІ СИТУАЦІЇ: -
ОСНОВНИЙ СЦЕНАРІЙ: 1. Система видаляє редактора
2. Система надсилає редактору повідомлення про його видалення

# Короткий огляд продукту

Програма має декілька адміністраторів, які завантажують тексти в систему. Після чого користувачі можуть обрати певний текст і стати його редактором (може бути максимум 2 редактора на 1 текст). Користувачі можуть одночасно анотувати текст у своїх гілках, після чого вони можуть надіслати pull request, таким чином зробивши запит на збереження змін. Один із адміністраторів перевіряє текст і підтверджує або відхиляє запропоновані зміни. У разі підтвердження файл переміщується у базу анотованих текстів, тоді інші користувачі мають можливість завантажити його, для тренування нейронних мереж.

# Функціональність

# Користувач:

Не має прямого доступу до вказанних файлів, може лише завантажувати їх для власної обробки, яка ніяк не вплине на джерело.

  • Створення нового облікового запису;
  • Авторизація на сервісі;
  • Створення запиту на знаходження тексту в системі;
  • Створення запиту на отримання прав редактора.

# Редактор:

Не має прямого доступу до вказанних файлів, на додачу до базового функціоналу користувача, може запропонувати власні зміни на розгляд.

  • Функціональні можливості звичайного користувача;
  • Редагування розмітки даних.

# Адміністратор:

Має повний доступ до файлів та системи загалом, приймає усі кінцеві рішення щодо редагувань текстових файлів.

  • Функціональні можливості звичайного користувача;
  • Функціональні можливості редактора;
  • Завантаження текстових файлів у систему;
  • Надання користувачам можливості редагувати файли;
  • Відміна можливостей редагувати файли у редакторів;
  • Видалення файлів з системи;
  • Перегляд історії змін файлів;
  • Перегляд гілки змін редактора;
  • Відправка кінцевих змін файлів у систему.

# Практичність

  • Простота та зрозумілість інтерфейсу
  • Наявність FAQ
  • Робота у браузері

# Надійність

  • Захист облікового запису паролем
  • Шифрування паролей
  • Розділення користувачів на ролі (user/admin)
  • Двофакторна аутентифікація

# Продуктивність

  • Система має підтримувати редагування файлу декількома користувачами одночасно
  • Система має підтримувати багатопоточне завантаження та вивантаження файлів
  • Система має підтримувати високу швідкість доступу до даних для ефективного навчання нейромереж

# Експлуатаційна придатність

  • Програмний код має бути максимально зрозумілим для легшої підтримки
  • Має існувати API для інтеграції з нейронними мережами
  • Необхідна наявність форми зворотнього зв'язку та контактів техпідтримки
  • Модульність коду для легшого модифікування
Останнє оновлення: 11/29/2022, 2:40:56 AM