doc/review/hwmodspec.txt

   1 1. Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden
   2    falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie!
   3
   4 Wofuer sind die verschiedenen Clocks im Design da? Ein Multiclockdesign ist nicht wuenschenswert,
   5 ausserdem zu komplex? Wir glauben man sollte das durch Kontrollsignale ersetzen, also z.B. ein
   6 Requestsignal geht hoch wenn alle Daten ins Register geladen wurden und bis zur Fertigstellung der
   7 Arbeit bleibt das ACK-Signal niedrig. Es koennte sein, dass es so gemeint ist, dann ist aber die
   8 Bezeichnung '*_clk' sehr irrefuehrend gewaehlt.
   9
  10 Note: 2
  11
  12
  13 2. Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des
  14    Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
  15
  16 Requirements jein: da auf die genaue art wie das alles funktioniert
  17 schlicht und ergreifend nicht eingegangen wird.
  18
  19 > bernhard: also ich finde die schon recht detailiert. afaik sagen die Requirements nichts darueber
  20 > aus wie die komponenten zusammenhaengen, sondern nur wie sich das system gegenueber dem user
  21 > verhalten soll. (ich kann mich aber auch irren -- ich hasse dieses geschwafel ueber
  22 > spezifikationen ;))
  23
  24 > alex: ich denke das hier nicht nur die vollstaendigkeit der requirements gemeint ist sondern auch
  25 > die vollstaendigkeit der module bzw. interfaces. also ist zu jedem interface mindestens ein modul
  26 > definiert und umgekehrt. Natuerlich gehort auch dazu ob die Module einen vollstaendigen
  27 > Taschenrechner erzeugen.
  28
  29 Module: Ueberblicksmaessig wirkt es recht gut (abgesehen von den '*_clk'-Signalen, aber in der
  30 "Detailed Design Description" fehlen eben die Details. Ablaeufe werden zwar textuell kurz erklaert,
  31 aber sie werden nur sehr oberflaechig und abstrakt "angekratzt". Ausserdem fehlen grafische
  32 Darstellungen (z.B. State-Maschinen). Weiters waere eine Beschreibung wuenschenswert wie ihr die
  33 eigentliche Berechnung umsetzen wollt (z.B. mit Hilfe von Pseudocode).
  34
  35 Testfaelle: Sind sehr gut!
  36
  37
  38 Note: 2
  39
  40
  41 3. Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine
  42    ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie!
  43
  44 Ja, grundsaetzlich schon, bis auf die Schnittstellenbeschreibung.
  45 Verbesserungsvorschlaege:
  46 * eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale fuehren.
  47 * einheitlichere Beschriftung der Signale (z.B. in "Calculator State Maschine", wo fuehren die
  48   Signale "result_data" bzw. "result_clk" hin? Das ist am ersten Blick nicht klar ersichtlich)
  49
  50 Note: 2
  51
  52
  53 4. Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes
  54    Feedback über die Qualität ihres Spezifikations-Dokumentes!
  55
  56 Wenn die nicht naeher beschriebenen Module funktionieren, schaut das Gesamtdesign recht
  57 zuversichtlich aus. (Sofern das mit den mehreren Clocksignalen beseitigt wird).
  58
  59 Die "Detailed Design Description" muss unbedingt noch ueberarbeitet werden.
  60
  61 Note: 2
  62