RE

[vit_r]

juristisch gesehen, sind die Requirements eine Grundlage für einen Vertrag.
Die Kunden wollen ein Lastenheft nicht detailliert Beschreiben, weil sie auf dieser Weise auf unentgeltlichen Änderungen der Anforderungen und auf "selbstverständliche" Forderungen für "vergessene" Leistungen verzichten müssen.
Die Entwickler wollen ein Pflichtenheft nicht detailliert Beschreiben, weil sie dann keine Möglichkeit haben werden, die Leistungen mangelhaft zu liefern. Und man muss auch nicht vergessen, dass nicht preziese Anforderungen immer die niedrigere Kostenschätzung produzieren, wass immer Konkurenzvorteile bringt.

Comments

[vit-r.livejournal.com]

Die Requirements schreibt man für die Leute, darum ist die Qualität der Anforderungen schwer zu messen. Mann kann auch die Gedichte mit verschiedenen Statistiken bewerten. Das könnte einige interessant Ideen bringen oder einige Theorien beweisen.

Es gibt viele Forschungsarbeiten (Sie können z.B. auf der Seiten von Hood-Group etwas finden.) Die meisten von Metriken fordern die Anforderungen ausführlich und formal zu Schreiben. Meine Erfahrung zeigt aber, dass die langen Texten von Menschen nicht gelesen werden. Die formale Sprache ist auch nur von Wissenschaftlern beliebt.

Ich mache zur Zeit QA für ein Web-Projekt. Die Anforderungen sind nicht formal. Es gibt Teile der Spezifikation, die elektronisch nicht gefasst sind. Aber wenn die Leute wissen, was zu machen ist, kann ich damit leben.

Ich messe nur die Anzahl von Open Points und Change Requests für bestimmte Use Cases und Gruppen von nichtfunktionalen Anforderungen. Zusätzlich kann ich in Ticket-System die Anzahl von Bugs in Software sehen.
So kann ich beurteilen, ob die Situation sich verbessert, oder ob wir unser Ziel nicht besonders gut vorstellen. Es ist auch klar, wo es wirklich brennt.