Dabei ist es notwendig, mögliche Sichtweisen des Softwareentwicklers zunächst zu vernachlässigen und der Benutzersicht unterzuordnen, um nicht zu früh Entscheidungen zu treffen, die später die Implementierung einschränken oder sogar behindern oder im schlimmsten Fall zu schweren Entwurfsfehlern führen können, deren Behebung äußerst unangenehm und zeitraubend werden kann.
Nur auf der Basis solider Kosten-Nutzen-Analysen, Erfahrung in der Konstruktion oder bei der Benutzung von Werkzeugen für Softwareentwicklung und genauer Untersuchungen des Benutzungsprofils sind schon zu diesem Zeitpunkt einschränkende Annahmen zulässig. Da das in einem Lehrprojekt von den Teilnehmern nicht erwartet werden kann, gehört die Einplanung unumgänglicher Einschränkungen zu den Aufgaben der Projektleitung: sie muß entsprechende Überlegungen im Zuge der Untersuchung geeigneter Themenstellungen - ggf. unter didaktischen Gesichtspunkten - vornehmen und dafür sorgen, daß sie bei der Aufgabenstellung berücksichtigt werden.
Das übergeordnete Lernziel in der Anforderungsdefinition ist die Einsicht darin, daß eine sorgfältige Gestaltung der Benutzeroberfläche für alle weiteren Phasen unumgänglich ist: nur Genauigkeit und Vollständigkeit der Arbeit kann sicherstellen, daß unmißverständliche und brauchbare Grundlagen für den Entwurf und die Realisierungsentscheidungen gelegt werden.
Die Benutzeroberfläche ist durch die Gesamtheit aller Interaktionen zwischen Benutzern (und den von ihm eingesetzten Geräten) und dem automatisierten System gegeben; zu ihrer Gestaltung gehört die Beschreibung
Die genannten Punkte sind weitgehend unabhängig voneinander zu klären: beispielsweise hängt die Repräsentation der Daten auf dem Bildschirm nicht von der Frage ab, ob das System lediglich durch die Tastatur bedient oder ob auch eine Maus eingesetzt wird; die Systemsteuerung mittels der Tastatur hat nichts mit den Formaten der Daten auf dem Bildschirm, auf dem Papier oder auf peripheren Speichern zu tun.
Bei der Gestaltung der Interaktion zwischen Mensch und Maschine müssen sich die Teilnehmer in die Vorstellungen und Gewohnheiten der vorgesehenen Benutzer eindenken, weil sonst die Akzeptanz des Systems nicht gewährleistet ist oder sogar die Gefahr besteht, ein unbrauchbares System zu konstruieren. Dazu gehört die beispielhafte Erörterung ergonomischer Fragestellungen.
Die detaillierten Überlegungen dazu, wie sich das geplante System den Benutzern darstellen soll, sind in der Regel mühselig und zeitaufwendig; sie werden häufig kontrovers diskutiert und ihre Notwendigkeit wird zu Beginn der Arbeit nicht immer eingesehen. Sie liefern aber einen natürlichen Einstieg in die Entwurfsarbeit, weil sich aus der Sachanalyse in Verbindung mit der Konstruktion der Benutzeroberfläche eine klare Gliederung der im System betrachteten Objekte ableiten läßt. Damit ergibt sich, wie später gezeigt wird, die für den Anfänger erfahrungsgemäß schwierige Frage nach der Zerlegung des Systems in beherrschbare Teile auf eine naheliegende Weise.
Alle Entscheidungen dürfen nicht nur in den Köpfen einzelner Projektmitarbeitern stecken, sondern müssen als nachvollziehbare, widerspruchs- und zweifelsfreie Arbeitsgrundlagen schriftlich niedergelegt werden, denn implizites Wissen hat zwingend Inkonsistenzen in der weiteren Arbeit zur Folge und gefährdet den Erfolg des Projekts.
Die zentrale Bedeutung der phasenbegleitenden Dokumentation der Arbeitsergebnisse kann deshalb für die weitere Arbeit nicht hoch genug eingeschätzt werden. (Eine gute Systementwicklungsdokumentation wird besonders von denjenigen Personen geschätzt, die ein System oder Teile davon weiterentwickeln wollen, obwohl sie an deren Erstellung nicht beteiligt waren.)
Letztlich kann die Frage nach der Widerspruchsfreiheit und Vollständigkeit der Ergebnisse dieser Phase des Softwarelebenszyklus relativ zur vorigen - der Systemanalyse/Themenstellung - letztlich nur ein Vergleich der Anforderungsdefinition mit dem Verhalten des entwickelten Systems beantworten. Manche Mängel der Anforderungsdefinition zeigen sich erst beim Gebrauch des fertigen Systems, also nach vollständigem Durchlaufen des Softwarelebenszyklus. Dabei beobachtete Fehler lassen sich nur unter Rückgriff auf frühere Phasen beseitigen; im ungünstigsten Fall zeigen genauere Analysen, daß die Anforderungsdefinition nicht in allen Punkten problemadäquat war:
Es ist unabdingbar notwendig, daß alle Teilnehmer über eine gründliche Detailkenntnis der gesamten bisherigen Dokumentation verfügen: es zeigt sich bei Lehrprojekten immer wieder, daß in den anschließenden Phasen plötzlich eigene Wege verfolgt werden, die nicht den Festlegungen der Anforderungsdefinition entsprechen. Alle späteren Ideen über Unvollständigkeiten, Widersprüche oder Fehler und alle Vorstellungen über inhaltliche Änderungen sind festzuhalten; die Diskussion wird nach der Fertigstellung des Systems wieder aufgenommen, um die zwischenzeitlich gewonnenen Erkenntnisse mit dem Ziel der Weiterentwicklung des Prototyps in einem ansatzweisen erneuten Durchlaufen des Softwarelebenszyklus in die gemeinsame Arbeit einzubringen.
Wenn aufgrund der Kompliziertheit der Bedienung des Systems ein Benutzerhandbuch notwendig ist, werden die Arbeitsergebnisse für dessen Erstellung genutzt.
Als Orientierungshilfe zur Gestaltung von Benutzeroberflächen (auch "Mensch-Maschine-Schnittstellen" genannt) seien einige Fragen aus [NV] zitiert, die "die meisten Schwierigkeiten der Benutzer interaktiver Programme gut kennzeichnen":