jean/time-tracker
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
time-tracker/docu/draft/grok.md
Jean Jacques Avril e31b93df93 concept
2025-03-09 08:16:30 +00:00

10 KiB
Raw Blame History

Ich habe Ihre Anfrage analysiert und die bestehende Dokumentation aktualisiert, um Ihre Anforderungen für ein Zeiterfassungstool zu berücksichtigen. Das Tool soll als Multi-Tenant-Lösung fungieren, in Go (Backend) und Next.js (Frontend) mit FPGO und FPTS für funktionale Programmierung umgesetzt werden. PostgreSQL wird als Datenbank mit einem ORM verwendet, und eine Swagger-Dokumentation wird für die API erstellt. Der Code wird in kleinere, übersichtliche Module und Dateien aufgeteilt, um die Implementierung mit LLMs zu erleichtern. Im Folgenden finden Sie die überarbeitete Spezifikation, die alle Anforderungen für Version 1 sowie geplante Erweiterungen für Version 2 abdeckt.

Software Requirements Specification

für das Time Tracking and Management System

Version 1.3
Erstellt von: Jean Jacques Avril, Masterstudent, Informatik, Technische Hochschule Rosenheim
Modul: Konzepte der Programmiersprachen
Datum: 5. Januar 2025

1. Einführung

1.1 Zweck

Dieses Software Requirements Specification (SRS) Dokument beschreibt detailliert die Anforderungen für das Time Tracking and Management System, eine Multi-Tenant-Lösung zur präzisen Erfassung und Verwaltung von Arbeitszeiten für mehrere Unternehmen. Jedes Unternehmen kann eigene Kunden, Projekte und Mitarbeiter verwalten. Das System unterstützt verschiedene Benutzerrollen (User, Manager, Auditor, Company, Admin) mit spezifischen Berechtigungen und Funktionen. Ziel ist es, eine klare Grundlage für die Entwicklung zu schaffen, die eine einfache Implementierung und Erweiterbarkeit ermöglicht.

1.2 Zielgruppe und Leseempfehlungen

Dieses Dokument richtet sich an:

  • Projektbeteiligte: Für ein umfassendes Verständnis der Funktionen und Einschränkungen.
  • Entwickler: Zur Einsicht in funktionale und nicht-funktionale Anforderungen für eine reibungslose Umsetzung.
  • Qualitätssicherungsteams: Um Tests an den spezifizierten Anforderungen auszurichten.
  • Zukünftige Mitwirkende: Um die Systemarchitektur zu verstehen und Erweiterungen beizutragen.

Leser sollten zunächst die funktionalen Anforderungen durchsehen, um die Kernfunktionen zu verstehen, gefolgt von den nicht-funktionalen Anforderungen für Einblicke in Sicherheit und Performance. Entwickler mit Fokus auf Backend und Architektur sollten die Abschnitte zur Systemarchitektur und Technologie besonders beachten.

1.3 Projektumfang

Das Time Tracking and Management System bietet eine benutzerfreundliche Plattform zur Zeiterfassung, Verwaltung von Projekten und Erstellung von Berichten in einer Multi-Tenant-Umgebung.

Version 1 (Initiale Version):

  • Multi-Tenant-Unterstützung mit Datenisolierung.
  • Benutzerverwaltung mit Rollen: User, Manager, Auditor, Company, Admin.
  • Verwaltung von Kunden, Projekten und Tätigkeiten je Unternehmen.
  • Zeiterfassung mit Buchungen (Zeit, Ort, Zweck, Mitarbeiter, Tätigkeit, Beschreibung, Verrechnungspreis, abrechenbarer Prozentsatz).
  • Berichte und Dashboards mit PDF-Export und grafischen Darstellungen.
  • Tracker auf der Startseite mit Standardwerten der letzten Buchung.

Version 2 (Zukünftige Erweiterungen):

  • Projekte mit Sprints und Task-Items.
  • Kanban-Boards zur Aufgabenzuweisung.
  • Direkte Task-Auswahl bei Buchungen.

Die modulare Architektur ermöglicht einfache Erweiterungen.

2. Anforderungen

2.1 Funktionale Anforderungen

FA-1: Multi-Tenant-Unterstützung

  • Beschreibung: Das System muss mehrere Unternehmen (Tenants) unterstützen, jedes mit isolierten Daten.
  • Details: Jedes Unternehmen hat eigene Kunden, Projekte, Tätigkeiten, Mitarbeiter und Buchungen.
  • Validierung: Kein Zugriff auf Daten anderer Tenants möglich.

FA-2: Benutzerverwaltung

  • Beschreibung: Benutzer können sich registrieren, anmelden und Rollen zugewiesen bekommen.
  • Details:
    • Rollen: User (Zeiterfassung), Manager (Projektübersicht), Auditor (Berichte einsehen), Company (Verwaltung), Admin (Systemweit).
    • Admin verwaltet Unternehmen, Company verwaltet eigene Daten.
  • Validierung: Eindeutige Benutzernamen und E-Mails pro Tenant.

FA-3: Kundenverwaltung

  • Beschreibung: Unternehmen können Kunden anlegen, bearbeiten und löschen.
  • Details: Kunden sind unternehmensspezifisch.
  • Validierung: Nur Company- und Admin-Rollen dürfen Kunden verwalten.

FA-4: Projektverwaltung

  • Beschreibung: Unternehmen können Projekte für Kunden anlegen, bearbeiten und löschen.
  • Details: Projekte sind mit Kunden und Unternehmen verknüpft.
  • Validierung: Nur Company- und Manager-Rollen dürfen Projekte verwalten.

FA-5: Tätigkeitsverwaltung

  • Beschreibung: Unternehmen können Tätigkeiten mit Verrechnungspreisen definieren.
  • Details: Tätigkeiten sind unternehmensspezifisch.
  • Validierung: Verrechnungspreise müssen positiv sein.

FA-6: Mitarbeiterverwaltung

  • Beschreibung: Unternehmen können Mitarbeiter mit Stundensätzen verwalten.
  • Details: Mitarbeiter sind unternehmensspezifisch.
  • Validierung: Stundensätze müssen positiv sein.

FA-7: Buchungsverwaltung

  • Beschreibung: Benutzer können Zeitbuchungen erfassen.
  • Details: Buchungen enthalten Zeit, Ort, Zweck, Mitarbeiter, Tätigkeit, optionale Beschreibung, Verrechnungspreis und abrechenbaren Prozentsatz (0-100%).
  • Validierung: Buchungen müssen gültige Projekte und Tätigkeiten referenzieren.

FA-8: Zeiterfassung

  • Beschreibung: Benutzer können einen Tracker starten und stoppen.
  • Details: Ohne Auswahl werden die Parameter der letzten Buchung übernommen.
  • Validierung: Kein Start möglich, wenn bereits aktiv.

FA-9: Berichte

  • Beschreibung: Berichte können über Projekte, Mitarbeiter, Kunden und Zeiträume erstellt werden.
  • Details: Berichte enthalten Arbeitszeit, abrechenbare Beträge und können als PDF exportiert werden.
  • Validierung: Nur autorisierte Rollen dürfen Berichte generieren.

FA-10: Dashboard

  • Beschreibung: Benutzer sehen auf der Startseite letzte Buchungen und einen Tracker.
  • Details: Dashboards zeigen grafische Zusammenfassungen.

2.2 Nicht-funktionale Anforderungen

NFA-1: Sicherheit

  • Beschreibung: Datenisolierung zwischen Tenants und sicherer Zugriff.
  • Details: RBAC, JWT-Authentifizierung, Verschlüsselung sensibler Daten.

NFA-2: Performance

  • Beschreibung: API-Antwortzeit unter 200 ms.
  • Details: Optimierte Datenbankabfragen und Caching.

NFA-3: Skalierbarkeit

  • Beschreibung: Unterstützung vieler gleichzeitiger Benutzer und Tenants.
  • Details: Horizontale Skalierung möglich.

NFA-4: Benutzbarkeit

  • Beschreibung: Intuitive und responsive Benutzeroberfläche.
  • Details: Kompatibel mit Desktop, Tablet und Mobilgeräten.

NFA-5: Modularität

  • Beschreibung: Code in kleine, überschaubare Module aufteilen.
  • Details: Erleichtert die Entwicklung mit LLMs.

3. Technische Spezifikation

3.1 Gesamtarchitektur

Das System ist eine Full-Stack-Webanwendung:

  • Frontend: Next.js mit React und FPTS.
  • Backend: Go mit FPGO.
  • Datenbank: PostgreSQL mit GORM als ORM.
  • API-Dokumentation: Swagger für RESTful APIs.
  • Kommunikation: RESTful APIs, optional WebSockets für Echtzeitfunktionen.

3.2 Technologie-Stack

3.2.1 Frontend

  • Next.js/React: Für interaktive Benutzeroberflächen.
  • FPTS: Funktionale Programmierung in TypeScript.
  • Axios: Für HTTP-Anfragen.

3.2.2 Backend

  • Go: Hauptsprache für Backend.
  • FPGO: Funktionale Programmierung in Go.
  • GORM: ORM für PostgreSQL.
  • Gin: Web-Framework für HTTP-Anfragen.
  • JWT: Für sichere Authentifizierung.

3.2.3 Datenbank

  • PostgreSQL: Relationale Datenbank.

3.3 Entitäten

  • Company: Tenant-Daten.
  • User: Mit Rollen und Unternehmenszuordnung.
  • Client: Unternehmensspezifisch.
  • Project: Mit Kunden und Unternehmen verknüpft.
  • Activity: Mit Verrechnungspreis.
  • Employee: Mit Stundensatz.
  • Booking: Zeitbuchungen mit Details.

4. Systemdesign

4.1 Übersicht

Das System folgt Domain-Driven Design (DDD) und Clean Architecture mit einer Multi-Tenant-Architektur (gemeinsame Datenbank mit Tenant-IDs).

4.2 Architekturdesign

  • Domain-Schicht: Geschäftlogik und Entitäten.
  • Application-Schicht: Services und Anwendungsfälle.
  • Infrastructure-Schicht: Datenbankzugriff via GORM.
  • Interface-Schicht: API-Handler.
  • Frontend: Next.js mit FPTS.

4.3 Moduldesign

  • Benutzerverwaltung: Registrierung, Authentifizierung.
  • Unternehmensverwaltung: Tenant-Daten.
  • Projektverwaltung: Projektzuweisungen.
  • Buchungsverwaltung: Zeiterfassung.
  • Berichte: Generierung und Export.

4.4 Datenbankdesign

  • Companies: id, name, created_at, updated_at.
  • Users: id, company_id, role, name, email, password_hash.
  • Clients: id, company_id, name.
  • Projects: id, client_id, company_id, name.
  • Activities: id, company_id, name, billing_rate.
  • Employees: id, company_id, name, hourly_rate.
  • Bookings: id, user_id, project_id, activity_id, start_time, end_time, description, billable_percentage.

5. API-Endpunkte

5.1 Übersicht

RESTful API mit Swagger-Dokumentation, gesichert durch JWT und RBAC.

5.2 Endpunkte

5.2.1 Authentifizierung

  • POST /api/auth/register: Neuer Benutzer.
  • POST /api/auth/login: Login mit JWT.
  • POST /api/auth/logout: Logout.
  • GET /api/auth/me: Benutzerdetails.

5.2.2 Unternehmensverwaltung (Admin)

  • POST /api/companies: Neues Unternehmen.
  • GET /api/companies: Liste aller Unternehmen.
  • PUT /api/companies/{id}: Unternehmen bearbeiten.
  • DELETE /api/companies/{id}: Unternehmen löschen.

5.2.3 Buchungsverwaltung

  • POST /api/bookings: Neue Buchung.
  • GET /api/bookings: Buchungen auflisten.
  • PUT /api/bookings/{id}: Buchung bearbeiten.
  • DELETE /api/bookings/{id}: Buchung löschen.

5.2.4 Berichte

  • GET /api/reports: Bericht generieren.
  • GET /api/reports/export: PDF-Export.

6. Sicherheitsaspekte

  • Authentifizierung: JWT-Token.
  • RBAC: Rollenbasierte Zugriffskontrolle.
  • Datenisolierung: Tenant-spezifischer Zugriff via Company-ID.
  • Verschlüsselung: Sensible Daten verschlüsselt.

Diese Spezifikation bietet eine klare Anleitung für die Entwicklung eines Multi-Tenant-Zeiterfassungstools mit modularer Struktur, das leicht mit LLMs implementiert werden kann. Die Version 2-Anforderungen sind als zukünftige Erweiterungen berücksichtigt.