# Запити зацікавлених осіб
# Вступ
Проаналізувавши предметну область та зробивши порівняльну характеристику існуючих засобів вирішення поставленого завдання[1], ми приступаємо до визначення основних вимог до нашої системи. Цей документ містить основні бізнес-сценарії використання системи зацікавленими особами та відповідні до них вимоги FURPS, а також короткий опис продукту.
# Мета
Перед тим як починати розроблювати СУБД треба визначити, ким будуть користувачі системи, чого вони вимагають від неї, адже кінцева мета проекту - задовольнити очікування користувачів.
# Контекст
У цьому документі розглядаються основні вимоги до нашої системи упраління проетами "Just Chill", що буде легкою для інтеграції користувачів, зручною у використанні та при цьому надасть найбільш широке коло можливостей для автоматизації процесів управління проектами.
# Основні визначення та скорочення
Бізнес-процес (opens new window) (англ. Business Process) — будь-яка діяльність, що має вхідний продукт, додає вартість до нього, та забезпечує вихідний продукт для внутрішнього або зовнішнього споживача.
Бізнес-актор (opens new window) (business actor) – індивідуум, група, організація, компанія чи система, які взаємодіють з модельованою бізнес-системою, але не входять до неї, тобто не є частиною системи, що моделюється.
Бізнес-працівник (opens new window) (business worker) представляє роль або набір ролей у бізнесі. Бізнес-працівник взаємодіє з іншими ролями та маніпулює бізнес-суб’єктами, беручи участь у реалізації бізнес-прецедентів.
Бізнес-сценарій (opens new window) (business scenario) – це опис ймовірних майбутніх подій і обставин, пов’язаних з бізнесом, який зазвичай ґрунтується на поточних і минулих тенденціях, а також на припущеннях, зроблених на основі цих тенденцій.
FURPS – класифікація вимог до програмних систем.[2] (opens new window)
Functionality (Функціональність) - те, що хоче клієнт! Зауважте, що це включає потреби, пов’язані з безпекою.
Usability (Зручність використання) - Наскільки ефективним є продукт з точки зору людини, яка повинна його використовувати? Чи це естетично прийнятно? Чи документація точна та повна?
Reliability (Надійність) - Який максимально прийнятний час простою системи? Чи передбачувані невдачі? Чи можемо ми продемонструвати точність результатів? Як відновлюється система?
Performance (Продуктивність) - Наскільки швидкою вона має бути? Який максимальний час відповіді? Яка пропускна здатність? Яке споживання пам'яті?
Supportability (Підтримуваність) - чи можна тестувати, розширювати, обслуговувати, встановлювати та конфігурувати? Чи можна це контролювати?[3] (opens new window)
Вимоги були розроблені та представлені Hewlett-Packard. В даний час використовується абревіатура FURPS+.
+ нагадує нам про кілька додаткових потреб, які можуть виникнути у клієнта:
Обмеження дизайну - Чи такі речі, як пристрої вводу/виводу чи СУБД, обмежують те, як програмне забезпечення повинно бути створено?
Вимоги до впровадження - чи потрібно програмістам дотримуватися стандартів? Чи потрібно використовувати TDD (Керована тестами розробка (Test-driven development) — технологія розробки програмного забезпечення, яка використовує короткі ітерації розробки, що починаються з попереднього написання тестів, які визначають необхідні покращення або нові функції.)[4] (opens new window)? Чи потрібне статистично надійне тестування в контексті чистих приміщень(Cleanroom -це обладнаний простір, у якому підтримується дуже низька концентрація частинок у повітрі . Він добре ізольований, добре контролюється від забруднень і активно очищається.[5] (opens new window)?
Вимоги до інтерфейсу - Які вихідні потоки необхідно створити? З якими іншими системами ця система має взаємодіяти? Як часто виробляються потоки?
Фізичні вимоги - На якому апаратному забезпеченні має бути розгорнута система?
# Посилання
- Аналіз предметної області
- Що таке FURPS? (opens new window)
- Опис FURPS (opens new window)
- TDD (opens new window)
- Cleanroom (opens new window))
# Короткий зміст
Характеристика ділових процесів
- USER.REGISTER (Зареєструвати користувача)
- USER.AUTHORIZE (Авторизувати користувача)
- TASK.CREATE (Створити завдання)
- TASK.EDIT (Редагувати завдання)
- TASK.DELETE (Видалити завдання)
- DASHBOARD.DISPLAY (Відобразити дашборд)
- СHANGE.VIEW (Змінити вигляд)
- TASK.FILTER (Відфільтрувати завдання)
- TASK.СOMMENT (Коментувати завдання)
- USER.BAN (Заблокувати користувача)
- USER.UNBAN (Розблокувати користувача)
- MEMBER.ADD (Додати користувача)
- MEMBER.DELETE (Видалити користувача)
- CREATE.PROJECT (Створити проект)
- DELETE.PROJECT (Видалити проект)
- CREATE.SPRINT (Створити спринт)
- FINISH.SPRINT (Завершити спринт)
- TEAMLEAD.REQUEST (Відправити запит бути тімлідом)
- TEAMLEAD.APPROVE (Підтвердити запит учасника проекту бути тімлідом)
- TEAMLEAD.DECLINE (Відхилити запит учасника проекту бути тімлідом)
# Характеристика ділових процесів
Щоб розробити модель поведінки нашої системи управління проектами, треба визначити її границі, тобто зовнішні та внутрішні фактори, що будуть впливати на систему та як система повинна відреагувати на цей вплив.
Зовнішнім фактором, тобто бізнес-актором для системи управління проектами буде:
- Клієнт (замовник, customer) - взаємодіє з системою управління проектами не безпосередньо, а через бізнес-робітників, він висловлює свої вимоги до проекту, переглядає результати на проміжних стадіях реалізації проекту.
Внутрішніми факторами, тобто бізнес-робітниками будуть:
- Менеджер проектів (Project Manager) - перетворює вимоги клієнта на конкретні задачі, планує та розділює роботу на відносно незалежні частини, які делегує командам, відстежує результати виконання завдань, управляє ресурсами (часовими, грошовими). Він може управляти одним або декількома проектами.
- Тімлід - управляє процесами всередині команди, роподілює роботу між працівниками, стежить за її виконанням згідно умовам, поставленим менеджером проекту.
- Робітник (colaborator) - виконує свої завдання, планує виключно свою роботу.
- Адміністратор системи - займається технічними питаннями у разі виникнення проблем з використанням інформаційного забезпечення.
Розглянемо основні бізнес-сценарії взаємодії учасників бізнес-процесу та інформаційної системи:
| ID | USER.REGISTER |
|---|---|
| Назва: | Зареєструвати користувача |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | Користувач не має облікового запису |
| Результат: | Обліковий запис користувача |
| Виключні ситуації: | Користувач не заповнив обов'язкові поля реєстраційної форми EX.NO.REGISTRATION.DATA Користувач вже зареєстрований у системі EX.ACCOUNT.ALREADY.EXISTS |
| Основний сценарій: | 1. Користувач натискає кнопку "Створити обліковий запис" 2. Користувач вводить реєстраційні дані 3. Користувач натискає кнопку "Зареєструватися" (можлива EX.NO.REGISTRATION.DATA) 4. Система перевіряє наявність облікового запису користувача (можлива EX.ACCOUNT.ALREADY.EXISTS) 5. Система створює новий обліковий запис 6. Система повідомляє користувача про успішну реєстрацію |
| ID | USER.AUTHORIZE |
|---|---|
| Назва: | Авторизувати користувача |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | -Користувач зареєстрований у системі -Користувач не авторизований у системі |
| Результат: | Авторизація користувача |
| Виключні ситуації: | У авторизаційній формі не заповнені одне або більше полів EX.NO.AUTHORIZATION.DATA Користувач не зареєстрований у системі EX.ACCOUNT.DOESNT.EXIST Користувач ввів неправильний пароль EX.WRONG.PASSWORD |
| Основний сценарій: | 1. Користувач вводить авторизаційні дані 2. Користувач натискає кнопку "Увійти" (можлива EX.NO.AUTHORIZATION.DATA) 3. Система перевіряє наявність облікового запису користувача (можлива EX.ACCOUNT.DOESNT.EXIST) 4. Система перевіряє отримані авторизаційні дані (можлива EX.WRONG.PASSWORD) 5. Система авторизує користувача 6. Система повідомляє користувача про успішну авторизацію |
| ID | TASK.CREATE |
|---|---|
| Назва: | Створити завдання |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | - Користувач авторизований - Користувач обрав проект |
| Результат: | Завдання створено |
| Виключні ситуації: | Користувач не заповнив обов'язкові поля EX.TASK.NO.OBLIGATORY.DATA |
| Основний сценарій: | 1. Користувач натискає кнопку "Створити завдання" 2. Користувач вводить назву завдання(обов'язково), його опис, зазначає теги(todo/in progress/done/in rewiew), дедлайн, кому призначене завдання 3. Користувач натискає кнопку "Створити" 4. Система перевіряє наявність обов'язкових полів(можлива EX.TASK.NO.OBLIGATORY.DATA) 5. Система створює і відображає завдання у беклозі та на відповідних дошках 6. Система повідомляє тим, кому призначене завдання, інформацію про завдання |
| ID | TASK.EDIT |
|---|---|
| Назва: | Редагувати завдання |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | - Користувач авторизований - Користувач обрав завдання |
| Результат: | Завдання відредаговано |
| Виключні ситуації: | Користувач не заповнив обов'язкові поля EX.TASK.NO.OBLIGATORY.DATA Завдання було видалене під час редагування EX.TASK.NOT.EXIST |
| Основний сценарій: | 1. Користувач натискає кнопку "Редагувати завдання" 2. Користувач редагує завдання 3. Користувач натискає кнопку "Зберегти"(можлива EX.TASK.NOT.EXIST) 4. Система перевіряє наявність обов'язкових полів(можлива EX.TASK.NO.OBLIGATORY.DATA) 5. Система зберігає зміни та відображає відредаговане завдання 6. Система повідомляє тим, кому призначене завдання, інформацію про завдання |
| ID | TASK.DELETE |
|---|---|
| Назва: | Видалити завдання |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | - Користувач авторизований - Користувач обрав завдання |
| Результат: | Завдання видалено |
| Виключні ситуації: | Натиснута кнопка "Скасувати" EX.CANCEL Користувач не має прав на видалення даного завдання EX.ACCESS.DENIED |
| Основний сценарій: | 1. Користувач натискає кнопку "Видалити завдання" 2.Система виводить вікно для підтвердження видалення 3.Користувач натискає кнопку "Підтвердити"(можлива EX.CANCEL) 4. Система видаляє завдання(можлива EX.ACCESS.DENIED) |
| ID | DASHBOARD.DISPLAY |
|---|---|
| Назва: | Відобразити дашборд |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник) |
| Передумови: | -Користувач авторизований -Користувач обрав проект |
| Результат: | Поточна інформація про проект у вигляді дашборду |
| Виключні ситуації: | Відсутні |
| Основний сценарій: | 1. Користувач натискає кнопку "Dashboard" 2. Система виводить список можливих компонентів дашборду 3. Користувач обирає потрібні елементи дашборду 4. Система виводить поточну інформацію про проект у вигляді дашборду |
| ID | СHANGE.VIEW |
|---|---|
| Назва: | Змінити вигляд |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | -Користувач авторизований -Користувач обрав проект -Користувач перейшов у розділ блоку завдань |
| Результат: | Змінений вигляд відображення завдань |
| Виключні ситуації: | Відсутні |
| Основний сценарій: | 1. Користувач натискає кнопку "View" 2. Система повідомляє про поточний тип відображення (Backlog/Kanban/Scrum/Roadmap) 3. Користувач обирає тип відображення 4. Система змінює вигляд відображення завдань |
| ID | TASK.FILTER |
|---|---|
| Назва: | Відфільтрувати завдання |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | -Користувач авторизований -Користувач обрав проект -Користувач обрав тип відображення завдань "Backlog" |
| Результат: | Відфільтровані завдання |
| Виключні ситуації: | У проекті нема жодних завдань EX.NO.TASKS |
| Основний сценарій: | 1. Користувач натискає кнопку "Filter"(можлива EX.NO.TASKS) 2. Користувач обирає критерій фільтрування 3. Система відображає відфільтровані завдання |
| ID | TASK.СOMMENT |
|---|---|
| Назва: | Коментувати завдання |
| Учасники: | Користувач (менеджер проекту, тімлід або робітник), система |
| Передумови: | -Користувач авторизований -Користувач обрав проект -Користувач обрав завдання |
| Результат: | Коментар до завдання |
| Виключні ситуації: | Завдання було видалене під час написання коментарію EX.TASK.NOT.EXIST Користувач відмінив операцію EX.CANCEL.COMMENT |
| Основний сценарій: | 1. Користувач натискає кнопку "Comment" 2. Користувач пише коментарій (можлива EX.CANCEL.COMMENT) 3. Користувач натискає кнопку "Save" (можлива EX.TASK.NOT.EXIST) 4. Cистема зберігає коментарій та повідомляє інших учасників цього завдання про новий коментарій |
| ID | USER.BAN |
|---|---|
| Назва: | Заблокувати користувача |
| Учасники: | Адміністратор системи, користувач, система |
| Передумови: | -Користувач порушив правила проекту -Забезпечення безпеки та ефективної роботи системи |
| Результат: | Користувач заблокований |
| Виключні ситуації: | Користувача вже заблоковано EX.USER.ALREADY.BANNED Натиснута кнопка "Відміна" EX.PRESS.CANCEL |
| Основний сценарій: | 1. Адміністратор виявляє проблемного користувача 2. Адміністратор визначає причину блокування 3. Адміністратор системи натискає кнопку "Заблокувати користувача" 4. Система відправляє форму для блокування(причина, тривалість, тип блокування) (можлива EX.PRESS.CANCEL) 5. Адміністратор системи заповнює форму 6. Система блокує доступ користувачу (можлива EX.USER.ALREADY.BANNED) та повідомляє йому інформацію про блокування 7. Адміністратор дивиться результат блокування |
| ID | USER.UNBAN |
|---|---|
| Назва: | Розблокувати користувача |
| Учасники: | Адміністратор системи, користувач, система |
| Передумови: | Користувач заблокований |
| Результат: | Розблокування акаунта користувача |
| Виключні ситуації: | Натиснута кнопка "Відміна" EX.PRESS.CANCEL |
| Основний сценарій: | 1. Адміністратор знаходить заблокованого користувача 2. Адміністратор визначає причину розблокування 3. Адміністратор системи натискає кнопку "Розблокувати користувача" 4. Система відправляє запит на підтвердження розблокування (можлива EX.PRESS.CANCEL) |
| ID | MEMBER.ADD |
|---|---|
| Назва: | Додати користувача до проекту |
| Учасники: | Користувач (менеджер проекту, тімлід), система |
| Передумови: | -Користувач авторизований -Користувач обрав проект -Користувач має необхідні права доступу до функціоналу системи |
| Результат: | Обраний користувач стає учасником проекту/додається до команди |
| Виключні ситуації: | Такого користувача не існує EX.USER_DONT_EXISTS Користувач вже є учасником проєкту EX.USER_IS_ALREADY_MEMBER |
| Основний сценарій: | 1.Користувач натискає кнопку "Додати учасника" 2.У вікні форми користувач вводить username або адресу електронної пошти учасника 3.4.Користувач натискає кнопку "Додати" 4.Система перевіряє коректність введених даних (можливі EX.USER_DONT_EXISTS, EX.USER_IS_ALREADY_MEMBER) 5.Система надсилає сповіщення користувачу про призначення до проекту/команди 6.Система надсилає сповіщення про успішне призначення користувача 7.Система відображає користувача у списку учасників проекту/команди |
| ID | MEMBER.DELETE |
|---|---|
| Назва: | Видалити користувача з проекту |
| Учасники: | Користувач (менеджер проекту, тімлід), система |
| Передумови: | -Користувач обрав проект -Користувач має необхідні права доступу до функціоналу системи -Існують інші учасники проекту |
| Результат: | Користувач більше не учасник проекту |
| Виключні ситуації: | Натиснута кнопка "Відмінити" EX.CANCEL_DELETE_MEMBER Користувач не має прав для видалення учасника EX.PERMISION_DENIED |
| Основний сценарій: | 1.Користувач відкриває список учасників проекту 2.Користувач ставить "галочку" біля вибраного учасника 3.Користувач нажимає кнопку "Видалити" (можлива EX.PERMISION_DENIED) 4.Система надсилає діалогове вікно з метою підтвердити видалення (можлива EX.CANCEL_DELETE_MEMBER) 5.Користувач підтверджує видалення учасника 6.Система надсилає сповіщення про успішне видалення учасника проекту 7.Система не відображає користувача у списку учасників проекту |
| ID | CREATE.PROJECT |
|---|---|
| Назва: | Створити проект |
| Учасники: | Користувач (менеджер проекту, тімлід), система |
| Передумови: | Користувач авторизований |
| Результат: | Новий проект створений у системі |
| Виключні ситуації: | Проект з такою назвою вже існує EX.PROJECT_NAME_EXISTS Користувач ввів некоректні дані EX.INVALID_DATA Натиснута кнопка "Скасувати" EX.CANCEL |
| Основний сценарій: | 1.Користувач нажимає кнопку "Створити новий проект" 2.Користувач заповнює поля форми (можлива EX.INVALID_DATA) 3.Користувач нажимає кнопку "Створити" (можливі EX.PROJECT_NAME_EXISTS, EX.CANCEL) 4.Система створює проект 5.Система повідомляє користувача про успішне створення проекту 6.Система відкриває новостворений проект |
| ID | DELETE.PROJECT |
|---|---|
| Назва: | Видалити проект |
| Учасники: | Користувач (менеджер проекту), система |
| Передумови: | Існує проект |
| Результат: | Проект створений у системі |
| Виключні ситуації: | Користувач не має прав на видалення проекту EX.PERMISION.DENIED Користувач натиснув кнопку скасувати EX.CANCEL |
| Основний сценарій: | 1.Користувач нажимає кнопку "Видалити проект" 2.Система перевіряє права користувача (можлива EX.PERMISION.DENIED) 3.Система відкриває вікно для підтвердження видалення (можлива EX.CANCEL) 4.Користувач нажимає кнопку "Видалити" 5.Система видаляє проект 6.Система повідомляє користувача про успішне видалення проекту |
| ID | CREATE.SPRINT |
|---|---|
| Назва: | Створити спринт |
| Учасники: | Користувач (менеджер проекту) |
| Передумови: | Користувач авторизований |
| Результат: | Спринт створено |
| Виключні ситуації: | Натиснута кнопка "Скасувати" EX.CANCEL |
| Основний сценарій: | 1.Користувач переходить до типу відображення завдань "Scrum" 2.Користувач натискає кнопку "Cтворити спринт" 3.Користувач вводить ім'я спринта, дату початку, дату завершення та ціль. 4.Користувач обирає завдання на спринт. 5.Користувач натискає на кнопку "Почати спринт"(можлива EX.CANCEL) 6.Система відображає спринт у розділі "Активні спринти" 7.Система повідомляє учасникам спринту інформацію про спринт. |
| ID | FINISH.SPRINT |
|---|---|
| Назва: | Завершити спринт |
| Учасники: | Користувач (менеджер проекту) |
| Передумови: | Користувач авторизований |
| Результат: | Спринт завершено |
| Виключні ситуації: | Натиснута кнопка "Скасувати" EX.CANCEL |
| Основний сценарій: | 1.Користувач переходить до типу відображення завдань "Scrum" 2.Користувач обирає спринт 3.Користувач натискає кнопку "Завершити спринт" 4.Система виводить вікно для підтвердження 5.Користувач підтверджує завершення спринта (можлива EX.CANCEL) 6.Система відображає спринт у розділі "Завершені спринти" 7. Система повідомляє учасників спринта про його завершення |
| ID | TEAMLEAD.REQUEST |
|---|---|
| Назва: | Відправити запит бути тімлідом |
| Учасники: | Учасник проекту, менеджер проекту |
| Передумови: | Користувач авторизований, користувач обрав проект |
| Результат: | Запит відправлено |
| Виключні ситуації: | Натиснута кнопка "Відхилити" EX.DECLINE |
| Основний сценарій: | 1.Учасник проекту натискає кнопку "Стати тімлідом" 2.Система виводить вікно для підтвердження. 3.Учасник проекту натискає кнопку "Надіслати запит"(можлива EX.DECLINE)4.Система надсилає запит менеджеру проекта. |
| ID | TEAMLEAD.APPROVE |
|---|---|
| Назва: | Підтвердити запит учасника проекту бути тімлідом |
| Учасники: | Менеджер проекту, учасник проекту |
| Передумови: | Користувач авторизований, система надіслала повідомлення про запит |
| Результат: | Учаснику надаються права тімліда |
| Виключні ситуації: | Натиснута кнопка "Відхилити" EX.DECLINE |
| Основний сценарій: | 1.Менеджер натискає кнопку "Підтвердити"(можлива EX.DECLINE) 2.Система надає учаснику права тімліда 3.Система надсилає повідомлення учаснику про те, що його запит підтверджено. |
| ID | TEAMLEAD.DECLINE |
|---|---|
| Назва: | Відхилити запит учасника проекту бути тімлідом |
| Учасники: | Менеджер проекту, учасник проекту |
| Передумови: | Користувач авторизований, система надіслала повідомлення про запит |
| Результат: | Учасник не є тімлідом |
| Виключні ситуації: | Відсутні |
| Основний сценарій: | 1.Менеджер натискає кнопку "Відхилити" 2.Система надсилає повідомлення учаснику про те, що його запит відхилено. |
# Короткий огляд продукту
Система управління проектами (Project Management System) має на меті планування, виконання та контроль проектів з метою забезпечення їх успішного завершення в межах визначених строків, бюджету та якості з використанням певної методогії розробки програмного забезпечення.
"Just Chill" - система управління проектами, яка допомогає створювати як великі, так і малі за розміром проекти з використанням доступних в ній функцій. Система полегшує процес розроблення проекту, забезпечуючи організацію проектування та управління ним.
Основні категорії користувачів системи управління проектами включають:
Керівництво проекту: менеджер проектів відповідає за планування, виконання та контроль за проектом, приймають рішення та координують роботу всіх інших учасників проекту.
Команда проекту: фахівці, які відповідають за виконання певних завдань та етапів проекту. Вони забезпечують виконання робіт згідно з планом, надсилають звіти про виконану роботу та повідомляють про проблеми, які виникають в процесі роботи.
Замовник проекту: особа або організація, яка фінансує проект та встановлює вимоги щодо його виконання. Замовник також може бути зацікавлений у звітах про прогрес та результати проекту.
Користувачі проекту: особи, які отримують користь від результатів проекту. Це є клієнти, партнери, співробітники та інші зацікавлені особи.
Аналітики проекту: фахівці, які займаються аналізом результатів проекту та роблять висновки щодо його ефективності, допомагають виявляти проблеми та запропонувати шляхи їх вирішення в майбутньому.
# Функціональність
Для того, щоб впорядкувати взаємодію між різними ролями користувачів системи та автоматизувати поділ на ці ролі, система повинна мати відповідні режими, кожен з яких буде реалізований через відповідний йому інтерфейс.
# Інтерфейс менеджера проектів
Інтерфейс менеджера проектів представляє собою розширений інтерфейс тімліда з додатковими можливостями та правами керування проектом загалом.
Можливості:
- створювати та видаляти проект
- додавати та видаляти учасників проекту
- підтверджувати та відхиляти кандидатуру на тімліда
- призначати завдання командам
- додавати, редагувати та видаляти завдання
- створювати та завершувати спринти
- відстежувати ресурси і прогрес проекту
- коментувати завдання
# Інтерфейс тімліда
Інтерфейс тімліда є розширеним інтерфейсом розробника з додатковою функціональністю та правами керування командою.
Можливості:
- додавати та видаляти учасників в команду
- додавати, редагувати та видаляти завдання для команди
- призначати завдання учасникам команди
- відстежувати ресурси і прогрес проекту
- коментувати завдання
# Інтерфейс розробника
Інтерфейс розробника передбачає базовий інтерфейс користувача системи.
Можливості:
- додавати, редагувати та видаляти власні завдання
- відстежувати ресурси і прогрес проекту
- коментувати завдання
# Інтерфейс адміністратора
Інтерфейс адміністратора системи включає найбільш повні права, адміністратор має доступ до бази даних та може надати технічну допомогу користувачам.
Можливості:
- заблокувати та розблокувати користувача
- приймати і відповідати на запити про технічну підтримку
# Практичність
Система повинна:
- забезпечити низький поріг входження для користувача: інтуїтивно-зрозумілий інтерфейс, підказки, туторіали, повідомлення про помилки та можливі шляхи їх вирішення
- підтримувати багатомовність
- зручно та легко налаштовуватись під конкретний проект
- підтримувати використання гарячих клавіш
- забезпечити технічну підтримку онлайн
- бути придатною до використання на різних пристроях/операційних системах/версіях програмного забезпечення
- мати можливості відновлення нещодавно видалених даних та втраченого доступу до аккаунту
# Надійність
Система повинна:
- мати можливість підключити додатковий захист інформації (двофакторну автентифікацію за електронною поштою, номером телефона тощо)
- надсилати запит на авторизацію користувача перед кожною сесією використання системи
- володіти засобами шифрування інформації (особистих даних користувачів, даних проектів)
- автоматично блокувати надмірну та/або незвичну активність (перевищення кількості користувачів, занадто часте створення проектів/завдань тощо)
- автоматично блокувати спроби злому через вікно реєстрації (тимчасовий бан після декількох разів неправильно введеного паролю)
- повідомляти адміністратора про помилки, несправності
- регулярно створювати резервні копії даних
- забезпечувати обслуговування заявленої максимальної кількості користувачів одночасно
# Продуктивність
Система повинна:
- швидко приймати запити користувачів і віддавати дані без суттєвих затримок
- самостійно обирати спосіб оптимізації даних і виділяти пам’ять під їх зберігання
- ефективно використовувати ресурси пам’яті (оперативної та довгострокової), хмар і серверів
- мати високу пропускну здатність
- надавати можливість одночасно працювати в одному проекті великій кількості користувачів
- вивантажувати давно не використовувані дані в хмари
- обмежувати кількість символів в назвах проектів і завдань, розмір доданих зображень тощо
- безперервно контролювати роботу системи і підлаштовувати її під вимоги кожної конкретної ситуації
# Експлуатаційна придатність
Система повинна:
- постійно підтримувати виконання своїх зобов’язань
- пропонувати надсилати запит до розробників при несправностях та інших проблемах
- мати швидкий зворотній зв’язок від розробників системи
- приймати доробки і оновлення за потреби
- підтримувати сумісність з різним програмним і апаратним забезпеченням
- запобігати виникненню перенавантажень системи
- мати змогу еефективно діяти при непередбачуваних ситуаціях
- бути здатною оптимізувати робочі процеси (такі, що часто повторюються, що потребують великого об’єму пам’яті і тд.)
- аналізувати недоліки і дефекти своєї роботи та пропонувати варіанти їх виправлення