Grundlagen der Programmierung: Objektorientiertes Design

Funktionale und nichtfunktionale Anforderungen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Die Programmierung unterscheidet zwischen funktionalen und nichtfunktionalen Anforderungen. Dabei stellen die funktionalen Anforderungen die Funktionen eines Programms dar, die nichtfunktionalen dienen der Ausfallsicherheit sowie der Dokumentation.

Transkript

Die erste Frage lautet: Was ist für die Anwendung erforderlich? Was muss sie tun? Und auf diese Frage gibt es zwei Antworten. Erstens, die funktionellen Anforderungen, das sind die Features, die Fähigkeiten Ihrer Applikation. Und die zweite Antwort auf die Frage lautet: Wie schaut es aus mit der Hilfe-Funktion? Brauchen wie eine Dokumentation? Gibt es Gesetze, die wir beachten müssen? Wenn Sie ein System aufbauen, dass Banktransaktionen durchführt oder Gesundheitsdaten speichert, dann kann das ganz schön wichtig werden. Auch so Fragen sind wichtig wie: Was passiert, wenn 150 User gleichzeitig auf die Anwendung zugreifen? Ist dann noch alles in Ordnung? Oder wenn es ein Problem mit Ihrer Webanwendung Sonntagmorgens um 5 Uhr gibt, schlafen Sie dann ruhig weiter und sagen, ist mir egal, ich mach das erst am Montagmorgen oder muss jemand in die Firma fahren? Die funktionalen Anforderungen beginnen meist mit dem Satz: Das System muss... Also zum Beispiel, das System muss die Herzfrequenz anzeigen, die Temperatur und den Blutdruck eines Patienten, der an den Monitor angeschlossen ist. Die Anwendung muss dem Anwender erlauben, nach dem Nachnamen eines Kunden zu suchen, nach der Telefonnummer oder nach der Auftragsnummer. Das Programm muss es ermöglichen, Empfangsbestätigungen via E-Mail-Versand zu generieren. Andererseits könnten wir auch nicht funktionelle Anwendungen haben. Hier ein paar Beispiele: Das System muss Suchanfragen innerhalb von 2 Sekunden beantworten. Das ist kein wirkliches Feature, sondern etwas, das gefordert wird. Der Help-Desk sollte von Montag bis Freitag von 08:00 bis 18:00 Uhr telefonisch erreichbar sein. Das sind alles nicht- funktionale Anforderungen. Je umfangreicher die Anwendung, und je größer ihre Organisation ist, desto formaler müssen Sie dies alles angehen. Ich möchte Ihnen noch eine Eselsbrücke für das ganze hier zeigen. Ein üblicher Ansatz dafür ist mit dem Akronym FURPS oder FURPS+ umschrieben. Das ist Englisch für: Functional, Usability, Reliability, Performance und Supportability. Gehen wir das einmal der Reihe nach durch. F steht für Funktionalität, also die Features der Anwendung. U das kommt von Usability, das ist die Benutzerfreundlichkeit und dazu gehören auch so Dinge, wie Hilfe, die Dokumentation, Tutorials und so was. R, das steht für Reliability, das ist die Zuverlässigkeit. Das umfasst die Notfallplanung, die akzeptablen Ausfallzeiten. Schließlich steht P für Performance, die Effizienz, die Verfügbarkeit, die Kapazität. Und das S steht für Supportability, also die Wartbarkeit. Dazu gehört auch zum Beispiel die Frage, lässt sich das Ding für das internationale Parkett fit machen? Kann es leicht internationalisiert, also zum Beispiel übersetzt werden? Eine Website zum Beispiel in mehreren Sprachen oder ein E-Shop für verschiedene, unterschiedliche Landesgesetze. Unsere nicht funktionalen Anforderungen haben oftmals die Endung -keit, also Wartbarkeit, Zuverlässigkeit, Brauchbarkeit, Verfügbarkeit. FURPS+ nimmt 4 weitere Anforderungen hinzu, nämlich, erstens, das Konzept der Designanforderungen. Das sind Fragen wie, muss eine iPhone-App beispielsweise sein oder brauchen wir unbedingt eine relationale Datenbank? Das sind keine eigentlichen Features der Anwendung, sondern etwas, worauf Sie ganz besonders achten müssen. Des Weiteren gibt es die Implementierungsanforderungen. Das sind Dinge wie, welche Sprache verwenden wir? PRP oder Java zum Beispiel. Müssen wir uns an bestimmte Standards halten oder vielleicht sogar an eine bestimmte Methodik? Eine Schnittstellenanforderung bezieht sich auf ein externes System, mit dem Sie kommunizieren müssen. Und dies müssen Sie eben ganz genau spezifizieren. Und eine physische Anforderung legt tatsächlich eine physische Einschränkung fest. Alles von "muss auf einem Gerät mit Kamera laufen" bis hin zu "muss mit 50 GB großen DVDs ausgeliefert werden. Doch noch einmal: Im ersten Durchgang suchen Sie nach der absoluten Mindestmenge von Anforderungen. Es geht nicht darum, was wünschenswert wäre, was optional ist, nicht um all Ihre Traumfeatures oder die Ihrer Kunden. Nur darum, was unbedingt erforderlich ist. Aus technischer Sicht hat das, was wir hier tun, noch nichts mit Objektorientierung zu tun. Wenn Sie in dieser Phase Wörter wie Polymorphie oder oder Abstraktion verwenden, dann liegen Sie falsch. Wir erwarten hier nicht einmal das Wort Klasse oder Objekt. Worauf wir hinauswollen ist etwas Niedergeschriebenes, ein Anforderungsdokument, in einfachem Deutsch. Nicht mehr, aber auch nicht weniger.

Grundlagen der Programmierung: Objektorientiertes Design

Lernen Sie alle Grundbegriffe und Methoden von objektorientiertem Design kennen und holen Sie sich das Rüstzeug, um bald Ihre eigene Softwareprojekte zu starten.

2 Std. 43 min (45 Videos)
Derzeit sind keine Feedbacks vorhanden...

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!