--- /dev/null
+Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden
+ falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+
+Aufgrund der schlechten Verständlichkeit, ist ein genaues Überprüfen auf Korrektheit nur bedingt
+möglich. Aufgefallen sind dennoch folgende Punkte:
+
+- Seite 2: Die History soll via RS232 nur ausgegeben werden und nicht "importiert"
+- Seite 10: Copy & Paste Fehler bei Parser-History-Schnittstelle => Richtungskonflikt
+- Seite 15: TC1: 50^B00 ist keine gültige Eingabe lt. angegebener Grammatik siehe Req2
+- Seite 18: read stopbit: Es muss detektiert werden, dass ein Stoppbit gesendet wurde, d.h. das Ende
+ des Frames muss erkannt werden und durch diesen Zustand dargestellt werden.
+
+Bei allen State-Machines wird bei Datenleitungen auf Flanken getriggert. Dies ist zwar möglich, aber
+es werden ziemlich begrenzte Ressourcen (z.B. Clock-Netze) verschwendet.
+
+- Seite 24: Wenn eine Priorisierung erfolgen soll, sollte auch definiert werden, wie dies zu
+ erfolgen hat (Konfliktauflösung).
+
+Note: 3
+=================================================================
+Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des
+ Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+
+Es gibt keinen Testcase der auf Underflow überprüft. TC6 prüft richtigerweise auf Overflow.
+
+Der Vollständigkeit halber gehört der PLL und eine Power on Reset(POR) Schaltung beschrieben.
+
+Sonst wurden keine Auslassungen gefunden.
+
+Note: 1
+=================================================================
+Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine
+ ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+
+Generell ist die Strukturierung, die Formulierungen und der Satzbau schlecht.
+
+Das Dokument ist zwar klar gegliedert, jedoch unübersichtlich. Wenn man die Funktionalität eines
+Modules verstehen möchte, muss man über 3-4 Textstellen den Überblick behalten, bzw. ständig hin-
+und herblättern.
+
+Die meisten Sätze und auch ganze Absätze sind verschachtelt und dadurch schwer verständlich. Auch
+die Eindeutigkeit leidet darunter. Vorgänge werden umgangssprachlich formuliert und sind dadurch
+unscharf definiert.
+
+Die Statemachines sind gar nicht verständlich, da sie einerseits sehr viele Details beinhalten, aber
+andererseits fehlen die Zusammenhänge der Details mit dem Verhalten des Moduls.
+
+Requirements sollen im Aktiv beschrieben werden, d.h. es muss eindeutig erkennbar sein, auf wen das
+Requirement zutrifft.
+Bsp: Req 3 Dabei soll Punkt- vor Strichrechnung gelten. (wobei und für wen soll dies gelten?)
+Req 5 Die Eingabe darf aus 70 Zeichen bestehen.
+darf => soll; darf drückt kein Requirement aus.
+aus 70 Zeichen => aus bis zu 70 Zeichen; oder sind genau 70 Zeichen gemeint?
+
+Req6 ... 'Enter' schließt die Eingabe ab und berechnet das Ergebnis, ... (Die Enter-Taste berechnet
+das Ergebnis?)
+Req9 ist referenziert auf eine "zuvor angegebene Methode" => Welche soll dies sein? Warum überhaupt
+eine Methode als Requirement spezifiziert
+
+Note: 4
+=================================================================
+Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes
+ Feedback über die Qualität ihres Spezifikations-Dokumentes!
+
+
+Eine Spezifikation soll die Teile definieren, die nötig sind um ein Projekt zu modularisieren und
+die Teile weglassen, die nicht beschrieben werden müssen, um eine bestimmte Aufgabe zu lösen.
+
+In eurer Spezifikation sind viel zu viele Implementationsdetails vorhanden. Dadurch würdet ihr bei
+einem korrekten Workflow, entweder die Implementierung an die Spezifikation binden oder die
+Spezifikation muss, bei einer abweichenden Implementierung, erneut verändert werden.
+
+In der jetzigen Fassung ist es, unserer Meinung nach, nicht möglich die Spezifikation als Vorlage
+für eine Implementierung zu verwenden.
+Stellt euch die Frage, was jemandem mitgeteilt werden muss, damit er eine (Teil-)Aufgabe/Problem
+lösen kann.
+Es ist nicht relevant das Projekt mit euer Lösung zu präsentieren.
+
+Note: 3
+
--- /dev/null
+Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden
+ falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+1
+
+Zwei wiederspruechliche Aussagen sind mir aufgefallen, fallen aber wohl unter Fluechtigkeitsfehler:
+
+Einleitung: Hier wird geschrieben, dass die Moeglichkeit besteht, die History per
+RS232-Schnittstelle zu importieren. Im Rest des Dokuments wird jedoch nicht beschrieben wie.
+
+Req 10 widerspricht 3.2, "Fehlermeldungen", indem es festlegt dass nur korrekte Eingaben in die
+History aufgenommen werden.
+=================================================================
+Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des
+ Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+2
+
+Weitere Testcases, die andere Requirements als die der Zahlenbereiche abdecken, waeren noch gut.
+Beispielsweise die leere Eingabe, die Eingabe von "3^B^B" oder "-5 - - 2".
+=================================================================
+Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine
+ ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+2
+
+Absatz 3.1 haette ich ans Ende des Dokuments gegeben, sonst wird man von Tabellen "erschlagen",
+bevor man deren Verhalten kennt.
+=================================================================
+Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes
+ Feedback über die Qualität ihres Spezifikations-Dokumentes!
+
+1
+
+Das Dokument hat mir vor allem wegen der Statemachine Diagramme samt ausfuehrlichen Erklaerungen gut
+gefallen. Es ist aber auch ansonsten alles drin, was man sich erwartet.
projects / hwmod.git / commitdiff