In agilen Software-Entwicklungsmethoden, wie SCRUM oder XP, wird häufig empfohlen, das zuerst zu tun, bei dem genau klar ist, was zu tun ist.
Das klingt zunächst gut, da dann sichergestellt ist, dass alle Ihre Aufgabe genau kennen und die Umsetzbarkeit und Umsetzungsaufwand abschätzen können.

Konsequenz dieses Vorgehens ist jedoch, dass die vage und unpräzise formulierten Anforderungen bzw. die Anforderungen, bei denen das genaue Ziel noch unklar ist, unterpriorisiert werden.
Einerseits mag in den Anforderungen, bei denen selbst der Anforderer nicht genau weiss, was er will, kein großes Gewicht liegen. Wenn der Anforderer nicht genau weiss, was er will, lässt er sich ggf. auch schneller davon überzeugen, dass er die Umsetzung dieser schwammig formulierten Anforderung vielleicht gar nicht braucht.
So wird für dieses Vorgehen gerne damit geworben, dass über eine solche Priorisierung die Anforderungen mit dem höchsten Nutzen zuerst implementiert werden. Am Ende eines Projektes bleiben dann nur noch Anforderungen mit hohem Aufwand aber vergleichsweise niedrigem Nutzen zurück, die notfalls auch komplett fallengelassen werden können.

Dieser Sichtweise steht aber die Behandlung besonders komplexer Anforderungen gegenüber. Dies sind diejenigen, die zu Beginn eines Projektes niemand so genau beschreiben kann. Bei diesen Anforderungen wäre zunächst weitere Planungszeit nötig, um sie präziser zu formulieren und in kleinere Teilanforderungen zu zerschneiden.
Andererseits ist bei unverstandenen Anforderungen der Nutzen zunächst noch unklar. Zumindest besteht zunächst die Wahrnehmung, dass der Aufwand zur Lösung den (noch unbekannten) Nutzen deutlich übersteigt.
Wenn sich in einer dieser komplexen Anforderungen jedoch ein simple Lösung mit hohem Nutzen verbirgt, ist es es wert, die zusätzlich erforderliche Zeit einzuplanen, um die Anforderung besser zu verstehen. Einer solchen Anforderung (würde man sie denn trotz ihrer Komplexität erkennen) sollte Priorität eingeräumt werden.

Wir schlussfolgern daraus:
Werden nur die klar verstandenen Anforderungen hoch priorisiert, läuft man Gefahr, Zeit zu verlieren, die derzeit unverstandenen, komplexen Anforderungen mit (relativ zum Aufwand) hohem Nutzen zu identifieren und somit auch umzusetzen. Mit diesem Vorgehen kann man sogar relativ sicher sein, dass diese Anforderungen überhaupt nicht umgesetzt werden, da der Anforderungsanalyse dafür nie ausreichend Zeit eingeräumt wird.

In Kürze: Komplexe Anforderungen müssen keine unwirtschaftlichen Anforderungen sein.