Bei der Überprüfung der Anforderungsspezifikation (einschließlich funktionaler, nichtfunktionaler Anforderungen, Einschränkungen usw.), egal wie klein oder groß sie ist, sind es die "Todsünden", auf die die Autoren achten müssen?
Bitte listen Sie nicht mehr als 7 wesentliche Dinge auf (in der Reihenfolge der abnehmenden Schwere), die in der Anforderungsspezifikation gemacht (oder nicht getan) haben nachteilige Auswirkungen auf die Qualität des Softwareprodukts. Weniger als 7 ist vollkommen in Ordnung.
OK, das ist mehr als 7, aber gute Anforderungen haben die folgenden Attribute:
Ein anständiges Anforderungsverfolgungstool kann einige der oben genannten Funktionen wie identifizierbar, priorisiert, kategorisiert automatisieren / durchsetzen, aber nur eine Überprüfung durch das Team kann den Rest überprüfen. Der Schlüssel liegt darin, Ihr Team hinsichtlich dieser Attribute zu schulen, indem Sie sowohl gute als auch schlechte Beispiele von Anforderungen lesen und einen effizienten Überprüfungsprozess einrichten, der die Anforderungen früh genug in Ihrem Lebenszyklus überprüft, um Auswirkungen auf die nachgelagerten Aktivitäten zu haben / p>
Features, Zeit, Qualität - wählen Sie zwei. Stellen Sie sicher, dass die Anforderungen nicht alle drei auf Ihr Team anwenden.
Schieben Sie Anforderungen zurück, die versuchen, Ihren Prozess zu steuern.
Fordern Sie von Anfang an eine klare Priorisierung an.
Bestehen Sie auf klare Annahmekriterien für jede Anforderung.
Die Anforderungen müssen spezifisch und eindeutig sein im Hinblick darauf, was benötigt wird, aber weniger darauf, wie die Anforderungen zu erfüllen sind.
Das Schlimmste, das ich in einem Projekt gesehen habe, für das ich codiert habe: -
%Vor%Erstens ist eine Anforderung mit "wie erforderlich" darin dumm. Diese eine Zeile muss 400.000 $ gekostet haben. Der Kunde zeigte darauf und sagte, dass es dort steht, dass du bla, bla, bla tun wirst.
Mehrdeutige Anforderungen sind schlecht.
Unüberprüfbare und nicht quantifizierbare Anforderungen verdoppeln sich.
Natürlich hängt alles davon ab, welche Art von Anforderung Sie erhalten. Ich bin typische Gui oder Web-Anwendung, Batch-Prozesse und
gewohntIch habe auch einen einzigen Ratschlag für den Reviewer: kenne dein Thema
Sie müssen sehr genaue Kenntnisse über den Kontext der Anforderung, den spezifischen Kundenbedarf, die technische Umgebung und vielleicht die wichtigsten Personen haben, an die diese Anforderung gestellt wird und welche Ebene des globalen Verständnisses sie haben.
Ich habe sehr schlechte Erfahrungen in Projekten mit vielen Leuten gemacht, die die Spezifikationen überprüft haben, da ihr individuelles Wissen sehr oberflächlich war. Sie erhalten das Feedback auf der gleichen Ebene, meist formale Korrekturen, aber die tiefgehenden Mängel der Spezifikation werden erst sehr spät im Projekt entdeckt.
Meine Empfehlung und was ich vor einem neuen Projekt immer mache ist die Checkliste zu überprüfen Seite 42,43 von Steve McConnells Code Complete
Die allwissende Wikpedia hat eine gute Zusammenfassung für die Anforderungen Ссылка . Ich würde sagen, dass unter diesen Punkten die fehlende Überprüfbarkeit am häufigsten vorkommt. Das große Ganze zu verstehen ist wichtig im Leben, aber Sie müssen Dinge explizit in Ihren Anforderungen formulieren, z. Das System soll schnell reagieren. Stattdessen muss das System auf alle Anfragen in weniger als 2 Sekunden reagieren.
Sie könnten einige Anforderungsmanagement und CMMI Dokumente.
Besuchen Sie auch die Anforderungscheckliste und googlen Sie nach "Kriterien für gute Anforderungen".
Diese wurden speziell entwickelt, um Prozesse zu erstellen, die bei der Softwareentwicklung helfen.
Tags und Links qa project-management specifications review