20 Points to death

  • [table] [tr] [td][url='http://www.st.inf.tu-dresden.de/SalesPoint/v3.1/index.html']Salespoint[/url][/td] [td][url='http://www.st.inf.tu-dresden.de/SalesPoint/v3.1/tutorial/index.html']Tutorien[/url][/td] [td][url='http://www.st.inf.tu-dresden.de/SalesPoint/v3.1/documentation/index.html']Dokumentation[/url][/td] [td][url='http://www.st.inf.tu-dresden.de/SalesPoint/v3.1/download.html']Download[/url][/td] [td][url='http://www.st.inf.tu-dresden.de/SalesPoint/v3.1/faq/index.html']FAQ[/url][/td] [/tr] [/table] [size=24]Pflichtenheft (Aufbau nach Balzert)[/size] [size=18]Zielbestimmung[/size] Im Rahmen der Zielbestimmung werden die Ziele des Produktes in einer Art Prioritätenliste exakt eingegrenzt, die in drei weitere Kategorien gegliedert ist, die als Muß-, Wunsch- und Abgrenzungskriterien bezeichnet werden. Zu den Mußkriterien zählen die Produktfunktionen, die für ein Funktionieren des Produktes unabdingbar sind. Ohne ihre Umsetzung geht einfach nichts, deshalb müssen sie erfüllt werden. Die nächste Kategorie, die Wunschkriterien, sind zwar entbehrlich, wurden aber ausdrücklich vom Auftraggeber gefordert. Ihre Umsetzung im Produkt ist also genauso eine Pflicht, wie die der ersten Kategorie, das Produkt würde aber auch ohne ihre Implementierung seinen Betrieb korrekt ausführen. Die letzte Kategorie von Kapitel 1 beschreiben die Abgrenzungskriterien. Sie sollen die Grenzen des Produktes klarmachen und sind von daher beinahe wichtiger als die beiden ersten Fälle denn sie hindern die Entwickler daran, über alle Ziele hinauszuschießen. Schreibt hier also genau die Punkte auf, die zwar in der Analyse irgendwo mal auftauchten, deren Umsetzung aber abgelehnt oder aufgeschoben wurde. [size=18]Produkteinsatz[/size] Als nächstes stellt sich das Problem des Produkteinsatzes. Wir haben schon in den vergangenen Abschnitten der Analyse darauf hingewiesen, daß dem Umfeld der Anwendung große Beachtung geschenkt werden muss. Ein kleines Beispiel soll das erläutern. Software-Entwickler können auf ihrem Gebiet ebensolche Fachidioten (Entschuldigung für die grobe Ausdrucksweise, aber in dem Zusammenhang finde ich sie einfach angebracht um den Ernst der Situation klarer zu machen) sein, wie beispielsweise KFZ-Mechaniker wenn es um Motorpflege beim Auto geht. Sie heben sehr schnell in nicht mehr erreichbare Höhen ab, in denen sie von normalen EDV-Nutzern nicht mehr verstanden werden. So etwas kann sich sehr schnell auf ihre Programme auswirken, beispielsweise beim GUI-Design, wo dann viel zu viel Wert auf Funktionalität gelegt wird und die Benutzbarkeit für andere Nutzer auf der Strecke bleibt. Genau deshalb werden in diesem Kapitel die späteren Anwendungsbereiche, Zielgruppen und Betriebsbedingungen (physikalische Umgebung, tägliche Betriebszeit und ständige Beobachtung oder unbeaufsichtigter Betrieb) der Anwendung sehr genau definiert. Bei den Zielgruppen sollte auch auf das Qualifikationsniveau des Benutzers eingegangen werden. [size=18]Produktübersicht[/size] Eine Übersicht über alle, die Anwendung betreffende, Geschäftsprozesse (Anwendungsfälle) in Form eines Anwendungsfall-Diagramms. Man ordnet alle mit dem Produkt umgesetzten Geschäftsprozesse untereinander an und ordnet ihnen die daran beteiligten Akteure zu. Eine Erklärung der einzelnen Anwendungsfälle folgt schließlich in Kapitel 4 mit den Produktfunktionen. [size=18]Produktfunktionen[/size] Angelehnt an die Analyse der Aufgabenstellung wird nun für jede unterstützte Produktfunktion beschrieben, wie sie im Anwendungsfall abläuft, unter welchen Bedingungen sie aufgerufen wird, welche Akteure daran beteiligt sind und welche Auswirkungen sie auf andere Geschäftsprozesse hat. Die einzelnen Funktionen werden dabei nach folgendem Schema durchnummeriert: Die Darstellung der Ordnungsnummer erfolgt nach dem Schema "/Fxx/", wobei das "F" kennzeichnet, daß es sich hierbei um eine Produktfunktion handelt und "xx" die Nummer ist. Für sie gelten besondere Regeln, deren Einhaltung empfohlen wird. Nummeriert wird zunächst in 10er-Schritten in derselben Reihenfolge, wie die Produktfunktionen im Übersichtsdiagramm in Kapitel 3 bzw. der Prioritätenliste aus Kapitel 1 auftauchen. Bei der Nummerierung werden die Wunschkriterien durch ein "W", das auf das "F" folgt, gekennzeichnet. Die großen Abstände zwischen den Punkten dienen dazu, genug Platz zu lassen um im weiteren Verlauf der Entwicklung entstehende Anforderungen einfach einfügen zu können. Die Nummerierung selbst dient Referenzzwecken, damit man sich im weiteren Entwicklungsverlauf immer wieder auf die Punkte aus dem Pflichtenheft berufen kann, ohne jedesmal eine ellenlange Beschreibung machen zu müssen. [size=18]Produktdaten[/size] Ich möchte den Leser an dieser Stelle darauf hinweisen, daß eine strikte Trennung zwischen Anforderung (Kap.4), Daten (Kap.5) und Funktionen der Benutzeroberfläche (Kap.8) vorgenommen wird. Bringt die Punkte dieser drei Kapitel nicht durcheinander. Kommen wir nun zu den Daten, worunter wir hier nur die langfristig (persistent) zu speichernden Informationen meinen. Zur Beschreibung gibt es zwei Wege. Als erstes natürlich wieder den verbalen Weg. Bezeichnet die Daten mit beschreibenden Namen (die Betonung liegt hier auf "beschreibend"! wir wollen an der Stelle keine kryptischen Variablenbezeichner wie m_strCWD sehen!) und erklärt in Worten die möglichen Inhalte des Datums und den dafür einzuplanenden Speicherplatzverbrauch. Die zweite Möglichkeit zur Beschreibung trifft besonders auf objektorientierte Entwicklungen zu. Hier reicht nämlich ein Klassendiagramm der Datenstrukturen mit einigen erläuternden Notizen zu jeder Klasse, was wieder den Speicherverbrauch etc. betrifft. Die Punkte dieses Kapitels sind wieder nach demselben Schema wie im letzten Abschnitt durchzunummerieren, nur das die Maske jetzt "/Dxx/" (natürlich steht das "D" für Daten) heißt. [size=18]Produktleistungen[/size] Gibt es bezüglich einiger Produktfunktionen bestimmte Leistungsanforderungen (Zeit zur Ausführung, Genauigkeit der Berechnungen oder Datentransfervolumen und -dauer bei netzwerkfähigen Anwendungen), werden sie hier aufgelistet. Wie schon bei den letzten beiden Kategorien, werden sie zu Referenzzwecken durchnummeriert (Schema: "/Lxx/"). Ein paar Anmerkungen, ob die geforderten Leistungen mit denen in Kapitel 5 genannten Datenmengen auch erreicht werden können dürfen an dieser Stelle ebenfalls nicht fehlen. [size=18]Qualitätsanforderungen[/size] In diesem Kapitel wird den Qualitätsmerkmalen Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit je eine Qualitätsstufe aus sehr gut, gut, normal und nicht relevant zugeordnet. [size=18]Benutzungsoberfläche[/size] An dieser Stelle wird oft über alle möglichen Einzelheiten jedes noch so unwichtigen Dialogfensters der Anwendung geplaudert, was an dieser Stelle der Entwicklung noch gar nicht angebracht ist. Selbst das Benutzerhandbuch sollte noch nicht so detailliert sein, daß es alle Einzelheiten der Benutzeroberfläche kennt. Hierher gehören lediglich grundlegende Anforderungen, wie zum Beispiel die Art des Fensterlayouts, die Dialogstruktur und ob Mausbedienung gefordert wird oder nicht. Ein weiterer Punkt, der hier erwähnt werden sollte, ist die Art der Zugriffsrechte der einzelnen Charaktere (Endbenutzer, Akteure). Auch jetzt wird eine Nummerierung, diesmal nach dem Muster "/Bxx/", vorgenommen. [size=18]Nichtfunktionale Anforderungen[/size] Hierher gehören alle Anforderungen an die zu erstellende Software, die nicht in die Kapitel 4, 5, 6 oder 7 einzuordnen sind. Balzert nennt auf Seite 117 die folgenden Beispiele: [list][*]einzuhaltende Gesetze und Normen, [*]Testat durch externe Prüfgesellschaft, [*]Revisionsfähigkeit, [*]Ordnungsmäßigkeit der Buchführung, [*]Sicherheitsanforderungen, wie Passwortschutz, Mitlaufen von Protokollen und sichere Übertragungen sowie [*]Plattformunabhängigkeiten. [/list]