Website Spezifikation

[HansAn]

Ich schreibe gerade eine Spezifikation für eine Website, die noch nicht umgesetzt wurde. Was für Punkte würdet ihr darin aufnehmen?
Ich habe bereits ein paar Seiten über (Einleitung, Bedürfnisse, Probleme, Struktur (Bild), Design) geschrieben.
Was kann ich noch aufnehmen? Ich wollte z.B. die Umsetzung beschreiben, aber dann müsste ich die Seite ja paralell umsetzen, während ich die Spezifikation schreibe, sinnvoll?

Ausserdem wollte ich eine kleine Vorschau der Seite zeigen und erläutern wo was ist und wozu es da ist. Gibt es da Vorlagen für eine Standardseite nur um den Aufbau zu zeigen oder muss ich die Seite im Photoshop aufbauen?

 

[F_GXdx]

Für eine Vorschau nutze Mockup Tools, zb von Balsamiq.

Eine technische Beschreibung ist schon sinnvoll, auch ohne nebenher schon zu implementieren.

 

[Krik]

Von Vorteil wären auch ein paar Use Cases, also eine simple, minimale Darstellung, wie User bestimmte Aktionen auslösen. Das ist aber nur dann relevant, wenn man auf der Seite mehr machen kann, als nur den Inhalt zu betrachten.

Eine Rohfassung der Sitemap ist auch interessant, damit man immerhin schon mal den Umfang abschätzen kann.

 

[HansAn]

Die Seite wird später von Produktmanager aktualisiert und dient der Information. Eigentlich werden Produkte abgebildet, mit Anleitungen etc.
Nebenbei wird auch eine Chatfunktion eingebaut, eine Art Live Support Chat.
Dann noch ein Feedbackformular.
Und als letztes überlege ich mir ob ein Newsletter auch sinnvoll wäre. z.B. wenn ein neues Produkt veröffentlicht wurde, dass dann ein Mail rausgeht.

Ist dieser Fall genug für eine Use Case Darstellung oder ist das zu simpel?

Wie stellst du dir die technische Beschreibung vor? Ich werde es mit Joomla umsetzen, soll ich dann die Vorgänge von Joomla erklären? Von Programmiercode gibt es bei Joomla eigentlich nichts. Das ist ja alles fix fertig.

danke

 

[Krik]

Im Use Case wird beschrieben, was das System für den User zu leisten hat. Das wird so simpel wie möglich gehalten. Welches Framework oder CMS verwendet wird, ist da nicht von Belang.


zB Feedbackformular:
Akteur (User) -> Feedback in Formular eingeben -> Mail an den Support schicken

Dazu noch eine kleine Tabelle, welche Beschränkungen (zB User muss vorher angemeldet sein), Anforderungen (zB User bekommt eine Bestätigungsmail o. ä.) und Features (denk dir was aus) "Feedback in Formular eingeben" und "Mail an den Support schicken" haben müssen.
Keine technischen Details! Diese werden erst später aus der Analyse der Use Cases erst entwickelt.


Ich sehe bei deiner Aufzählung eine ganze Menge an Use Cases:
zB Produkte anzeigen:
Akteur (User) -> Filtereinstellungen setzen -> Produktliste filtern

Use Cases sind wirklich so simpel. Exakte Details sind hier nicht gefordert, es geht nur darum zu zeigen, was der User machen kann.
Später kannst du immer noch sagen, dass dieses Use Case mit Plugin XY in Joomla umsetzbar ist.

 

[HansAn]

e-Laurin
das ist echt interessant, danke für die deutliche Erklärung. Aber was meinst du, sollte ich für den Use Case so eine Zeichnung erstellen mit zB Visio oder reichen Worte "User gibt Feedback ein> Support bekommt E-Mail etc."

Würdest du alle Use Cases in einer Zeichunng erfassen, also ein Strichmännlein und dann verschiedenene Tasks oder für jeden Case eine Zeichnung?

danke

 

[Krik]

Ich kenne es so, dass man diese Grafiken erstellt und eben zu jedem dargestellten Use Case eine kleine Tabelle mit Eigenschaften des Use Cases (wie beschrieben) schreibt.

Wie du die Zeichnungen machst, ist eher dir überlassen. Bei Use Cases, die mehrere Akteure mit unterschiedlichen Benutzerrechten (zB User und Admin) haben, lohnt es sich schon, die in eine Grafik zu hauen. Da kann man dann auch gleich schnell erkennen, was ein User mit erweiterten Rechten denn zusätzlich noch tun kann.

Generelle Richtlinie ist aber: Ein Use Case pro Anwendungsfall.


Falls dich das Thema sehr interessiert und du öfters Spezifikationen schreiben musst, solltest du dir mal UML und auch das Thema Software Engineering anschauen. Es gibt ziemlich dicke Wälzer dazu und ist zwingend wichtig, um größere Projekte im Voraus planen, organisieren und später dann auch durchführen zu können.


Edit:
Es ist vielleicht vorher etwas unklar rübergekommen: Über alles auf der Webseite, mit dem ein User interagieren kann (außer Hyperlink), sollte es ein Use Case geben. Wenn jemand hinterher sagt: "Und was macht der User, wenn er XY machen soll?", dann weißt du, dass du ein Use Case übersehen hast.

 

[HansAn]

Zu allem ein Use Case
Dann hätte ich allein 10 Seiten Use Cases

Die technische Beschreibung ist jedoch nicht klar. Ist verstehe wenig bis gar nichts in Sachen WebProgrammierung. Ich kann hier also nicht Stellen von Programmiercodes präsentieren. Was soll ich in der Beschreibung schreiben, wenn ich es mit Joomla umsetze? Meinst du so eine Art Schritt-für-Schritt Anleitung wie ich vorgehe? Das ist vielleicht langweillig und hat nichts mit dem Thema zu tun. Andererseits würde ich es gleichzeitig umsetzen, weil auswendig weiss ich es dann auch nicht

Wäre cool, wenn ich hierzu noch etwas Imput bekäme. Dann habe ich wohl das was ich brauche
Danke

 

[Krik]

Ach so viel wird das nicht. So viele Buttons kannst du doch gar nicht haben. ^^


Bei der technischen Beschreibung schreibst du exakt das, was du gemacht hast. Also in welcher Reihenfolge du irgendwas mit welchen Einstellungen installierst hast, was du danach an der Konfiguration geändert hast, was du wo eingetragen hast usw.

Hier geht es darum, dass alles dokumentiert ist. Wenn man das einem anderen Menschen in die Hand drückt, soll er in der Lage sein, genau nachzuvollziehen, was du gemacht hast. Theoretisch kann man diese Beschreibung sogar als Anleitung nehmen und damit ein exakt identisches System aufsetzen.

Vorne weg schreibst du aber noch, was das System so kann, auf welchen Rechner es so läuft usw. (Stichwort Systemvoraussetzung)


Natürlich ist das langweiliger Text. Aber du schreibst ja auch eine Dokumentation und keinen Roman.

 

[F_GXdx]

Ich persönlich bin der Meinung, dass Use Cases und vor allem Use Case Diagramme - obwohl sie so gelehrt werden - vom Nutzen her eher gering sind.

Mein Eindruck ist, dass moderne Formen der Visualisierung wie zB Storyboards und Rich Pictures beim Kunden besser ankommen.

Was man mit dem System alles machen kann gehört eher in den Vertrag/Pflichtenheft, bzw. die Bestellung/Lastenheft. Dort kann man die Use Cases auch gleich textuell beschreiben mit einem Template, dass man immer ausfüllt. Ist aber staubtrocken, langweilig und wenig übersichtlich - daher auch wenig nützlich.

Daher: Für die "Systemidee", bzw. "Systemvision" wirklich nur zentrale Ausprägungen wichtiger Use Cases, sogenannte Szenarios, modellieren. Für den genauen Funktionsumfang Use Cases, wobei das wirklich umfangreich werden kann - und auch lästig.

 

[HansAn]

Ja, solche Storys werden bei uns auch eingesetzt. Ich finde sowas immer spannender, als eine lange und ermüdende Beschreibung des PRojektes. Eine Story zeigt anhand eines Beispiels was behandelt werden soll. Aber was ist die Story jetzt für ein Punkt in der Spezifikation?

Story selber oder soll man es Beschreibung nennen? Ich habe schon eine kleine Einleitung dazu geschrieben, demnach könnte ich die löschen. Wie würdest du es machen?

Meine Website Spezifikation sieht jetzt in etwa so aus:
- Einleitung (was ist es)
- Bedürfnisse (der kunden)
- - Allgemein
- - Im Detail
- Probleme (wieso es das projekt braucht)
- Struktur (Flussdiagramm)
- Aufbau (Vorschau Bild)
- Design (nur ein paar Sätze Beschreibung)
- User Berechtigungen und Tasks (wer macht was)
- - User xy
- - User xx
- - etc.
- Umsetzung der Tasks (wie macht wer was)
- Umsetzung des Projektes (wie setze ich das Projekt um) -> Hier so eine Art Anleitung von der Bestellung der Domain bis hin zum schreiben eines Beitrages?

Würdet ihr es anders machen?

 

[HansAn]

keine Antwort?

 

[Krik]

War im Urlaub

Deine Auflistung klingt sehr gut. Ich weiß nicht, ob dein Projekt gewerblich oder nur ein schulisch ist. Ist es gewerblich, solltest du den Auftraggeber vielleicht noch fragen, was er neben den von dir genannten Punkten auch sehen will. Ist es schulisch, dann frag den Lehrer, wonach er bepunktet.