Requirements Engineering Methoden

Anforderungen müssen 'atomar' sein, schreibt die einschlägige Requirements-Engineering-Literatur.

Nachdem ich in der Vergangenheit viele atomare Anforderungen geschrieben habe und vor einigen Jahren dann zu Use-Cases als Dokumentationswerkzeug übergegangen bin, möchte ich dem widersprechen.
Atomare Anforderungen mögen formal toll sein, nützlich sind sie nicht.

Mein Hauptkritikpunkt an atomaren Anforderungen ist die erschwerte Lesbarkeit. Dokumentation dient in erster Linie dazu, gelesen zu werden und sollte leicht lesbar und möglichst gut verständlich sein.
Insbesondere der Kontext einer Anforderung und die Zusammenhänge zwischen den einzelnen Anforderungen sollen IMHO leicht erfassbar sein können, um es dem Leser einfach zu machen, die Komplexität zu erfassen.
Aus einer Menge atomarer Anforderungen diese Komplexität zu erfassen, ist fast unmöglich für einen untrainierten Leser.

Lt. Wikipedia soll das Kriterium für ein "Atom" die Entscheidbarkeit einer Anforderung sein.
Formal gesehen muss also in einer Anforderung alle Information enthalten sein, um zu entscheiden ob sie erfüllt ist. Das heißt, der gesamte Kontext, insbesondere alle Vorbedingungen zum Erreichen der Anforderung, müssen in der Anforderung genannt sein!?

Da das viel zu aufwendig und nicht mehr lesbar ist, ergibt sich der Kontext meist aus den umstehenden Anforderungen. Oftmals gibt es für eine Handvoll zusammenhängender Anforderungen einen Übersichtsabschnitt, der den Kontext und den Zusammenhang der Anforderungen erklärt, bevor dann die einzelnen atomaren Anforderungen aufgezählt werden.
Dieser Übersichtsabschnitt ist demnach redundant zu den umstehenden Anforderungen, er bündelt nur die Einzelpunkte mit dem Ziel der Lesbarkeit. Manchmal nennt er auch ein übergeordnetes Ziel, die atomaren Anforderungen dann die Details.

Beiden Varianten würde ich die Integration der Informationen vorziehen. Ich lasse die Detailanforderungen weg und integriere sie in den Übersichtsabschnitt!

Alle potenziellen Leser profitieren von leichter Lesbarkeit. Selbst Tester, die atomar entscheiden sollen, ob eine Anforderung erfüllt ist, profitieren von den Zusammenhängen für ihre Testfälle.
Das einzige Szenario, das mir einfällt, in dem atomare Anforderungen notwendig sind, ist die Abnahme mit dem Anwalt – eine Situation, in die ich hoffentlich nicht kommen werde...

Die Art und Weise der Dokumentation von Anforderungen hat Einfluss auf die Analyse der Anforderungen. Meine Erfahrung ist, dass eine geeignete Dokumentationsmethodik die Analyse unterstützen kann.
Ich habe die folgenden Erfahrungen mit diesen Dokumentationsmethoden gemacht:

Sammlung von Requirements a la "Das System muss ...", strukturiert nach Thema der Anforderung
Keine Unterstützung für die Analyse, da die Anforderungen keine Beziehung zueinander haben.
Ein weiterer Nachteil ist die schwere Lesbarkeit. Der Leser muss die Anforderungen in seinem eigenen mentalen Modell zusammen setzen.
Geeignet für sehr formale Rahmenbedingungen, da einzelne Anforderungen referenziert / abgenommen / etc. werden können.
Mein Tipp: Hierarchische Übersichtsabschnitte um den Zusammenhang und das Big Picture der Anforderungen zu bekommen.

Use-Case-Modellierung (in Text-Szenarien oder als Aktivitätsdiagramm)
Use-Cases erleichtern, sicherzustellen, dass das System dem Anwender ermöglicht, sein Ziel zu erreichen. Ausnahmen und Fehlerfälle können methodisch ermittelt werden.
Meine Lieblings-Dokumentation für alle Benutzerinteraktionen, insbesondere wegen der Zielorientierung.
Ein Nachteil ist die hohe Freiheit beim Dokumentieren. Use-Cases können auf unterschiedlicher Ebene modelliert werden - was bewusst geschehen muss.
Geeignet insbesondere für Systeme mit Benutzerinteraktion.
Mein Tipp: Ein gutes Buch zum Thema besorgen.

UML-Modell (insb. Zustandsdiagramme / Klassendiagramme)
OOA-Modelle unterstützen, das System vollständig zu analysieren inkl. aller Ausnahmen. Es fällt leicht, alle Systemaspekte auf einer Abstraktionsebene zu analysieren.
Großer Nachteil ist die hohe Einstiegshürde zum Lesen und Interpretieren der OO-Modelle. Der Leser benötigt Grundverständnis der (technischen) Sprache UML.
Geeignet falls alle Leser UML verstehen oder als Hilfsmittel für den Analytiker, Vollständigkeit zu erreichen.
Mein Tipp: Mit anderen Methoden mischen, ggf. Redundanz in Kauf nehmen zugunsten der leichteren Lesbarkeit.

Als Business Analyst und Projektleiter verbringe ich viel Zeit in Meetings mit Kollegen, Anwendern, Managern und anderen Stakeholdern. Um so wichtiger ist es, diese Meetings effektiv zu gestalten.
Aber - wer kennt das nicht? Teilnehmer sind unvorbereitet, andere diskutieren über uninteressante Dinge, das Meeting hat kein Ergebnis und ein neues Meeting zu demselben Thema muss anberaumt werden?
Folgende Regeln für effektive Meetings haben sich sehr bewährt:

• Ziel formulieren
  Ein festgelegtes Ziel hilft den Teilnehmern, sich zu fokussieren und hilft dem Moderator, das Meeting zielgerichtet zu halten.
• Agenda verteilen
  Eine vorab verteilte Agenda, ggf. mit Zeitangaben, hilft ebenfalls, die Diskussion effektiv zu halten. Als Moderator zwingt mich das Formulieren der Agenda, mir Gedanken über den effektiven Ablauf des Meetings zu machen.
• Vorbereitung
  Eine gute Vorbereitung durch den Moderator mag selbstverständlich sein. Vorher an die Teilnehmer verteilte Aufgaben helfen, das Meeting frei von Vorträgen zu halten und sich auf die Entscheidungen zu konzentrieren.
• Ergebnisse
  Die Ergebnisse werden im Meeting zusammengefasst und ggf. per Protokoll verteilt. Aufgaben für die Teilnehmer werden definiert und namentlich an einzelne Personen vergeben.

Marissa Meyer von Google hat strenge Regeln aufgestellt und wendet diese für jedes 5-Minuten-Meeting an.
Die Regel "Demonstrate Respect for People's Time" gibt wie ich finde ein gutes Selbstverständnis eines Moderators wieder. Scott Sehlhorst formuliert diese als eine der Regeln um Meetings 60% effektiver zu machen. Er gibt außerdem Verhaltenstipps, wenn sich z. B. Teilnehmer nicht vorbereiten.

In die gleiche Richtung gehen die Top 7 Strategien für produktive Meetings von Kevin Kearns.
Für Meetings, die ich selbst veranstalte, wende ich diese Regeln konsequent an - und bin im Allgemeinen zufrieden mit der Meeting-Effizienz... Schwieriger ist es natürlich in Meetings als Teilnehmer. Hier hilft es, vorher ein Ziel und eine Agenda zu fordern. Ich frage meist auch, wie ich mich vorbereiten kann. Gelingen Meetings dennoch nicht nach meiner Zufriedenheit, hilft Feedback, ggf. mit Hinweis auf die Artikel oben...

Projektkontext
Seit ca. 2 Jahren hatten wir für einen Kunden ein System in enger Zusammenarbeit mit den Anwendern entwickelt. Eine spannende Erfahrung, weil das entstehende System trotz seiner hohen Komplexität in relativ kurzer Zeit entstand. Dem System zur Modellierung von maschinell ausgeführten Workflows lag wegen seiner Komplexität eine online/offline SOA-Architektur zugrunde.
Mit dem Rollout des Systems sollte die Weiterentwicklung formalisiert werden um eine hohe Sicherheit für ein sicheres System zu erreichen. Dazu wurde eine vollständige Spezifikation (inkl. Oberflächen-Dokumentation), automatische Tests und zur Unterstützung der Anwender ein Benutzerhandbuch (separat) erstellt.
Um folgende Ziele zu erreichen, wurden die entstehenden Artefakte verknüpft (Tracing):

• Vollständigkeit herstellen (Tests, Handbuch, Oberflächen)‏
• Vollständige Abdeckung durch Tests sicherstellen
• Änderungen konsistent dokumentieren

Lösung
Für das Tracing führten wir Verknüpfungen der Artefakte Tests, Handbuch und Oberflächen-Dokumentation auf die Anforderungen ein:

• Tests -> Anforderungen
• Handbuch -> Anforderungen
• Oberflächen-Dokumentation -> Anforderungen

Wichtig für das Tracing-Konzept waren die Ziele, auf Basis derer wir festlegten, welche Informationen verlinkt werden mussten. Wir entschieden uns z. B. gegen ein Tracing innerhalb der Anforderungen, weil der Aufwand im Verhältnis zum Nutzen "Änderungen konsistent dokumentieren" unter den gegebenen Rahmenbedingungen nicht gerechtfertigt war.
Dem Kunden stellten wir das Konzept zum Tracing vor, wobei er den zusätzlichen Aufwand (jetzt und bei jeder Änderung) in Kauf nahm, die Links zu erstellen und zu warten.

Tool
Eine wichtige Erfahrung war, dass ein Tool unbedingt erforderlich war, die Ziele zu erreichen. Wir erstellten bereits Anforderungen und Tests als das Tool noch nicht einsatzbereit war. Zu dieser Zeit war es z. B. unmöglich, den Fortschritt des Projekts zu kontrollieren (Testabdeckung). Ein Tool ermöglichte außerdem, zusammenhängende Bestandteile mit hoher Sicherheit zu erkennen.
Wir setzten Microsoft SharePoint mit Listen für jedes Artefakt ein. Auswertungen führten wir mithilfe von Excel durch.

m Allgemeinen gehe ich auf meinen Gesprächspartner ein. Ich antizipiere seine Sprache, seine Welt, seine Durchdringung eines Sachverhalts und unterstütze z. B. mit visuellen Hilfsmitteln um mein Anliegen für ihn so möglichst einfach verständlich zu machen.

Aber: Ist das immer sinnvoll?

Vor ein paar Tagen hörte ich ein Gespräch, bei dem ein Kollege seinem Gegenüber einen unverständlichen Brocken hinwarf und dann erst einmal eine Pause machte. Der Gesprächspartner guckte verwirrt und fragte nach "Was bedeutet das?", worauf der Kollege nach und nach (immer wieder Fragen abwartend) mit der Wahrheit herausrückte.
Das Gegenüber war gezwungen, aufzupassen und immer wieder Fragen zu stellen um den Sachverhalt zu verstehen – er musste aktiv mitdenken.
Würde ich ihm den Sachverhalt leicht verdaulich servieren, würde er nach Ende meines Monologs im Halbschlaf "jaja" sagen und anschließend die Hälfte wieder vergessen!?

Projektkontext
In einem E-Learning-Projekt sollte ein Konzept für die Anforderung "Kopierschutz" erarbeitet werden. Das E-Learning sollte lt. Lastenheft einen "Kopierschutz" enthalten.
Für das Konzept musste zunächst die Anforderung geklärt werden (eine berühmte nicht-funktionale Anforderung, wie man sie oft findet). Viele Ansprechpartner mussten einbezogen werden, was Richtlinien für Verschlüsselung beim Unternehmen unseres Kunden sowie in den verschiedenen Ländern betraf (China, Frankreich).
Aus den zur Verfügung stehenden Alternativen konnten mit wachsender Erkenntnis die beste ausgewählt werden.

Lösung
Um die wachsenden Informationen zum Thema "Sicherheit" im Verlauf des Prozesses nicht zu vergessen, erstellte ich ein Konzept-Dokument, in dem alle Informationen von der Lastenheft-Anforderung bis zu den Begründungen für die Verwendung einer Alternative dokumentiert waren. Es enthielt die Anforderungen aller Ebenen (bis zu Umsetzungsdetails) zum Thema "Sicherheit".
Das entstehende Konzept-Dokument schrieb ich während der Erarbeitung fort und dokumentierte den jeweils aktuellen Wissensstand. Verworfene Alternativen kopierte ich mit Begründung in den Anhang.
Das Dokument diente zu jedem Zeitpunkt als Kommunikationsgrundlage mit den Stakeholdern (jeweils relevante Auszüge) sowie als Dokumentation der Entscheidungskriterien gegenüber unserem Kunden sowie der internen Entwicklung.
Nach dem Projekt diente das Konzept-Dokument in weiteren Projekten als Vorlage um das jeweilige Sicherheitskonzept zu erarbeiten. Das Dokument war sehr gut wiederverwendbar, da nicht nur das Konzept sondern der Weg dorthin dokumentiert war.

Aufbau
Das Dokument enthielt die folgenden Informationen:

• Lastenheft-Anforderung sowie Aussagen des Kunden
• Tiefer analysierte Anforderung: Was ist der Gegenstand des Schutzes und was ist sein Wert? Welche Gefahren-Szenarien gibt es? Welche (messbaren) Anforderungen an die Sicherheit ergeben sich daraus?
• Konzept mit verschiedenen Alternativen zu Algorithmus, Schlüsselhinterlegung und Zeitpunkt der Entschlüsselung
• Constraints durch die weltweite Verteilung (z. B. Roll-Out in Frankreich und China) und mögliche Umsetzungsvarianten

Nach und nach konkretisierten sich die Randbedingungen durch Gesprächen mit Stakeholdern, wodurch sich die Zahl der möglichen Alternativen reduzierten. Die verworfenen Alternativen verschob ich in den Anhang und dokumentierte den Grund.

Projektkontext
Ein bestehendes Portal zur Auslieferung von Dokumenten an Kunden sollte abgelöst werden. Im Vordergrund stand dabei eine vereinfachte Wartung und Pflege der Dokumente je Kunde. Das neue Portal sollte die spezifischen Eigenschaften des Kundenkreises berücksichtigen und so den Pflegeaufwand reduzieren, um identische Dokumente an verschiedene Kunden zu verteilen, die bisher für jeden Kunden separat eingestellt werden mussten. Die neue Lösung sollte diesen Schritt automatisieren.
Ein wichtiger Aspekt des Konzept war also, die Arbeitsweise effizienter zu gestalten.
Da ich zum Zeitpunkt der Konzeption erst kurz bei der GfK war, war es für mich außerdem wichtig, die Arbeitsweise der Kollegen kennen zu lernen.
Eine Herausforderung war, die Ausnahmen vollständig zu erfassen und Möglichkeiten zu deren Behandlung zur Verfügung zu stellen.

Lösung
Im Konzept fokussierte ich zunächst auf den Workflow um die zukünftige effiziente Arbeitsweise zu definieren. Sonderfälle und Ausnahmen konnten im Workflow dargestellt werden.
Zur Dokumentation nutzte ich klassische Use-Cases mit Diagramm zur Übersicht und Beschreibung für die Details des Workflows. Mithilfe der Beschreibung konnte ich den Workflow mit den Anwendern durchsprechen und Sonderfälle identifizieren sowie die Vereinfachung der Arbeitsweise deutlich machen. Unterstützend nutzte ich einfache Objektdiagramme (kein UML, sondern Powerpoint ;-)

Beispiele
Das Use-Case-Diagramm zeigt einen Überblick über die geplanten Erweiterungen. Die Use-Cases beschreiben die Workflows.


Häufig habe ich Use-Cases auf der Ebene einer Systemspezifikation eingesetzt.

Projektkontext
Für einen Kunden sollten wir eine Datenbank für medizinische Bilder erstellen, die Anwendern ermöglichen sollte, möglichst einfach das richtige Bild zu finden. Einfachheit und Geschwindigkeit der Intranet-Applikation standen für die Anwender im Vordergrund. Andere Mitarbeiter, die Editoren, bereiteten die Bilder auf und qualifizierten sie.
Unser Kunde liebte die UML. Bereits das Lastenheft enthielt Aktivitätsdiagramme. Diese Chance wollten wir nutzen und UML auch in der Zusammenarbeit mit dem Kunden einzusetzen.

Lösung
Zu Projektbeginn entschied ich mich dafür, Zustandsdiagramme zur Konzeption zu nutzen, da sie erlauben, das Verhalten aus Sicht des Systems zu spezifizieren. Wir nutzten die Diagramme zur funktionalen Spezifikation des Systems.
Ich erinnere mich gerne an die äußerst effektiven Workshops, in denen ich mit dem Kunden gemeinsam Zustandsmodelle entwickelte. Wir sprachen dieselbe Sprache – UML.
Es war einfach, Ausnahmen und Fehlerfälle zu erkennen und so die Vollständigkeit herzustellen. Das Ergebnis war eine sehr präzise Dokumentation des Systemverhaltens. Wichtig war dabei, dass die Diagramme immer durch Text ergänzt werden mussten. Ich nutzte die Möglichkeiten der UML, Informationen in den Diagrammen unterzubringen. Dennoch gab es Anforderungen, die nur textuell dokumentiert werden konnten, z. B. welche Informationen in einer Liste angezeigt werden sollten.
Wichtige Erfahrungen waren, dass das ganze Team geschult werden muss, um alle Feinheiten der Diagramme erkennen und nutzen zu können. Eine Voraussetzung für den konsequenten Einsatz von UML war, dass der Kunde diese Sprache sprach.

Beispiele
Zustände definierten einen logischen Schritt für den Anwender. Ein Zustand wurde dabei typischer Weise zu einem Screen der Applikation, in dem bestimmte Funktionen zur Verfügung standen, die als Transitionen am Zustand notiert waren.

Das Beispiel zeigt die Funktionalität beim Ansehen eines Bildes.
Wir setzten Zustandsdiagramme natürlich auch zur Beschreibung von Objektzuständen ein.

Projektkontext
In der Konzeption einer Intranet-Applikation zum Knowledge-Management zur Projektmanagement-Unterstützung setzten wir Use-Cases ein. Darin spezifizierten wir textuell und ablauforientiert die Funktionalität des Tools und wie die Interessen der Benutzer gewahrt wurden. Wir mischten klassische Dokumenten-Management-Ansätze mit Web 2.0 Ideen um die Anwender im Sinne des Unternehmens möglichst gut zu unterstützen.
Die Use-Cases wollten wir anschließend mit der Projektleiterin auf Kundenseite durchsprechen. Die lehnte jedoch das formelle Schema der Use-Cases ab – wir hatten ein eine tabellarische Darstellung gewählt, wie z. B. von Alistair Cockburn beschrieben. Sobald sie dieses formale Schema sah, stoppte sie das Review ohne den Text zu lesen...

Lösung
Um das Konzept mit der Projektleiterin besprechen zu können, mussten wir eine andere Darstellungsform finden. Wir entschieden uns für Wireframes, eine abstrahierte Darstellung der Oberflächen, auf denen das Konzept in einer sehr konkreten Form dargestellt ist. Den Text der Use-Cases formulierten wir ohne Tabelle und weniger formal und kombinierten ihn mit den Wireframes.
Anhand der Wireframes war es einfach, mit der Projektleiterin die Anwendungsfälle durchzusprechen und das Konzept zu reviewen. Die Projektleiterin konnte die zukünftige Arbeitsweise anhand des Papier-Prototyps der Anwender leicht nachvollziehen und ihre Erfahrung aus dem Geschäfts-Alltag einbringen.

Beispiele
Im ersten Beispiel ist ein Wireframe dargestellt, mit Notizen über das funktionale Verhalten der Oberfläche.
Das zweite Beispiel zeigt das Zusammenspiel mehrerer Screens in einer Applikation in einem Flow-Chart. Hinter jedem der Boxen im Flow-Chart steht ein Wireframe. Mithilfe des Flow-Charts lässt sich der Weg des Anwenders durch die Applikation nachvollziehen und optimieren.

Vor einiger Zeit hatte ich das Vergnügen, für ein Seminar der Universität Erlangen einen Vortrag über RE-Methoden im Projektkontext zu halten. Ich habe einige der Methoden vorgestellt, die ich (beinahe) täglich in meinen Projekten einsetze und die Gründe für den Einsatz der Methoden in bestimmten Projekten beschrieben.
In den folgenden Artikeln veröffentliche ich die Berichte über die einzelnen Methoden.

Vor einiger Zeit habe ich zusammen mit Chris Rupp und Frank Rachinger erforscht, ob sich ein Benutzerhandbuch als Spezifikation eignet (Vortragsfolien und Vortragsankündigung).
Die grundlegende Idee war, dass im Benutzerhandbuch eine funktionale Beschreibung aus Benutzersicht beschrieben ist - dieselbe Information, die schließlich auch in der Spezifikation landet. In unserem Artikel haben wir einen (theoretisch) gut funktionierenden Ansatz beschrieben, Aufwand zu sparen und dieselbe Information nur 1x zu dokumentieren - im Benutzerhandbuch.

In einem Projekt bei Spirit Link hatte ich jetzt die Gelegenheit, diesen Ansatz praktisch zu prüfen.
Vorweg: Wir haben uns zu Beginn dagegen entschieden, mit dem Benutzerhandbuch zu spezifizieren und zwei Dokumente geschrieben. Dennoch habe ich immer wieder an meine alten Forschungen gedacht und sie während des Projekts auf eine mögliche Umsetzung geprüft - immerhin hätte sie uns min. 30% des gesamten Aufwands gespart!

Wir haben uns aus folgenden Gründen dagegen entschieden:

• Benutzerhandbuch und Spezifikation haben unterschiedliche Leser.
  Das Benutzerhandbuch muss extrem gut verständlich sein, da es eine komplexe Applikation beschreibt und die Anwender teilweise wenig IT-Verständnis besitzen.
  Die Spezifikation ist für Projektbeteiligte (Auftraggeber und uns) und soll u. a. als formale Grundlage für die Weiterentwicklung dienen.
• Die Spezifikation ist eine formale Grundlage für Tests. Sie muss daher auf derselben detaillierten Abstraktionsebene komplett das gesamte System beschreiben.
• Die Sprache ist unterschiedlich - Prosa vs. Eindeutigkeit; Lesespaß vs. Exaktheit
• Die Detailtiefe ist unterschiedlich (z. B. keine Fehlerbeschreibung im Benutzerhandbuch, siehe Pyramide)

Gibt es andere Erfahrungen? Welche Voraussetzungen gibt es und wann sind diese tatsächlich einmal erfüllt?

Jeff Patton wrote an article about goal levels, that I described in my earlier article Abstraktionsgrad von Anforderungen. He refers to Alistair Cockburn for the description of levels.

What I find an interesting point in Jeff's article is that the same requirement may be on different levels, depending on the context.
He finds two examples, where buying coffee can be either on fish level when I'm ordering a breakfast - or on sea level when I need to get coffee. The other example is looking up an email address for a friend who asks for the address of another friend (sea level) or looking up the same address while sending an email message (fish level).

When designing an email client, you would have to figure out which of the two scenarios is the more likely one. For this one you should write the use case.
It does not make sense to repeat the same use case from the sea level on fish level, obviously.
Still the fish level use case should be a considered scenario when designing the software - otherwise you would lose the possibility to look up an email address without having to write an email message...
I guess, I would try to cope with this in the use case's trigger. Other ideas?

Vor einiger Zeit hatte ich eine interessante Diskussion mit einem Senior-Entwickler.
Muss ein Use-Case "Login" auf Anwenderzielebene aufgeführt werden?

Ich hatte in etwa folgende Use-Cases aufgestellt:


Der Kollege argumentierte, ein für ihn relevanter, weil den Aufwand stark beeinflussener Use-Case fehlt: Login

Auf der einen Seite verbietet es die "reine" Lehre, z. B. nach Alistair Cockburn (z. B. in diesem Artikel) oder gemäß dem Kaffeepausen-Test, Use-Cases auf Systemebene mit denen der Anwenderebene zu mischen.
Mein Entwickler will auf der anderen Seite die wichtigen Kostentreiber auf einen Blick erkennen können.

Heute schreibe ich pragmatisch einen Use-Case "Login", mische die Ebenen und behelfe mir mit der Ausreden, dass ich es bewusst tue.

Bessere Ideen?

How important is the text of an application, for example in a dialogue box, for the usability and therefore the success of the application?
Enormously!
This fact is often beeing underestimated.
Often the text is written by programmers "along the way" while programming the functionality.

In her article "Dialogue boxes making simple things simple", Leisa Reichelt points out a nice example of a bad dialogue box text.
I think, everybody has seen bad examples of dialogue boxes like this one.

From the point of view of a software company, I have made similar experiences during application development - dialogue box texts completely not helpful to the user.
Luckily, I am in charge of improving this :-)
That's why we started to specify dialog boxes including texts before the get programmed. Wireframes also include dialogue boxes that are called from them.
I also like to ask if the dialogue box is necessary at all. Every dialogue box forces the user to think about something he may not be aware of.
Instead, we want the application to support the user thinking in his way.

An interesting thought though - what to do with experienced users? Scott Sehlhorst puts up some ideas about beginners and experts and the Canyon of Pain.

In seinem Blog schreibt Rolf Götz über nicht-funktionale Anforderungen und die Abstraktionseben der Spezifikation ("Nonfunctional requirements and level of specification").
Zentrale Aussage des Artikels: "The higher the level of a system's requirements specification, the greater the portion of non-functional requirements."

Interessanterweise kann sich das ändern, wenn man einen anderen Scope betrachtet.
Für die Webapplikation Online-Shop ist z. B. die Conversion Rate, also die Zahl der Bestellungen je Besucher, eine nicht-funktionale Anforderung. Sie wird gemäß Rolfs Regel in konkreteren Spezifikationen durch einen Mix aus funktionalen und nicht-funktionalen Anforderungen detailliert.
Aus Sicht des Unternehmens ist die Conversion Rate jedoch die wesentliche Funktion der Applikation, Besucher zu einem Abschluss zu bewegen, also eine funktionale Anforderung.

Wikipedia definiert "Usability" als "Gebrauchstauglichkeit" in der Gesamtbetrachtung einer Software. Dies beinhaltet funktionale und nicht-funktionale Aspekte.
Klassische Software-Ingenieure kennen als "Usability" die nicht-funktionale Anforderung, die Wikipedia im Artikel über "Software Ergonomie" als die nicht-funktionale Eigenschaft einer Software definiert, wie die vorhandenen Funktionen genutzt werden können.