Freitag, 24. November 2006
Thema: Anforderungen
Nicht-funktionale Anforderungen sind nach wie vor ein schwieriges Kapitel in jedem Pflichtenheft. Ich erlebe häufig, dass Kunden nicht an Qualität denken, bevor ich sie dazu zwinge ;-)
Schlimmer ist, dass sich auch viele Analytiker schwer tun, nicht-funktionale Anforderungen zu fassen.
In meinen letzten Projekten hatte ein paar spannende Berührungspunkte mit der Dienstleistungsqualität und so sind ein paar Gedanken entstanden, die ich hier in einen Artikel gieße.
Statt dem Begriff "nicht-funktionale Anforderungen" verwende ich gerne "Dienstleistungsqualität" oder allgemein "Qualität". Die Anforderungen klingen einfach zu sehr nach dem oberen Drittel der Abstraktionspyramide.
Qualität gibt es auf jeder Ebene
Qualität ist kein Ding von Lastenheften, die im Pflichtenheft durch eine funktionale Spezifikation "gelöst" werden.
Sicher gibt es Anforderungen, z. B. zur Sicherheit, die im Pflichtenheft (teilweise) durch Funktionalität gelöst werden, z. B. durch ein Login.
Im Allgemeinen gibt es aber auf jeder Ebene von Anforderungen ein "wie gut". (Siehe auch den lesenswerten Kommentar von Rolf Götz zum "Was und Wie".)
Z. B. lässt sich die Sicherheit nicht nur als Funktion beschreiben, die Sicherheitslücken schließt, sondern eben auch als Qualität des Codes, der keine Lücke offen lässt.
Ein anderes Beispiel ist die Erweiterbarkeit, die ein Kriterium von gutem Code ist.
Qualitätsanforderungen sind Risikofaktoren
Eine vergessene funktionale Anforderung führt zu Ärger und zu Nachbesserung. Eine vergessene Qualitätsanforderung führt zum Scheitern des Projekts!
In einem unserer Projekte plante unser Kunde eine Lösung für die interne Nutzung, besann sich dann gegen Ende des Projekts jedoch darauf, sie auch über das Internet jedermann zugänglich zu machen. Die Funktionalität blieb dieselbe, die Software musste nur ins Internet gestellt werden.
Niemand denkt an Sicherheitsaspekte, die plötzlich so wichtig werden wie die Funktionalität.
Plötzlich werden Qualitätsabteilungen hellhörig, die IT des Unternehmens wurde aufmerksam. Vorher unbeteiligte Personen schalten sich ein und die Software wird politisch relevant, die Kreise werden größer. Mit einem Mal ist eine erfolgskritische Anforderung "Sicherheit" relevant!
Unser Kunde ist baff und wir reden plötzlich mit vielen Menschen statt mit einem Kunden. Die Software muss (fast) neu geschrieben werden...
Qualitätsanforderungen sind einfach
Zumindest auf hoher Abstraktionsebenen ist es einfach, Qualitätsanforderungen aufzustellen. Damit sind zumindest die größten Risiken eines Projekts abgedeckt. Ich nutze eine Checkliste mit wenigen Aspekten wie Sicherheit, Usability, Effizienz, um die Anforderungen zu prüfen. Checklisten bieten z. B. DIN 66272 oder Volere.
Eine größere Herausforderung ist, die Qualität der Software messbar zu machen. Ich finde das Prinzip von GQM praktisch, ein anderer Ansatz ist Planguage von Tom Gilb.
Schlimmer ist, dass sich auch viele Analytiker schwer tun, nicht-funktionale Anforderungen zu fassen.
In meinen letzten Projekten hatte ein paar spannende Berührungspunkte mit der Dienstleistungsqualität und so sind ein paar Gedanken entstanden, die ich hier in einen Artikel gieße.
Statt dem Begriff "nicht-funktionale Anforderungen" verwende ich gerne "Dienstleistungsqualität" oder allgemein "Qualität". Die Anforderungen klingen einfach zu sehr nach dem oberen Drittel der Abstraktionspyramide.
Qualität gibt es auf jeder Ebene
Qualität ist kein Ding von Lastenheften, die im Pflichtenheft durch eine funktionale Spezifikation "gelöst" werden.
Sicher gibt es Anforderungen, z. B. zur Sicherheit, die im Pflichtenheft (teilweise) durch Funktionalität gelöst werden, z. B. durch ein Login.
Im Allgemeinen gibt es aber auf jeder Ebene von Anforderungen ein "wie gut". (Siehe auch den lesenswerten Kommentar von Rolf Götz zum "Was und Wie".)
Z. B. lässt sich die Sicherheit nicht nur als Funktion beschreiben, die Sicherheitslücken schließt, sondern eben auch als Qualität des Codes, der keine Lücke offen lässt.
Ein anderes Beispiel ist die Erweiterbarkeit, die ein Kriterium von gutem Code ist.
Qualitätsanforderungen sind Risikofaktoren
Eine vergessene funktionale Anforderung führt zu Ärger und zu Nachbesserung. Eine vergessene Qualitätsanforderung führt zum Scheitern des Projekts!
In einem unserer Projekte plante unser Kunde eine Lösung für die interne Nutzung, besann sich dann gegen Ende des Projekts jedoch darauf, sie auch über das Internet jedermann zugänglich zu machen. Die Funktionalität blieb dieselbe, die Software musste nur ins Internet gestellt werden.
Niemand denkt an Sicherheitsaspekte, die plötzlich so wichtig werden wie die Funktionalität.
Plötzlich werden Qualitätsabteilungen hellhörig, die IT des Unternehmens wurde aufmerksam. Vorher unbeteiligte Personen schalten sich ein und die Software wird politisch relevant, die Kreise werden größer. Mit einem Mal ist eine erfolgskritische Anforderung "Sicherheit" relevant!
Unser Kunde ist baff und wir reden plötzlich mit vielen Menschen statt mit einem Kunden. Die Software muss (fast) neu geschrieben werden...
Qualitätsanforderungen sind einfach
Zumindest auf hoher Abstraktionsebenen ist es einfach, Qualitätsanforderungen aufzustellen. Damit sind zumindest die größten Risiken eines Projekts abgedeckt. Ich nutze eine Checkliste mit wenigen Aspekten wie Sicherheit, Usability, Effizienz, um die Anforderungen zu prüfen. Checklisten bieten z. B. DIN 66272 oder Volere.
Eine größere Herausforderung ist, die Qualität der Software messbar zu machen. Ich finde das Prinzip von GQM praktisch, ein anderer Ansatz ist Planguage von Tom Gilb.
... kommentieren