Auf die Analyse zuvor ermittelter Anforderungen will ich hier nur kurz eingehen. Die Analyse der Anforderungen dient, wie schon gesagt, zur Qualitäts- und Plausibilitätsprüfung des Anforderungskatalogs. Sie ist ein wichtiges Hilfsmittel auch für die Anforderungsbestimmung, weil Lücken und Widersprüche, die bei der Analyse gefunden werden, die Aufmerksamkeit bei der Bestimmung auf diejenigen Aspekte lenken, wo sie am meisten gebraucht wird. An Anforderungen und ihre Dokumentation gibt es folgende Qualitätsanforderungen:
Zur Prüfung dieser Qualitätsanforderungen können hauptsächlich zwei allgemeine Methoden eingesetzt werden: Konsistenzprüfung und Vollständigkeitsprüfung. Bei der Konsistenzprüfung wird die erstellte Spezifikation auf innere Widersprüche untersucht, was zumindest bei Verwendung formaler Spezifikationssprachen oft relativ leicht möglich ist. Bei der Vollständigkeitsprüfung wird versucht festzustellen, ob alle Anforderungen auch erfaßt sind. Diese Prüfung ist natürlich nicht vollständig möglich; also wird z.B. untersucht, ob Fallunterscheidungen mit erkennbarer Fallmenge vollständig sind und ob alle Teile der Spezifikation, die an anderer Stelle benutzt werden, auch definiert sind. Beim Einsatz formaler Spezifikationsmethoden können beide Prüfungen teilweise automatisiert werden, was ihren Aufwand vermindert und ihre Zuverlässigkeit erhöht.
Die anderen Qualitätsmerkmale können nicht so einfach geprüft werden, jedoch gibt es auch für sie zum Teil Möglichkeiten, ihre Einhaltung besser sicherzustellen: Die Rückverfolgbarkeit kann mit Hilfe von entsprechenden Werkzeugen hergestellt werden, die die Entstehungsgeschichte einer Anforderung während der Anforderungsbestimmung aufzuzeichnen gestatten. Wenn solche Werkzeuge auch Querbezüge zwischen den Anforderungen aufzeichnen können, läßt sich auch die Modifizierbarkeit verbessern, weil das Werkzeug das Mitändern oder Neuüberprüfen anderer Anforderungen zwar nicht unnötig macht, aber zumindest seine Durchführung erleichtert.
Die Eindeutigkeit von Anforderungen wird zum Teil überprüft, wenn man sie in eine formale mathematische Notation überführt. Allerdings ist die Eindeutigkeitsprüfung von sprachlich formulierten Anforderungen zur Zeit noch in jedem Fall etwas, das nur ein Mensch machen kann und deshalb selbst dann fehleranfällig: wenn beim Überführen in formale Notation eine Mehrdeutigkeit nicht erkannt wird, sondern eine der möglichen Interpretationen ausgewählt wird, kann trotz späterer formaler Beschreibung ein Mißverständnis entstanden sein. Die Eindeutigkeit umfaßt auch, daß auch der Kunde die Anforderung, in der Form wie sie im Pflichtenheft auftaucht, wirklich verstanden hat. Bei entsprechender Sorgfalt bei der Anforderungsbestimmung kann das normalerweise immer geprüft bzw. sichergestellt werden, aber diese Sorgfalt ist extrem kritisch für den Erfolg eines Projekts: Eine Schlamperei in diesem Punkt wird nämlich oftmals erst viel zu spät, z.B. bei der Abnahme eines Systems entdeckt. Für Software, die nicht für spezifisch vorhandene Kunden, sondern für einen Markt von vielen Kunden entwickelt wird, ist dieser Aspekt nur scheinbar ohne Bedeutung. Aber auch hier wird ja die Anforderungsbestimmung aufgrund von Befragungen potentieller Kunden erstellt, und ein Fehlverständnis von deren Wünschen kann den Markterfolg des Produkts zunichte machen.
Die Realisierbarkeit wie auch die Nachprüfbarkeit und die Einschätzbarkeit lassen sich kaum maschinell prüfen. Hierzu sind immer noch Wissen, Erfahrung, Gefühl und Überschlagsrechnungen die Mittel der Wahl.