Die Anforderungsbestimmung umfaßt drei Schritte:
Bei der Ermittlung der Anforderungen geht es darum, in Zusammenarbeit zwischen Anwendern und Projektteam zu ermitteln, was für Eigenschaften des Softwaresystems die Anwender benötigen. Dieser Aspekt ist der bei weitem schwierigste und wird in diesem Kapitel im Mittelpunkt stehen. Für die Ermittlung der Anforderungen gibt es eine Reihe von teil- oder vollstrukturierten Techniken, wie Bereichsexperten (domain experts), sprich Anwender, und technische Experten (Softwareingenieure) ein gemeinsames Verständnis der Anforderungen erarbeiten können. Die Verfahren werden um so komplizierter, je mehr verschiedene Teilbereiche von verschiedenen Bereichsexperten abgedeckt werden müssen und je weiter das Anwendungsfeld vom Verständnishorizont der Softwareingenieure oder die technische Systemrealisierung vom Verständnishorizont der Anwender entfernt liegt.
Für die Beschreibung der Anforderungen ist einerseits die Menge der möglichen Notationen von Interesse, aus der einige Beispiele in der Vorlesung ,,Softwaretechnik`` behandelt wurden, sowie andererseits die Menge der Konventionen für die Verwendung der Notation. Auf das letztere Problem wird hier nur sehr am Rande eingegangen.
Die Analyse der Anforderungen, soweit sie noch vor der Entwurfsphase vorgenommen wird, dient zur Qualitäts- und Plausibilitätsprüfung der Arbeitsergebnisse der Anforderungsbestimmung. Schwächen des Anforderungskatalogs, die hierbei aufgedeckt werden, müssen in einer Nachbearbeitungsphase aufgeklärt werden.
Vielfach wird der Begriff des requirements engineering in Zusammenhängen benutzt, in denen die Beschreibung und die Analyse im Mittelpunkt stehen. Das Kernproblem ist aber eigentlich die Ermittlung. Es ist jedoch zutreffend, daß sich viele Schwierigkeiten bei der Ermittlung beseitigen ließen, wenn man bessere Beschreibungsmittel zur Kommunikation zwischen Anwender und Entwickler hätte. Sinnvollerweise durchläuft man alle drei Schritte ohnehin zyklisch und mit Rückkopplung, da bei der Beschreibung und Analyse Fragen auftauchen, die in die Ermittlung eingehen müssen oder bei ihr hilfreich sind.
In unterschiedlichen Arten von Softwareprojekten stellen sich auch die Probleme der Anforderungsbestimmung verschieden dar. Generell wird die Anforderungsbestimmung um so schwieriger, je tiefer das zu gestaltende Softwaresystem in das Leben und die Arbeit der betroffenen Anwender eingreift.
Der schwierigste Fall sind deshalb normalerweise betriebliche Informationssysteme, die oft zentrale Faktoren des Arbeitslebens vieler Anwender darstellen. Hier wird erstens die Anforderungsbestimmung dadurch erschwert, daß das Softwaresystem nicht isoliert betrachtet werden darf, sondern im Zusammenhang des Gesamtsystems gesehen werden muß, das die gesamte Firma und ihre Wirtschaftstätigkeit umfaßt. In diesen Fällen sind zweitens auch Interessenkonflikte besonders häufig und zugleich besonders schwierig aufzulösen. Drittens tritt bei diesen Systemen die größte Verständniskluft zwischen Anwendern und Softwareteam auf.
Ähnlich problematische Fälle, wenn auch aus teilweise etwas anderen Gründen, sind alle Arten von Benutzerschnittstellen. Hier schwanken Erfahrungshintergründe der Benutzer und Anwendungskontext oft besonders stark. Wenn es um Massensoftware geht, wie beispielsweise ein Textverarbeitungsprogramm, ist es oft sehr schwierig, an die nötigen Informationen zu gelangen, um die Anforderungen optimal zu bestimmen, weil nicht genügend viele genügend verschiedene Anwender zugänglich sind. Außerdem spielen bei Benutzerschnittstellen kognitionspsychologische Phänomene eine große Rolle. Da die Benutzbarkeit von Software zu einem großen Teil von der Gestaltung der Benutzerschnittstelle abhängt, ist dies ein wichtiges Teilproblem der Anforderungsbestimmung in fast allen Anwendungsbereichen. Die Konstruktion von Benutzerschnittstellen ist jedoch eine eigene Disziplin, die deshalb hier in der Betrachtung ausgespart wird.
Oftmals etwas einfacher ist Software für technische Anwendungen, wie beispielsweise Konstruktionssysteme. Hier sind die Anwender häufig mit mehr Verständnis für Datenverarbeitung ausgestattet und können dementsprechend leichter mit einem Softwareteam kommunizieren. Auch hier gibt es aber Unterschiede, je nach konkretem Anwendungsgebiet.
Nochmals einfacher sind zumeist Steuerungssysteme und ähnliches, weil dort die Anforderungen zumeist durch technische Randbedingungen sehr viel enger vorgegeben sind als in den prinzipiell extrem flexiblen Umgebungen, in denen nur Menschen arbeiten. Eine Herausforderung besteht hier (wie auch auf allen anderen Anwendungsgebieten) darin, gänzlich neue Anwendungsarten von Software herauszufinden und zu beschreiben. Ein Beispiel hierfür ist die Realisierung eines Gasventils mit stufenlos wählbarer Durchflußmenge durch ein (wesentlich billigeres) binäres Gasventil plus Software.
Mit diesem Beispiel sind wir auch schon in der verwandten Kategorie ,,eingebettete Software`` (embedded systems). Hier ist die Software gar nicht mehr separat sichtbar sondern verschwindet als ein Funktionsbestandteil in einem technischen System, beispielsweise obigem Ventil oder der Steuerung einer Waschmaschine, eines Fernsehgeräts, eines Antiblockiersystems oder einer Uhr. Die Anforderungen werden hierbei noch enger von Randbedingungen bestimmt als bei Steuerungssoftware für größere Systeme und sind dementsprechend leichter zu bestimmen. Ausnahmen bilden die zahlreichen Fälle, in denen Benutzerschnittstellen gestaltet werden müssen, wie bei Waschmaschine und Fernseher.
Mit sinkender Schwierigkeit der Anforderungsbestimmung steigen üblicherweise zugleich die Anforderungen an die Zuverlässigkeit der Software. Der Grund für beide Tendenzen ist der gleiche: starke direkte Beteiligung von Menschen an der Benutzung der Software. Wo der Mensch eng ins System verflochten ist, sind die Anforderungen zwar schwer zu bestimmen, dafür können Fehler des Systems eher toleriert werden, weil der Mensch als Kontrollinstanz Probleme ausgleichen kann. Umgekehrt versteht man recht leicht, was ein Antiblockiersystem tun soll, aber wehe, wenn es nicht korrekt funktioniert.