чекліст вимог до курсового проєкту

project_requirements_and_defense_checklist.md

Вимоги до проєкту та захисту

Зміст

1. Product
2. Architecture
3. Data
4. Security
5. Quality
6. DevOps та командна робота
7. Documentation
8. Team
9. Defense
10. Demo readiness
11. Підсумкова модель оцінювання

---

1. Product

1.1. SRS та вимоги

• Наявна оформлена SRS (Software Requirements Specification)
• SRS містить функціональні вимоги - що конкретно має робити система
• SRS містить нефункціональні вимоги - як система працює, які її якісні характеристики, стандарти роботи всього додатка (Продуктивність, Масштабованість, Безпека, Надійність, Зручність використання)
• Реалізована функціональність відповідає заявленим вимогам SRS
• Є можливість продемонструвати відповідність ключових функцій вимогам SRS
• Наявний потижневий план виконання робіт

1.2. Проблема та потреба

• Чітко сформульована проблема, яку вирішує проєкт
• Визначена реальна потреба користувача
• Наведено 1–2 приклади з реального життя, які демонструють проблему

1.3. Цільова аудиторія

• Визначена цільова аудиторія
• Сформовано 1–3 персони
• Для кожної персони визначено:
  • хто це
  • приблизний вік
  • де та в яких умовах використовуватиме продукт
  • яку потребу продукт задовольняє

1.4. UI/UX та дослідження

За наявності відповідного сценарію:

• UI Kit
• Аналіз конкурентів
• Карти емпатії
• Customer Journey Map (CJM)
• Інформаційна архітектура (IA)
• Результати UX/UI-дослідження
• Основні висновки дослідження враховані в реалізації

1.5. Логічна завершеність

• Основний користувацький сценарій можна пройти від початку до кінця
• Реалізована ключова функціональність
• Немає критичних незавершених частин, які блокують демонстрацію
• Проєкт має зрозумілу логіку та цілісний користувацький сценарій

---

2. Architecture

2.1. ООП та принципи проєктування

• Використані принципи об'єктно-орієнтованого проєктування
• Дотримуються принципи SOLID
• Забезпечено low coupling
• Забезпечено high cohesion
• Відповідальності класів та компонентів розподілені логічно
• Архітектурні рішення мають зрозуміле обґрунтування

2.2. Архітектура бекенду

• Clean Architecture / Onion Architecture
• Чітко визначені межі між шарами та залежності проєктів в рамках рішення
• Domain є ядро системи і не залежить від жодних інших шарів (ні від Application, ні від Infrastructure, ні від Web/API)
• Application-шар містить бізнес-логіку сценаріїв використання (Use Cases) та залежить виключно від Domain
• Infrastructure реалізує технічні деталі (бази даних, зовнішні API) та ізольована від Application завдяки винесенню інтерфейсів (контрактів) у Domain або спільні абстракції, що усуває пряму залежність інфраструктури від бізнес-логіки
• Залежності між проєктами суворо спрямовані всередину (від зовнішніх шарів до доменного ядра)
• Presentation/API відповідає за HTTP-рівень та взаємодію із клієнтом, викликаючи виключно сервіси шару Application

2.3. Dependency Injection

• Використовується Dependency Injection (DI)
• Залежності передаються через абстракції там, де це виправдано
• Реєстрація залежностей централізована та зрозуміла
• DI не використовується формально там, де він не дає користі

2.4. Патерни проєктування

За потреби проєкту можуть використовуватися:

• GoF patterns
• Pipeline / Middleware Pattern
• Repository Pattern
• Unit of Work
• CQRS
• Інші патерни, якщо вони вирішують конкретну архітектурну проблему

Важливо: патерни не потрібно додавати формально лише для виконання вимоги. Кожне архітектурне або проєктувальне рішення повинно мати обґрунтування та відповідати реальній потребі проєкту.

2.5. Архітектурна схема

У документації та презентації бажано показати:

Frontend (React)
   │
   ▼
Backend / API
   │
   ├── Application
   ├── Domain
   └── Infrastructure
           │
           ▼
      Database / External APIs

Конкретна схема повинна відповідати фактичній архітектурі проєкту!

---

3. Data

3.1. Система зберігання даних

Допускається використання:

• SQL Server
• Firestore
• PostgreSQL

Вибір СУБД повинен відповідати вимогам та сценаріям конкретного проєкту.

3.2. Проєктування бази даних

• Визначені основні сутності
• Визначені зв'язки між сутностями
• Структура даних обґрунтована
• Для SQL використовується ER-діаграма
• Для Firestore показана структура колекцій та документів
• Визначені необхідні індекси
• Структура даних не містить очевидного дублювання або нелогічних залежностей

3.3. Доступ до даних

За наявності відповідного сценарію:

• Entity Framework Core
• Dapper
• Repository / Unit of Work
• Migrations
• Seed-дані

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

---

4. Security

4.1. Authentication та Authorization

• Реалізована аутентифікація користувачів
• Реалізована авторизація користувачів
• Перевірка прав доступу виконується на рівні API
• Ролі / claims / permissions використовуються відповідно до логіки проєкту
• Користувач не може отримати доступ до ресурсів, на які він не має прав

4.2. Паролі

Якщо проєкт самостійно зберігає паролі:

• Паролі не зберігаються у відкритому вигляді
• Використовується безпечне hash + salt
• Для зберігання паролів не використовується прості алгоритми накшталт SHA256(password)

Якщо використовується зовнішній Identity Provider, наприклад Firebase Authentication, необхідно чітко пояснити, де та як фактично зберігаються облікові дані

4.3. Захист вебзастосунку від вразливостей

Необхідно врахувати:

• SQL Injection
• XSS
• CSRF або відповідний механізм захисту залежно від способу автентифікації
• BOLA / IDOR
• Несанкціонований доступ до API
• Безпечну роботу із секретами
• Перевірку authorization на рівні API

4.4. Secrets та configuration

• Конфігурація винесена в environment variables / configuration
• Паролі, токени, API keys та інші секрети не зберігаються у Git
• .gitignore налаштований коректно
• У репозиторії немає реальних секретів
• Для локального запуску є приклад конфігурації, наприклад .env.example або відповідний configuration template

---

5. Quality

5.1. Асинхронне програмування

• Використовується async/await
• Використовується Task / відповідні асинхронні API
• I/O-операції не блокують потоки без необхідності.
• Не використовується async формально там, де асинхронність не має сенсу

5.2. Багатопоточність та parallel execution

Не є обов'язковою для кожного проєкту.

Якщо в проєкті є відповідний сценарій:

• Визначено операції, які можуть виконуватися паралельно
• Обґрунтовано використання parallel execution / multithreading
• Враховано race conditions та thread safety
• Паралельне виконання не створює неконтрольованих побічних ефектів

5.3. Validation

• Виконується валідація вхідних даних на стороні клієнта (бажано)
• Виконується валідація вхідних даних на стороні сервера (обов'язково)
• Сервер не покладається лише на client-side validation
• Некоректні дані повертають зрозумілу помилку

5.4. Кешування

Не є обов'язковим для кожного проєкту.

Якщо є дані або операції, для яких кешування має сенс:

• Визначено, що саме кешується
• Обґрунтовано необхідність кешування
• Визначено стратегію invalidation / expiration
• Кеш не призводить до використання критично застарілих даних

5.5. Логування

• Логуються ключові операції
• Логуються помилки
• Логи містять достатній контекст для діагностики
• Не логуються паролі, токени та інші секрети
• За потреби використовується централізований logging framework, наприклад Serilog

5.6. Централізована обробка винятків

• Є централізований механізм обробки винятків
• Непередбачені помилки не призводять до неконтрольованої поведінки API
• Помилки перетворюються на коректні HTTP-відповіді
• У production-відповідях не розкривається внутрішня технічна інформація

5.7. HTTP-помилки

Проєкт повинен коректно обробляти щонайменше:

Код	Сценарій
401 Unauthorized	Користувач не автентифікований
403 Forbidden	Користувач автентифікований, але не має необхідних прав
404 Not Found	Ресурс не знайдений
500 Internal Server Error	Непередбачена серверна помилка

• Для помилок сформовані коректні HTTP-відповіді
• За потреби реалізовані відповідні error pages / error responses
• Під час демонстрації не відбулось неперехоплених помилок

5.8. Тестування

• Є unit tests
• Є integration tests
• Тести перевіряють критичну бізнес-логіку
• Відомий поточний code coverage % (Test -> Analyze Code Coverage, dotnet add package coverlet.collector, dotnet test --collect:"XPlat Code Coverage")
• Для .NET-проєкту використовуються xUnit / NUnit

---

6. DevOps та командна робота

6.1. Git та GitHub

• Код зберігається в загальному для всіх учасників Git-репозиторії
• Використовується GitHub
• Робота ведеться через branches
• Використовуються merge / pull requests відповідно до workflow команди
• Історія комітів відображає реальну роботу команди (видно послідовну роботу протягом 1-2 місяців)
• Внесок кожного учасника можна ідентифікувати

6.2. Scrum

• Визначені дати спринтів
• Є backlog
• Є Kanban-дошка
• Використовується Jira або аналогічний інструмент.
• Збережені результати роботи спринтів
• Для презентації підготовлені відповідні скріншоти / діаграми

6.3. CI/CD

За наявності відповідної інфраструктури:

• Налаштований GitHub Actions
• Виконується автоматична збірка
• Автоматично запускаються тести
• Виконується автоматичний deployment
• CI/CD pipeline можна продемонструвати

6.4. Deployed application

• Наявне посилання в чаті тімсу на задеплоєну frontend-частину (скинути перед демо)
• Задеплоєний frontend доступний для перевірки в день захисту
• Якщо є backend deployment, його також можна продемонструвати
• У README наведені актуальні посилання на deployed application

---

7. Documentation

7.1. README.md

У репозиторії повинен бути оформлений README.md, якого достатньо для відтворення проєкту на чистому середовищі.

README повинен містити:

• Опис проєкту
• Основну проблему та мету.
• Features / функціональність
• Architecture overview
• Prerequisites
• Installation
• Configuration
• Environment variables
• Database setup
• Migrations
• Seed
• Запуск backend
• Запуск frontend
• Запуск тестів
• Docker
• Посилання на deployed application
• Посилання на документацію (DocFX)
• Посилання на API (Scalar)
• Інші необхідні кроки для повного відтворення проєкту

7.2. Документаційні коментарі

• У коді присутні документаційні коментарі на всіх публічних класах, методах та властивостях
• Є окремі коментарі, що пояснюють складну логіку, контракти або призначення API
• Коментарі не дублюють очевидний код
• Коментарі підтримуються в актуальному стані

7.3. HTML-документація

• Підготовлена оформлена документація у вигляді HTML-сторінок
• Документація опублікована через GitHub Pages
• Для генерації документації використовується DocFX.
• В рідмі є посилання на опубліковану документацію

7.4. API documentation

• Описаний REST API
• Наведені основні (бажано всі) endpoints
• Вказані HTTP methods
• Вказані status codes
• Описані authentication / authorization
• Наявна OpenAPI-документація
• Використовується Scalar.

---

8. Team

8.1. Склад команди

Рекомендований склад:

2–4 учасники.

Для кожного учасника необхідно визначити:

• ім'я та прізвище
• роль
• зону відповідальності
• конкретний виконаний обсяг робіт

8.2. Індивідуальний внесок

Кожен учасник під час захисту має доповісти про виконану саме ним роботу.

Необхідно мати підтвердження внеску:

• Git commits
• Branches
• Pull requests / merges
• Реалізовані features
• Тести
• Документація
• UI/UX-робота
• Інші конкретні результати

---

9. Defense

Презентація повинна містити 7–15 слайдів.

Рекомендована структура

Слайд 1. Проєкт

• Назва проєкту
• Короткий опис
• Учасники
• Контакти
• QR-код / посилання на сайт та репозиторій

Слайд 2. Проблема

• Яку проблему вирішує проєкт
• Який біль або потреба існує
• 1–2 приклади з реального життя

Слайд 3. Цільова аудиторія

• 1–3 персони
• Хто користувач
• Вік
• Контекст використання
• Потреби користувача

Слайд 4. UI/UX та дослідження

Дуже бажано:

• UI Kit
• Аналіз конкурентів
• Empathy Map
• Customer Journey Map
• Information Architecture
• Результати дослідження

Слайд 5. Архітектура

Показати:

Frontend
    ↓
Backend / API
    ↓
Application
    ↓
Domain
    ↓
Infrastructure
    ↓
Database / External Services

Також:

• діаграма класів
• діаграма розміщення
• зовнішні API / сервіси

Слайд 6. Clean / Onion Architecture

• Пояснити використану архітектуру
• Показати схему зв'язків між проєктами
• Пояснити напрямок залежностей
• Пояснити, чому обрана архітектура доречна саме для цього проєкту

Слайд 7. Патерни

Показати фактично використані патерни:

• GoF
• DI
• Repository
• Unit of Work
• Pipeline / Middleware
• Інші

Для кожного важливого патерна:

Проблема → рішення → чому саме цей патерн.

Слайд 8. База даних

• ER-діаграма або структура Firestore
• Основні сутності
• Зв'язки
• Індекси
• Обґрунтування структури
• EF Core / Dapper, якщо використовується

Слайд 9. Результати

Ключові метрики:

• кількість реалізованих features
• час розробки
• code coverage %
• кількість тестів
• кількість комітів
• розмір проєкту
• кількість користувачів, якщо є
• інші релевантні метрики

Слайд 10. Git та командна робота

• Git branches
• Pull requests / merge
• Коміти
• Внесок кожного учасника
• Scrum
• Sprint dates
• Kanban
• Backlogs

Слайд 11. Tools & Workflow

Показати логотипами використані інструменти, наприклад:

• Visual Studio 2026 / Rider / VS Code
• Git + GitHub
• Firebase / SQL Server / PostgreSQL
• EF Core / Dapper
• xUnit / NUnit
• Serilog
• Docker
• Scalar
• DocFX
• Jira
• Postman
• Figma

Показувати лише ті інструменти, які реально використовувалися.

Слайд 12. SRS та план

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

Слайд 13. Testing & Logging

Показати:

• Unit tests
• Integration tests
• Скріншоти тестів
• Code coverage
• Логування
• 1–2 скріншоти логів

Слайд 14. Documentation, API та CI/CD

Показати:

• README
• DocFX
• GitHub Pages
• Scalar / OpenAPI, REST API endpoints
• HTTP methods
• Status codes
• Authentication / Authorization
• GitHub Actions
• Build
• Tests
• Deployment

Слайд 15. Майбутнє та Q&A

• Чому проєкт важливий
• Потенціал у реальному світі
• Можливість монетизації
• Open-source потенціал
• Портфоліо-цінність
• Дякуємо за увагу
• Q&A
• Контакти / посилання / QR-код

Ключова думка проєкту: одне коротке речення, яке пояснює головну цінність продукту.

---

10. Demo readiness

10.1. Демонстраційний сценарій

• Підготовлений чіткий сценарій демонстрації
• Відомо, які функції демонструються
• Відомо, у якій послідовності проходить demo
• Перед демонстрацією перевірено працездатність основного сценарію

10.2. Тестові користувачі

• Є тестові користувачі
• Є користувачі з різними ролями
• Для кожної ролі підготовлено відповідний сценарій
• Дані для demo підготовлені заздалегідь

10.3. Тестові дані

• Є реалістичні тестові дані
• Дані не виглядають випадковими або абсурдними
• Підготовлені записи для демонстрації ключових сценаріїв
• Немає залежності demo від ручного створення великої кількості даних у момент захисту

Не треба демонструвати «кілограми цегли» в системі, де цегла взагалі не є змістовною тестовою сутністю. Дані повинні підтримувати сценарій, а не існувати заради кількості.

10.4. Backup demo (необов'язково)

• Є backup/demo video тривалістю до 2 хвилин
• Відео демонструє основний сценарій
• Відео готове до використання у разі відсутності світла або інтернету

10.5. Відтворення проєкту

• Проєкт можна запустити за інструкцією з README
• Вказані всі prerequisites
• Вказані environment variables
• Описано налаштування БД
• Описано запуск backend
• Описано запуск frontend
• Описано запуск тестів
• За потреби описано Docker

---

11. Підсумкова модель оцінювання

Product

SRS
 ↓
Проблема та потреба
 ↓
Цільова аудиторія
 ↓
Функціональні вимоги
 ↓
Нефункціональні вимоги
 ↓
Відповідність реалізації SRS
 ↓
UI/UX
 ↓
Логічна завершеність
 ↓
Demo readiness

Architecture

ООП
 ↓
SOLID
 ↓
Low Coupling / High Cohesion
 ↓
Clean / Onion Architecture
 ↓
Dependency Injection
 ↓
GoF Patterns
 ↓
Pipeline / Middleware
 ↓
Repository / Unit of Work
 ↓
Обґрунтованість архітектурних рішень

Data

SQL Server / PostgreSQL / Firestore
 ↓
Проєктування структури даних
 ↓
ER-діаграма / структура Firestore
 ↓
Сутності та зв'язки
 ↓
Індекси
 ↓
EF Core / Dapper
 ↓
Конфігурація доступу до даних

Security

Authentication
 ↓
Authorization
 ↓
Authorization на рівні API
 ↓
Input Validation
 ↓
SQL Injection
 ↓
XSS
 ↓
CSRF / відповідний механізм захисту
 ↓
BOLA / IDOR
 ↓
Hash + Salt
 ↓
Environment Variables / Configuration
 ↓
Безпечне зберігання секретів
 ↓
Відсутність секретів у Git

Quality

async/await
 ↓
Task
 ↓
Parallel Execution / Multithreading*
 ↓
Caching*
 ↓
Unit Tests
 ↓
Integration Tests
 ↓
Logging
 ↓
Centralized Exception Handling
 ↓
HTTP 401 / 403 / 404 / 500
 ↓
Відсутність неперехоплених помилок

* Не є обов'язковим для кожного проєкту. Використовується за наявності обґрунтованого сценарію.

DevOps

Git
 ↓
GitHub
 ↓
Branches
 ↓
Merge / Pull Requests
 ↓
Scrum
 ↓
Sprints
 ↓
Backlog
 ↓
Kanban
 ↓
CI/CD
 ↓
Automatic Build
 ↓
Automatic Tests
 ↓
Automatic Deployment*
 ↓
Deployed Frontend

* За наявності відповідної інфраструктури.

Documentation

Documentation Comments
 ↓
SRS
 ↓
README.md
 ↓
Clean Environment Setup
 ↓
Prerequisites
 ↓
Installation
 ↓
Configuration
 ↓
Environment Variables
 ↓
Database Setup / Migrations
 ↓
Seed
 ↓
Backend / Frontend
 ↓
Tests
 ↓
Docker
 ↓
DocFX
 ↓
HTML Documentation
 ↓
GitHub Pages
 ↓
OpenAPI / Scalar
 ↓
API Documentation

Team

2–4 учасники
 ↓
Розподіл роботи
 ↓
Індивідуальний внесок від кожного тіммейта
 ↓
Git Branches / Merge / Commits
 ↓
Scrum
 ↓
Sprint Dates
 ↓
Backlog
 ↓
Kanban
 ↓
Jira / Trello
 ↓
Індивідуальна доповідь від кожного тіммейта

Defense

Презентація 7–15 слайдів
 ↓
Проблема
 ↓
Реальні приклади
 ↓
Персони
 ↓
UI Kit / Конкуренти / Empathy Maps / CJM / IA
 ↓
Архітектура
 ↓
Clean / Onion
 ↓
Patterns
 ↓
Database
 ↓
Metrics
 ↓
Git
 ↓
Tools / Workflow
 ↓
Scrum
 ↓
SRS
 ↓
Testing
 ↓
Logging
 ↓
Documentation
 ↓
REST API
 ↓
CI/CD
 ↓
Потенціал проєкту
 ↓
Q&A
 ↓
Live Demo
 ↓
Test Users + Test Data
 ↓
Backup Video ≤ 2 хв
 ↓
Links / QR
 ↓
Ключова думка проєкту одним реченням

---

Важливе правило щодо технологій

Технологічна вимога не означає, що кожна технологія повинна бути використана в кожному проєкті.

Зокрема, SignalR, мікросервіси, EF Core / Dapper, кешування та багатопоточність не є обов'язковими самі по собі.

Правильний підхід:

Потреба → проблема → архітектурне рішення → технологія → обґрунтування.

Неправильний підхід:

Вимога → додамо технологію бо так просив Олександр → придумаємо, навіщо вона потрібна.

Використання технології без функціональної або архітектурної необхідності не вважається перевагою.

---

Фінальний checklist перед захистом

Product

• SRS готовий
• Функціональні вимоги описані
• Нефункціональні вимоги описані
• Реалізація відповідає SRS
• Проблема сформульована
• Цільова аудиторія визначена
• UI/UX-дослідження підготовлені
• Проєкт логічно завершений

Architecture

• ООП
• SOLID
• Low coupling / high cohesion
• Clean / Onion Architecture
• DI
• Патерни обґрунтовані
• Архітектурна схема готова

Data

• СУБД налаштована
• Структура даних спроєктована
• ER-діаграма / Firestore structure готова
• Індекси визначені
• Migrations / Seed готові

Security

• Authentication
• Authorization
• API authorization
• Validation
• SQL Injection protection
• XSS protection
• CSRF / відповідний механізм
• BOLA / IDOR protection
• Password hashing
• Secrets management
• Secrets відсутні в Git

Quality

• async/await
• Task
• Multithreading / parallel execution, якщо потрібні
• Caching, якщо потрібне
• Unit tests
• Integration tests
• Logging
• Centralized exception handling
• 401 / 403 / 404 / 500
• Немає неперехоплених помилок

DevOps

• Git
• GitHub
• Branches
• Merge / Pull Requests
• Scrum
• Sprints
• Backlog
• Kanban
• CI/CD
• Automated build
• Automated tests
• Deployment

Documentation

• README.md
• Prerequisites
• Installation
• Configuration
• Environment variables
• Database setup
• Migrations
• Seed
• Backend запуск
• Frontend запуск
• Tests
• Docker
• DocFX
• GitHub Pages
• OpenAPI / Scalar

Team

• Визначені ролі
• Визначений внесок кожного
• Git history підтверджує внесок
• Кожен учасник готовий доповісти про власну роботу

Defense

• Презентація 7–15 слайдів
• Live demo
• Тестові користувачі
• Різні ролі
• Підготовлені тестові дані
• Demo script
• Backup video ≤ 2 хв
• QR-коди / посилання
• Готові відповіді щодо архітектури, безпеки, тестування та SRS

---

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