Es wird davon abgeraten, Änderungswünsche nur aus Sicht des Managements zu formulieren, ohne ausgewählte Benutzer (Keyuser) der betroffenen IT-Systeme einzubeziehen. Keyuser müssen in direktem Kontakt mit BenutzerInnen stehen, die die bestellte Software täglich verwenden sollen.
Erstellung eines Lastenheftes mit den Zielen aus Kundensicht
Der Kundenwunsch aus Sicht des Auftraggebers kann anschließend mit Hilfe eines Spezialisten in ein Lastenheft ausgearbeitet werden, oder zumindest in Form einer losen Anforderungssammlung. Genauere, strukturierte Anforderungen im Lastenheft sind nur erforderlich, wenn es für eine Ausschreibung zur Bearbeitung an mehrere potentielle Auftraggeber verteilt wird. Das Lastenheft kann ein persönliches Gespräch zur Klärung von Detailfragen durch einen Requirements Engineer (AnalytikerIn) und durch ausgewählte Vertreter des Entwicklerteams des Auftragnehmers unterstützen, aber nicht ersetzen. Es kann z.B. die Vorbereitung der Abstimmung erleichtern. Die Ergebnissen der Abstimmung sollten anschließend eingearbeitet werden.
Die Abklärung von Anforderungen zur Angebotslegung durch einen Kundenbetreuer/in bzw. Verkäufer/in (z.B. Key Account Manager) gilt als "Antipattern", d.h. dieses Vorgehen hat sich in der Praxis nicht bewährt. Verkürztes Lastenheft wenn Pflichtenheft eingeplant wird
Das Lastenheft kann auf eine kurze fachliche Beschreibung der Kundenwünsche reduziert werden, wenn bereits ein Auftragnehmer fest steht und wenn mit Hilfe eines "Requirements Engineer" (AnalytikerIn) später ein Pflichtenheft und eine Dokumentation zu der gewünschten Applikation (IT-System) erarbeitet wird. Bei Bedarf kann die Erstellung der Dokumentation als eigener Auftrag erfolgen, z.B. wenn zusätzlich die bestehenden Geschäftsprozesse anzupassen sind. In diesem Fall wird zunächst ein Teil der benötigten Dokumentation erstellt und ausgeliefert, bis ein entsprechendes Angebot zur Umsetzung möglich ist. Weitere Details dazu liefert der Beitrag Pflichtenhefte und das Unified Model und für die agile Produktentwicklung der Beitrag agiles Management zur Produkt-Entwicklung.
Backlog statt Lastenheft für die agile Produkt-Entwicklung
Das beschriebene Vorgehen widerspricht teilweise den Vorgaben und Werten der agilen Produkt-Entwicklung, und kann vermieden werden, in dem die Problemstellung in einem vorbereiteten Sprint grob analysiert und in einem initialen Product-Backlog in Form von ersten grob skizzierten Epics und User Stories dokumentiert wird. Zur Vorbereitung kann auch in diesem Fall eine zuvor erwähne Anforderungssammlung verwendet werden. In der agilen Produkt-Entwicklung wird ein Entwicklungs-Team fix für einen Zeitraum "gemietet", über den der Product Owner die zuerst umsetzbaren Funktionalitäten nach entsprechender Vorbereitung selbst abschätzen und steuern kann - vgl. z.B. Scrum. Auf schwer handhabbare Fixpreis-Angebote kann in der Regel verzichtet werden.
Das agile Vorgehen vereinfacht die Erstellung des Lastenheftes, das auf eine valide Vision für das gewünschte Produkt, und wichtige, nicht funktionale Vorgaben mit Auswirkungen auf das spätere Lösungsdesign beschränkt werden kann. Dazu zählen z.B. Vorgaben, bestimmte Technologien und Standards zu berücksichtigen, und bestehende Schnittstellen zu nutzen.
Auf ein Pflichtenheft muss auch im Fall der agilen Projektabwicklung nicht verzichtet werden. Ansonsten entspricht das Product-Backlog dem Pflichtenheft, nach dem die zunächst grob skizzierten Epics und User Stories ausreichend detailliert wurden, um mit den ersten Sprints zu starten. Dieser Vergleich trifft jedoch nur bedingt zu, da ein klassisches Pflichtenheft alle vorgesehenen Funktionalitäten grob beschreiben sollte, um das Vorhaben als Ganzes auf Machbarkeit zu prüfen, ohne unnötig ins Detail zu gehen. Die Philosophie der agilen Vorgehensweise vermeidet jeden Aufwand, der für das erste Zwischenergebnis nicht unmittelbar erforderlich ist.
Das hilft z.B. unnötige Aufwände zu vermeiden, wenn sich später Planänderungen ergeben. In komplexen Domänen mit zahlreichen Abhängigkeiten kann dieses Vorgehen auch zu unangenehmen Überraschungen führen, die bei früherer Berücksichtigung unnötige Arbeit erspart hätten.