AI_Entwurf.md

Einführung und Ziele

Aufgabenstellung

Qualitätsziele

Datenschutz und Datenintegrität:

• Persönliche Daten der Kunden sind geschützt. Kunden können nur auf ihre eigenen Informationen zugreifen. Mitarbeiter sehen nur die relevanten Informationen zur Verarbeitung des Workflows.

Bedienbarkeit:

• Kunden sollten sich einfach auf der Website orientieren können, System soll sehr handlich gestaltet sein.

Verlässlichkeit:

• Das System speichet die von Kunden eingegebenen Daten korrekt.

Skalierbarkeit:

• Das System kann sowohl mit 100 oder auch Millionen von Kunden umgehen.

Stakeholder

Rolle	Erwartungshaltung
Kunden	einfach und unkompliziert sein Gerät minimale benötigte Daten angeben für den Verkauf
Mitarbeiter im Betrieb	muss koordiniert und reibungslos ablaufen

Randbedingungen

Kontextabgrenzung

Lösungsstrategie

Bausteinsicht

Ebene 1

Ebene 2

ReviewService

Kriterium	Beschreibung
Zweck/Verantwortung	Preisschätzung: Durchführung einer Preisschätzung mit Angaben des Kunden Vollständige Bewertung: Durchführung der Bewertung mit den angegebenen Bewertungsmerkmalen (Preisberechnung)
Schnittstellen	DeviceCatalog: stellt die für die Bewertung benötigten Regeln bereit (getRules) ProductManager: kann die Erstellung von Bewertungen anfragen (createReview)
Qualitäts-/ Leistungsmerkmale	Genauigkeit: Preisschätzung soll möglichst akkurat sein (nah an eigentlicher Bewertung) Korrektheit: berechneter Preis entspricht den Bewertungskriterien
Offene Probleme/Risiken	Mitarbeiter können bei der Bewertung auf noch unbekannte technische Probleme stoßen (für diese gibt es noch keine Fragen im Fragenkatalog)

Schnittstellen

Schnittstelle	Vorbedingung	Nachbedingung
createReview(  DeviceType,  List<Properties> )	Gerätetyp wird unterstützt, Produkteigenschaften müssen vorhanden sein	eine korrekte Bewertung des angegebenen Geräts wurde zurückgegeben
getRules(DeviceType)	Gerätetyp wird unterstützt	Regeln werden zurückgegeben

DeviceCatalog

Kriterium	Beschreibung
Zweck/Verantwortung	Verwaltung der unterstützten Gerätetypen nimmt 5-10 neue Gerätetypen pro Monat auf sollte es zu einem bereits unterstützten Gerätetypen ein Jahr lang keine Einsendungen geben, wird dieser aus dem Angebot entfernt speichert Informationen zu den Gerätetypen: Bewertungskriterien Preis mögliche verwertbare Subkomponenten/Teile Anzahl eingesendeter Geräte Zeitpunkt der Einsendungen
Schnittstellen	ReviewService: greift auf die gespeicherten Regeln zu einem Gerätetypen zu (getRules) ProductManager: kann anfragen, ob ein Gerät unterstützt wird (isSupportedType) ProductManager: kann Unterstützung eines neuen Gerätetyps anfragen (addSupportedType) DeviceDatabase: stellt Daten zu den Gerätetypen bereit (z.B. getNumberOfDevices) ERP-System: wird über Änderungen bezüglich der Unterstützung von Gerätetypen und erhaltenen Geräten informiert (informERP)
Qualitäts-/ Leistungsmerkmale	Korrektheit: die gespeicherten Information müssen korrekt sein Aktualität: die gespeicherten Informationen dürfen nicht veraltet sein
Offene Probleme/Risiken	mögliche Duplizierung von Daten, die schon im ERP-System gespeichert werden

Schnittstellen

Schnittstelle	Vorbedingung	Nachbedingung
getRules(DeviceType)	Gerätetyp wird unterstützt	Regeln werden zurückgegeben
isSupportedType(DeviceType)	Gerät wurde eingesendet	Rückgabe, ob der angegebene Gerätetyp unterstützt wird
addSupportedType(DeviceType)	Gerätetyp wird (noch) nicht unterstützt	Gerätetyp wird unterstützt
getNumberOfDevices(DeviceType)	Gerätetyp wird unterstützt und ist in GeräteDatenbank gespeichert	Anzahl der Geräte wird an GeräteKatalog zurückgegeben
informERP(List<Device>)	Daten sind mit ERP-System kompatibel	ERP-System ist über die neuen Informationen informiert

Laufzeitsicht

Laufzeitsicht - Erstellung Angebot

Laufzeitsicht - Annahme Angebot

Verteilungssicht

Infrastruktur Ebene 1

Use Cases

Use Case: Geräterücknahme - Anmeldung

Nummer	UC-1
Titel	Anmeldung
Akteure und Komponenten	Kunde, CustomerManager
Ziel	Ein Kunde möchte sich anmelden.
Auslöser	Kunde öffnet Anmeldefenster im Browser
Vorbedingungen	Kunde ist bereits registriert Kunde kennt Email-Adresse für sein Konto
Nachbedingungen	Kunde ist angemeldet und kann seine Einsendungen und Angebote verwalten
Erfolgsszenario	1. Kunde gibt seine Anmeldedaten im Frontend ein 2. CustomerManager prüft Daten und genehmigt Kunden den Zugang 3. Kunde sieht Benutzeroberfläche nach dem Login
Erweiterungsfälle	1.1 Kunde hat Passwort vergessen und klickt auf "Passwort vergessen?" 1.2 Kunde gibt seine E-Mail-Adresse an und erhält eine Mail, wo das Passwort zurückgesetzt werden kann.
Fehlerfälle	2.1 Übrprüfung der Anmeldedaten ist nicht erfolgreich 2.2 Kunde wird über fehlgeschlagene Anmeldung informiert
Häufigkeit	Einmal die Woche pro Kunde
Zugrundeliegende Anforderungen	-

Use Case: Geräterücknahme - Einsendung

Nummer	UC-2
Titel	Einsendung
Akteure und Komponenten	Kunde, ProductManager
Ziel	Ein eingesendetes Gerät wird im System aufgenommen.
Auslöser	Kunde hat Gerät eingesendet.
Vorbedingungen	Einzusendender Gerätetyp wird unterstützt. Kunde ist im Nutzerkonto angemeldet. Kunde hat eine Andresse hinterlegt.
Nachbedingungen	Einsendung wurde im System aufgenommen. Kunde wurde im Frontend über das Eintreffen der Einsendung informiert.
Erfolgsszenario	1. Kunde kündigt Einsendung im Frontend an und gibt dabei den Gerätetypen der Einsendung an. 2. Gerät wird erhalten. 3. ProductManager überprüft, ob das erhaltene Gerät wirklich zu dem angegebenen Gerätetypen gehört. 4. Nach erfolgreicher Überprüfung nimmt ProductManager das Gerät im System auf. 5. ProductManager informiert das Frontend über den erfolgreichen Erhalt des Geräts.
Erweiterungsfälle	1.1 Kunde kann auswählen, dass das Gerät gespendet wird. 1.2. Es muss anschließend kein Angebot erstellt und somit auch keine Bewertung durchgeführt werden.
Fehlerfälle	4.1. Das Gerät entspricht nicht dem angegebenen Gerätetypen OPTION A: 4.2.1. Der eigentliche Gerätetyp wird auch unterstützt und das Gerät kann trotzdem bewertet werden. 4.2.2. Der Auftrag wird mit dem eigentlichen Gerätetypen aktualisiert. OPTION B: 4.3.1. Der eigentliche Gerätetyp wird nicht unterstützt und das Gerät wird an den Kunden zurückgeschickt. 4.3.2. Der Kunde wird im Frontend darüber informiert.
Häufigkeit	Einmal im Monat pro Kunde
Zugrundeliegende Anforderungen	UC-1

Use Case: Geräterücknahme - Bewertung

Nummer	UC-3
Titel	Bewertung
Akteure und Komponenten	Mitarbeiter, ProductManager, CustomerManager, ReviewService, DeviceCatalog
Ziel	Ein eingesendetes Gerät wird bewertet.
Auslöser	Ein eingesendetes Gerät wurde im System aufgenommen.
Vorbedingungen	Ein zu bewertendes Gerät ist vorhanden. Gerät wird unterstützt (Regeln zur Bewertung sind vorhanden) Der Mitarbeiter befindet sich beim Gerätebewertungsbereich.
Nachbedingungen	Bewertung wurde erstellt und ist im DeviceCatalog gespeichert. Angebot wurde erstellt und gespeichert.
Erfolgsszenario	1. ProductManager fragt die Bewertung beim ReviewService an. 2. ReviewService holt sich die Bewertungsegeln aus DeviceCatalog. 3. ReviewService generiert aus den Regeln einen Fragenkatalog für den Mitarbeiter. 4. Der Mitarbeiter inspiziert das Gerät und füllt den Fragenkatalog aus. 5. ReviewService führt mithilfe der Angaben des Mitarbeiters die Bewertung durch und berechnet einen Preis. 6. ReviewService sendet Bewertung an DeviceCatalog und ProductManager. 7. ProductManager legt Angebot an und sendet dieses an CustomerManager. 8. CustomerManager speichert das Angebot beim Kunden ab.
Erweiterungsfälle	-
Fehlerfälle	-
Häufigkeit	Einmal im Monat pro Kunde
Zugrundeliegende Anforderungen	UC-1, UC-2

Use Case: Geräterücknahme - Auszahlung

Nummer	UC-4
Titel	Auszahlung
Akteure und Komponenten	Kunde, ProductManager, CustomerManager, DeviceCatalog, Payment
Ziel	Einem Kunden wird der Preis des bewertetenmeingesendeten Gerät ausgezahlt.
Auslöser	Kunde nimmt ein bereits erstelltes Angebot an.
Vorbedingungen	Es existiert ein Angebot. Kunde hat Zahlungsinformationen im Nutzerkonto hinterlegt.
Nachbedingungen	Kunde hat Auszahlung bekommen. Kunde wurde im Frontend über Auszahlung informiert. Bestand wurde aktualisiert.
Erfolgsszenario	1. Kunde nimmt das Angebot über das Frontend an. 2. ProductManager überprüft beim CustomerManager, ob das Angebot wirklich existiert und zum anfragenden Kunden gehört. 3. ProductManager fragt Auszahlung bei Payment an. 4. Payment fragt die Zahlungsinformationen des Kunden beim CustomerManager an. 5. Payment fragt mithilfe der erhaltenen Zahlungsinformationen die eigentliche Auszahlung beim Finanzsystem an. 6. Die Auszahlung wird durchgeführt und eine Bestätigung an Payment geschickt. 7. Payment schickt eine Bestätigung an den ProductManager. 8. ProductManager löst eine Aktualisierung des Bestands bei DeviceCatalog aus. 9. Das Angebot wird aus dem CustomerManager gelöscht. 10. ProductManager bestätigt die Auszahlung beim Frontend des Kunden.
Erweiterungsfälle	5.1. Payment fragt mithilfe der erhaltenen Zahlungsinformationen die eigentliche Auszahlung stattdessen bei PayPal an.
Fehlerfälle	2.1. Das Angebot ist ungültig und der Prozess wird abgebrochen. 2.2. Der Kunde wird informiert. 6.1. Auszahlung war nicht erfolgreich. 6.2. Erneute Durchführung von Schritt 5. 6.3 Bei dreimaligem Fehlschlagen von Schritt 6 wird die Auszahlung abgebrochen und der Kunde darüber informiert.
Häufigkeit	Einmal im Monat bei 2/3 der Kunden.
Zugrundeliegende Anforderungen	UC-1, UC-2, UC-3

Architekturentscheidungen

Qualitätsanforderungen

Risiken und technische Schulden

Glossar