Die Kunst der Modellierung 7 Sections64 Lessons6 Quizzes8 Weeks
Anforderungsspezifikation
Etappe 1: Vom Kundenwunsch zur Analyse
Wie formuliert man eine Anforderung richtig?
Aus der Ist-Analyse wissen wir nun, wie es bei Chez Motchi heute läuft. Der nächste Schritt besteht darin, daraus eine Soll-Konzeption zu entwickeln: Wir legen fest, welche Funktionen die neue Software tatsächlich bieten soll, und dokumentieren das in einer Anforderungsspezifikation.
Klingt einfach – ist es aber nicht. Denn Anforderungen lassen sich erstaunlich leicht schlecht formulieren.
Was macht eine gute Anforderung aus?
Eine gute Anforderung muss vier Eigenschaften erfüllen. Fehlt eine davon, entstehen später Missverständnisse zwischen Motchi und dem Entwicklungsteam.
| Eigenschaft | Bedeutung | Schlechtes Beispiel |
|---|---|---|
| Korrektheit | Entspricht präzise dem, was tatsächlich vereinbart wurde – vollständig, ohne eigene Zusätze | „Die App soll automatisch SMS verschicken“ (obwohl nur E-Mails vereinbart waren) |
| Eindeutigkeit | Nur eine einzige Interpretation möglich, ohne Widersprüche | „Die Software soll die Daten möglichst schnell und zuverlässig speichern“ |
| Prüfbarkeit | Der Nachweis der erfolgreichen Umsetzung muss möglich sein | „Die Benutzeroberfläche soll attraktiv und modern wirken“ |
| Nachverfolgbarkeit | Der Umsetzungsprozess muss nachvollziehbar bleiben | „Die Anwendung soll irgendwann ein sicheres Login enthalten“ |
Formuliert man stattdessen konkret „Das System muss eine Reservierung innerhalb von zwei Sekunden speichern und dem Gast eine Bestätigung anzeigen“, lässt sich diese Anforderung eindeutig prüfen – ganz im Gegensatz zu „möglichst schnell und zuverlässig“.
Woraus bestehen Anforderungen?
Anforderungen an ein System wie Motchis Reservierungssoftware lassen sich grob in zwei große Gruppen einteilen.
Anforderungen
/
Funktionale Nicht-Funktionale
Anforderungen Anforderungen
/
Qualitäts- Rahmen-
anforderungen bedingungen
Funktionale Anforderungen
Funktionale Anforderungen beschreiben, was das System leisten soll. Sie sind sehr spezifisch und hängen direkt von der jeweiligen Software ab – etwa Funktionen und Funktionskomplexe, Eingabedaten, Verarbeitungsschritte und Ausgaben.
🥐 Funktionale Anforderung bei Chez Motchi
„Das System muss es ermöglichen, eine Reservierung mit Name, Uhrzeit, Personenzahl und Tischwunsch anzulegen und dem Gast per E-Mail zu bestätigen.“
Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen beschreiben dagegen, wie das System seine Leistungen erbringen soll. Sie sind oft schwerer zu formulieren, weil sie teils subjektiv wirken – „soll gut aussehen“ ist eben keine überprüfbare Aussage. Man unterscheidet zwei Hauptarten: Qualitätsanforderungen und Rahmenbedingungen.
Qualitätsanforderungen
| Kriterium | Bedeutung | Schlechtes Beispiel |
|---|---|---|
| Benutzbarkeit | Umgangsfreundlichkeit, Skizze der grafischen Oberfläche | „Das System soll ein modernes Design haben“ |
| Zuverlässigkeit | Fehlertoleranz, Wiederherstellbarkeit bei Softwareversagen | „Die Software darf möglichst selten abstürzen“ |
| Effizienz | Zeitverhalten, Verbrauchsverhalten | „Die Software soll schnell laufen“ |
| Änderbarkeit | Anpassungsfähigkeit an neue Anforderungen | „Die Architektur soll zukünftige Erweiterungen ermöglichen“ |
| Übertragbarkeit | Effizienz der Umgebungsmigration | „Die Software soll auf vielen Plattformen laufen“ |
Statt „Die Software darf möglichst selten abstürzen“ wäre eine prüfbare Version zum Beispiel: „Das System muss eine Verfügbarkeit von mindestens 99 % während der Öffnungszeiten von Chez Motchi gewährleisten.“
Rahmenbedingungen
| Art | Bedeutung | Schlechtes Beispiel |
|---|---|---|
| Technologisch | Vorhandene technische Infrastruktur – Plattformen, Schnittstellen, Nachbarsysteme | „Die Software soll mit moderner Technik laufen“ |
| Organisatorisch | Aufbau und Prozessabläufe der nutzenden Abteilungen, feste Projekttermine | „Die Software muss rechtzeitig fertig werden“ |
| Normativ | Einzuhaltende Gesetze, Verordnungen, Normen, kulturelle Aspekte | „Es müssen relevante Vorschriften beachtet werden“ |
Für Chez Motchi wäre eine konkrete Rahmenbedingung etwa: „Das System muss auf dem vorhandenen Tablet mit Android 12 lauffähig sein und die Kundendaten gemäß DSGVO speichern.“
Beispiel: Login-Ablauf bei Chez Motchi
Eine funktionale Anforderung lässt sich oft am besten Schritt für Schritt beschreiben. Angenommen, Motchis Mitarbeitende sollen sich zunächst anmelden, bevor sie Reservierungen bearbeiten dürfen:
- Mitarbeiter öffnet die Login-Seite.
- Mitarbeiter gibt Benutzername und Passwort ein.
- System prüft die Eingaben.
- System überprüft Benutzername und Passwort in der Datenbank.
- Bei korrekten Daten: Login erfolgreich, Weiterleitung zur Reservierungsübersicht.
- Bei falschen Daten: Fehlermeldung, zurück zu Schritt 2.
Eine solche Schrittfolge lässt sich später sowohl in einem UML-Aktivitätsdiagramm als auch technisch in einem Klassendiagramm abbilden – beides lernen wir im weiteren Kursverlauf.
💡 Merke
- Gute Anforderungen sind korrekt, eindeutig, prüfbar und nachverfolgbar.
- Funktionale Anforderungen beschreiben, was das System tun soll.
- Nicht-funktionale Anforderungen beschreiben, wie das System diese Leistung erbringen soll – unterteilt in Qualitätsanforderungen und Rahmenbedingungen.
- Vage Formulierungen wie „schnell“ oder „modern“ sind keine überprüfbaren Anforderungen.
🚀 Ausblick
Damit ist Etappe 1 abgeschlossen: Wir wissen jetzt, wie man ein Café analysiert und daraus saubere Anforderungen ableitet. In der nächsten Lektion beginnt Etappe 2 – wir betrachten Chez Motchi erstmals als Sammlung von Objekten und legen damit den Grundstein für die spätere UML-Modellierung.