Einfach nicht… funktional! (Teil 1)

Sie spezifizieren Systeme und deren Funktionen, Requirements sind für Sie kein Fremdwort, und Sie sind sich der bedeutenden Rolle guter Anforderungsspezifikationen bewusst? Haben Sie sich dann auch schon näher mit den nicht-funktionalen Anforderungen beschäftigt und deren Bedeutung zu schätzen gelernt?

Nicht-funktionale Anforderungen (NFA) tragen maßgeblich dazu bei, das System so zu entwickeln, wie es der Auftraggeber eigentlich haben möchte. Deshalb widmen wir den NFA eine ganze Blogserie. In diesem Teil stellen wir Ihnen die verschiedenen Kategorien der NFA vor und zeigen ihre Bedeutung für die Entwicklung eines für den Auftraggeber brauchbaren Systems. In den beiden darauf folgenden Teilen zeigen wir Ihnen dann, wie Sie NFA systematisch erheben können.

Haben Sie schon mal versucht, eine Dose Ravioli mit dem Schraubenzieher zu öffnen? Beim letzten Date gemerkt, dass kein Korkenzieher im Haus ist und es mit dem Brotmesser versucht? In solchen Augenblicken wird einem recht schnell bewusst, dass das einfach nicht funktional ist. Wer also bitte braucht „nicht- funktionale Anforderungen“?

Wir finden es ziemlich amüsant, dass „nicht-funktionale Anforderungen“ erst einmal das Gegenteil dessen implizieren, was sie eigentlich bewirken: nämlich maßgeblich dazu beizutragen, dass ein zu spezifizierendes System funktional wird.

Verwirrt? Wir klären auf. Nicht- …Sprechpause… funktionale Anforderungen sind, einfach und verallgemeinert ausgedrückt, all jene Anforderungen, die NICHT die Funktion, also das, was ein System tun soll, enthalten. NFA beschreiben das „Wie“ und damit u.a. technische Eigenschaften und Anforderungen bezüglich der Qualität. NFA beschreiben, wie Teile oder Aspekte des Systems beschaffen sein sollen oder wie Prozesse um das System herum durchgeführt werden müssen.

Denken Sie beispielsweise an eine funktionale Anforderung zur Beschreibung einer Suchfunktion. Eine entsprechende NFA dazu könnte lauten, dass das System ein Suchergebnis innerhalb von 3 Sek. liefern muss. Wenn Sie sich nun ausmalen, was wohl wäre, wenn es diese NFA nicht gäbe, bekommen Sie unmittelbar ein Gefühl dafür, wie entscheidend NFA dazu beitragen, dass Systeme „funktional“ – im umgangssprachlichen Sinne – werden. Sie säßen sonst womöglich stundenlang wartend vor ihrem Rechner. Das wäre einfach nicht funktional.

Im umgangssprachlichen Sinne bezeichnen wir mit „funktional“ schlicht und einfach Dinge, die für einen Zweck gut, nützlich und tatsächlich hilfreich und praktisch anwendbar sind – eben richtig funktionieren. NFA benötigt deshalb also jeder, der den Nutzen des Systems für seinen Auftraggeber sicherstellen möchte.

NFA lassen sich in Kategorien einteilen:NFA_Teil 1_Kategorien für nicht-funktionale Anforderungen

Da gibt es Anforderungen an die Benutzungsoberfläche, technologische Anforderungen, rechtlich-vertragliche Anforderungen, Anforderungen an durchzuführende Tätigkeiten, Anforderungen an sonstige Lieferbestandteile und Qualitätsanforderungen.

Mit technologischen Anforderungen können Sie all jene Anforderungen benennen, die beschreiben, wie etwas technisch realisiert werden soll oder welche Eigenschaften technische Komponenten aufweisen sollen. Und um obige These nochmal aufzugreifen – Sie erinnern sich: NFA tragen maßgeblich dazu bei, ein System „funktional“ zu machen. Eine Schneefräse, deren Komponenten bei Minusgraden den Dienst verweigern, können Sie allenfalls noch zum Entfernen von Laub verwenden. Der Nachbar lässt grüßen. Sie sehen: NFA sind unerlässlich. Um das zu überprüfen, malen Sie sich zu den weiteren Kategorien doch einfach noch einige weitere Kopfbilder, denn nicht weniger nötig sind Anforderungen an die Benutzungsoberfläche.

Mit Anforderungen an die Benutzungsoberfläche definieren Sie, „wie“ sich das System dem Benutzer darstellen soll. Somit steuern Sie durch eine klare Spezifikation von NFA, wie anwenderfreundlich und praktikabel ihr System gestaltet werden soll. Sonstige Lieferbestandteile bündeln alle Anforderungen, um zu beschreiben, welche Produkte zusätzlich zum eigentlichen System geliefert werden müssen, z.B. ein Handbuch. Eine Qualitätsanforderung definiert eine qualitative Eigenschaft, die das betrachtete System, eine seiner Funktionen, der Prozess oder eine am Prozess beteiligte Person aufweisen muss.

Rechtlich-vertragliche Anforderungen benennen alle Regelungen zwischen Auftraggeber und Auftragnehmer, wie z.B. die Übertragung der Nutzungsrechte. Und zu guter Letzt beschreiben Sie mit Anforderungen an durchzuführende Tätigkeiten z.B. den Entwicklungsprozess selbst oder Wartung und Support, um damit langfristig ein funktionales System zu realisieren bzw. zu erhalten.

Neugierig geworden auf mehr? Dann freuen Sie sich auf den SOPHIST-Erhebungsprozess für NFA in den beiden folgenden Blogteilen. Damit geben wir Ihnen einen praxisorientierten Ansatz, um NFA systematisch zu ermitteln und zu dokumentieren.

Ihr André Pflüger und Sascha Frehse

 

Einfach nicht… funktional! (Teil 2)
Einfach nicht… funktional! (Teil 3)

—————————————-
Quellenangabe:
Bild Kategorien von NFA: Requirements-Engineering und -Management; 6. Auflage; Seite 268, Abbildung 12.1

Ein Gedanke zu „Einfach nicht… funktional! (Teil 1)

  1. Guten Tag Herr Pflüger und Herr Frehse.
    Schon mal versucht, mit einem Schrauben“zieher“ eine Schraube ein- oder auszudrehen?
    Schon mal eine Schraube „gezogen“, die sich danach wieder einschrauben lässt?
    Oder doch lieber den Schraubendreher verwenden?
    Funktionale Anforderung: Der Schraubendreher muss dem Anwender die Möglichkeit bieten, eine Schraube zu drehen. Herzlichen Dank und freundliche Grüße

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert