Software Engineering Labor-Übung, LVNr: Übungsleiter: Dokument: Anforderungsanalyse und Use Case Modell I v.1.0 Projekttitel: better-than-new Projekthomepage: http://code.google.com/p/better-than-new Gruppenmitglieder: MatNr: Nachname: Vorname: e-mail: a1000639 El-Manakhli Stefan elmanakhli@hotmail.com a0926606 Kafai-Ghaini Ahmed ahmed.kafai@gmx.at a0929188 Klaassen Sebastian rcsepp@hotmail.com a1001030 Müller Nick nick.mueller@aon.at Datum: 20.11.2011 1
Anforderungsanalyse Funktionale Anforderungen Zu Projektstart traf sich unsere Entwicklergruppe zu einem Brainstorming, um die funktionalen Anforderungen für unsere Plattform zum Kaufen und Verkaufen von gebrauchter Computer- und Server-Hardware zu definieren. Dabei orientierten wir uns an bereits existierenden großen Handels- und Auktionsplattformen wie zum Beispiel ebay oder Amazon. Außerdem versuchten wir, uns in potentielle zukünftige Kunden hineinzuversetzen, um diesen möglichst komfortabel und schnell alle gewünschten Funktionen zur Verfügung zu stellen. Aus diesen Überlegungen ergab sich die grundlegende Funktionalität unseres Systems, welche im folgenden Absatz erläutert wird. 1. Beschreibung der Funktionalität Das System better-than-new soll verschiedene Funktionen je nach Benutzertyp anbieten, wobei zwischen folgenden Usergruppen unterschieden wird: 1.) Nicht registrierte Benutzer: User, die sich noch nicht auf der Plattform registriert haben, können alle Artikel und Produktgruppen ansehen und durchsuchen, aber nicht auf diese bieten oder selbst Angebote erstellen. Dafür muss zuerst ein Käufer- oder Verkäufer-Konto erstellt werden. 2.) Käufer: Käufer sind registrierte Benutzer, welche auf Artikel von Verkäufern bieten oder diese direkt per Sofort-Kauf erwerben können (der Sofort-Kauf wird hierbei als Abschlussgebot interpretiert und beendet die Auktion automatisch). Käufer können ihr eigenes Konto bearbeiten (Email-Adresse/Kennwort ändern, Konto löschen), außerdem können sie auf Statistiken von laufenden und bereits abgelaufenen Auktionen zugreifen und nach erfolgreichem Abschluss eines Kaufes eine Bewertung des Verkäufers und des angebotenen Artikels abgeben. 3.) Verkäufer: Verkäufer sind ebenfalls registrierte Benutzer, welche anderen Kunden Artikel zum Verkauf anbieten und dabei auch auf Produkte anderer Anbieter Gebote abgeben können. Beim Hinzufügen eines neuen Artikels kann außerdem die die Art des Verkaufes (Auktion, Sofortkauf, beides) gewählt werden. Zusätzlich hat ein Verkäufer die Möglichkeit, alle Käufer der von ihm/ihr angebotenen Artikel einzusehen, und diese nach Rechnungsabschluss auch zu bewerten. Genauso wie der Käufer hat auch ein Verkäufer Zugang zu den Statistiken einer Auktion. 4.) Administratoren: Aufgabe der Administratoren von better-than-new ist es, die Produktgruppen und Artikel zu verwalten (Artikel verschiedenen Produktgruppen zuordnen oder verschieben) und gegebenenfalls zu löschen. Außerdem können sie Käufer- und Verkäufer-Konten bearbeiten und im Bedarfsfall auch ganz löschen. 2
2. Bedienungsoberfläche Lädt der Nutzer den Webshop, landet er auf der oben gezeigten Hauptseite von better-than-new. Im linken Navigationsbalken sind die verschiedenen Kategorien aufgelistet, bei deren Klick die in der Mitte angezeigten Artikel nach jeweiligen Produktgruppen sortiert und angezeigt werden. Über der Artikelliste wird eine Suchleiste eingeblendet, mit Hilfe derer der User die vorhandenen Artikel nach gewünschten Stichwörtern durchsuchen kann. Des Weiteren werden der Benutzername des momentan eingeloggten Benutzers (und dazu ein Login/Logut-Button) und weitere Schaltflächen zum Aufrufen der Hilfe, Kontakt oder Impressums-Seite in der Menüleiste am Kopf der Seite angezeigt. Per Klick auf das Einkaufswagen-Symbol wird dem Benutzer sein Warenkorb mit den momentan vorhandenen Artikeln angezeigt (Auktionsartikel und Sofort-Kauf- Artikel). 3
Auf der Login-Seite kann ein User sich einloggen, falls er bereits ein Konto im Webshop besitzt. Danach wird er zu seiner User-Seite weitergeleitet. Hat der Nutzer noch keinen Account, kann er sich auf derselben Seite neu registrieren, wobei einige Daten (Name, Emailadresse, etc ) angegeben müssen, und eine Wahl zwischen Verkäufer- und Käuferkonto getroffen werden muss. 4
Im Account-Fenster bekommt der Käufer einen Überblick über bereits abgeschlossene Käufe, Artikel, auf die er geboten hat und deren Auktion noch läuft, und Produkte, die er zu einer Watchlist hinzugefügt hat. 5
Der Verkäufer erhält in seiner Kontoübersicht zusätzlich eine Übersicht über die von ihm angebotenen Artikel, die bereits verkauften Gegenstände und Statistiken zu seinen Verkäufen. 6
Will ein Verkäufer einen neuen Artikel anbieten oder einen bereits bestehenden bearbeiten, kann er dies per Formular tun. Dabei muss ein Bild hochgeladen, welches das angebotene Produkt zeigt, eine Beschreibung sowie eine Produktgruppe ausgewählt werden, und schließlich noch eine Auktionsart gewählt werden. Außerdem besteht die Möglichkeit, einen (bereits vorhandenen) Artikel aus dem System zu entfernen. 7
Nach getätigtem Kauf können Artikel und Verkäufer/Käufer bewertet werden. Neben einem kurzen schriftlichen Kommentar wird eine Wertung von 1-5 Sternen abgegeben, wobei 5 Sterne die bestmögliche Bewertung ist. 8
Nichtfunktionale Anforderungen Ähnlich wie die Funktionen sind auch die Nichtfunktionen unseres Projekts in mehrere Gruppen aufgegliedert: 1.) Allgemeine Nichtfunktionen: Das Shop-System soll nicht die Bezahlung durch elektronische Zahlungsmittel wie PayPal oder direkte Abbuchung von einer Kreditkarte verwenden. Außerdem sind keine Email-Aussendungen für Informationen und News an Kunden geplant. 2.) Nicht registrierte Benutzer: Unregistrierte User könne keine Daten verändern oder ansehen, die sonst nur Käufern beziehungsweise Verkäufern zugänglich sind. 3.) Käufer: Benutzer mit einem Käufer-Konto können keine Verkäufer-Statistiken einsehen, außerdem haben sie keinen Zugriff auf andere Benutzer (Ausnahme: Daten der Verkäufer, von denen bereits Artikel gekauft wurden). 4.) Verkäufer: Verkäufern ist es nicht möglich, Gebote auf eigene Artikel abzugeben, um den Preis zu steigern. Des Weiteren können sie weder Artikel noch ihr Profil löschen, wenn noch eine Aktion läuft. Ähnlich wie Käufer haben Verkäufer nur auf die Daten derjenigen User Zugriff, die bereits einen angebotenen Artikel gekauft haben. 5.) Administratoren: Administratoren können keine vorhandenen Produktgruppen löschen, besitzen außerdem kein Käufer-/Verkäuferkonto und können deswegen an keinen Auktionen teilnehmen oder Käufe tätigen. 1. Qualitätsanforderungen Funktionalität: Die Realisierte Plattform soll alle von uns in diesem Dokument erläuterten Funktionen besitzen. Es wird sicherlich kleinere Abweichungen beim Endprodukt geben, dies soll aber nicht die zugrunde liegenden Funktionen der Plattform betreffen. Zuverlässigkeit: Die Plattform muss immer eine Verfügbarkeit, was heißen soll einen Zugriff für Benutzer bereitstellen. Falls aus Gründen der Sicherheit oder bei eventuellen nachträglichen Anpassungen die Seite nicht erreichbar sein sollte, muss dies dem Kunden mitgeteilt werden und eine ausdrückliche Erklärung bereitgestellt sein. Es müssen daher vorab alle beeinträchtigenden Fehler ausgemerzt werden. Benutzbarkeit: Es soll dem Kunden eine übersichtlich organisierte Seite zur Verfügung stehen, welche einfach aufgebaut und leicht zu bedienen ist (siehe Bedienungsoberfläche). Effizienz: Bei der Programmierung soll hier ein Augenmerk auf die Bedienbarkeit des Webinterfaces und das Handling von Daten auf dem MySQL-Server gelegt werden. Auch in Richtung Geschwindigkeit der Datenabfrage und -speicherung. Übertragbarkeit: Die Multibrowserfähigkeit ist zu berücksichtigen zumindest (Firefox, IE, Opera und Chrome) 9
2. Technische Anforderungen Das Projekt wird auf einem Windows Dedicated Rootserver mit Windows Server 2008 R2 Enterprise gehosted werden. Auf diesem Server werden außerdem die benötigte MySQL- Datenbank und der Apache Tomcat 7.0.22 Server betrieben, mit Hilfe derer der Webshop aufgebaut wird. Auf Serverseite wird das Java SE Development Kit in der Version 7u1 verwendet. Die Benutzer des Webshops müssen das Java SE Runtime Environment 6 oder höher installiert haben, um das System benutzen zu können. 3. Realisierungsanforderungen Installierung: Keine Clientseitige Installation von nöten. Serverseitig die Installation des Tomcat Servers und MySQL Datenbank. Dokumentation: Die Technische Dokumentation ist der Zusammenschluss der SVN Comments, der angelegten JavaDocs und der von uns gestalteten Wiki-Pages. Dem Endbenutzer werden hier die Wiki-Pages und Tutorials zur Verfügung stehen. 4. Diverses Annahme: Ein User Besitzt einen Namen, eine Adresse und alle Parameter die zu einer Anmeldung erforderlich sind. Risikos Projekt: Probleme bei der Implementierung, Webinterface funktioniert nicht korrekt, Ausfall von Teammitgliedern Risikos Plattform: Kunden können nicht angeworben werden, Verkäufer benutzen andere Plattformen um ihre Produkte zu verkaufen. 1
Use Case Modell Erstellen sie für das zu entwickelnde System ein Use-Case Modell bestehend einem Use-Case- Diagramm und den detaillierten Beschreibungen der Use-Cases. Use Case Diagramm Use Case Beschreibung 1. Use Case Artikel suchen Ziel: Artikel finden 1
Kategorie: primär Vorbedingung: null Nachbedingung bei Erfolg: Artikel ansehen Nachbedingung bei Fehlschlag: null Akteur: Benutzer Auslösendes Ereignis: Benutzer sucht über Interface Basisablauf: Kunde besucht Webseite Kunde gibt Suchbegriff ein Kunde klickt search_button 2. Use Case Artikeleinsicht Ziel: Artikel Details einsehen Kategorie: primär Vorbedingung: null Nachbedingung bei Erfolg: Artikeldetails werden angezeigt Nachbedingung bei Fehlschlag: Kunde kann die Details nicht sehen Akteur: Benutzer Auslösendes Ereignis: Benutzer klickt Artikel an Basisablauf: Kunde besucht Webseite Kunde sucht Artikel / Kunde öffnet Produktgruppe Kunde klickt Artikel zur Einsicht an 3. Use Case Statistik anzeigen Ziel: Übersicht über Informationen zu geben Vorbedingung: Registrierter Nutzer Nachbedingung bei Erfolg: zeigt Diagramm an Nachbedingung bei Fehlschlag: null Akteur: registrierter Nutzer Auslösendes Ereignis: Nutzer ist angemeldet Basisablauf: Kunde besucht Webseite Kunde meldet sich an Kunde sieht Statistik ein 4. Use Case Registrierung Ziel: Anlegung eines Benutzeraccounts Kategorie: primär Vorbedingung: null Nachbedingung bei Erfolg: Anlegung eines Benutzeraccounts plus Erstanmeldung Nachbedingung bei Fehlschlag: Registrierung wiederholen Akteur: unreg. Nutzer Auslösendes Ereignis: Nutzer besucht die Webseite und klickt auf Registrieren Basisablauf: Kunde besucht die Webseite Kunde klickt auf Registrieren 5. Use Case Anmeldung Ziel: Benutzer wird eingeloggt Vorbedingung: reg. Nutzer, nicht angemeldet Nachbedingung bei Erfolg: Anmeldung auf Webinterface Nachbedingung bei Fehlschlag: Anmeldung wiederholen 1
Akteur: reg. Benutzer Auslösendes Ereignis: Login angeklickt 6. Use Case Verwaltung Ziel: Die Verwaltung der Plattform und Userdaten Vorbedingung: Admin Nachbedingung bei Erfolg: Daten können vom Admin bearbeitet werden Akteur: Admin Auslösendes Ereignis: Verfügt über Adminzugang 7. Use Case Artikel erstellen Ziel: Artikel in Datenbank anlegen Vorbedingung: angemeldeter Verkäufer Nachbedingung bei Fehlschlag: Fehlermeldung wird ausgegeben Akteur: Verkäufer Basisablauf: Verkäufer > login Verkäufer > erstellt Artikel 8. Use Case Bewerten Ziel: Bewertung von Artikeln, Verkäufern und Käufern Vorbedingung: angemeldeter Nutzer, Kauf Abgeschlossen Nachbedingung bei Erfolg: Bewertung wird angelegt Akteur: Käufer, Verkäufer Basisablauf: gibt Kommentar + Bewertung ab 9. Use Case Bieten Ziel: Gebot abgeben, oder Sofortkauf Vorbedingung: angemeldeter Käufer Nachbedingung bei Erfolg: Gebotsabgabe auf Artikel oder Kauf mögllich Nachbedingung bei Fehlschlag: Fehlermeldung Akteur: Käufer 10. Use Case Kaufen Ziel: Abschließen des Kaufes oder Auktion Vorbedingung: ang. Käufer hat Gebot abgegeben oder Sofortkauf Nachbedingung bei Erfolg: Muss Rechnung zahlen per Erlagschein > Produkt geliefert Nachbedingung bei Fehlschlag: Fehlermeldung Akteur: Käufer Auslösendes Ereignis: Käufer schließt kauf ab Basisablauf: Käufer bietet auf Artikel / Käufer macht Sofortkauf Käufer schließt Kauf ab 1