Die Norm EN
ISO 9000:2005, in der Grundlagen und Begriffe zu Qualitätsmanagementsystemen definiert
werden, beschreibt Qualität als „Grad, in dem ein Satz inhärenter Merkmale
Anforderungen erfüllt“.
Aus dieser
Definition folgt einerseits, dass es Anforderungen geben muss. Im Idealfall sind Anforderungen mit einem Produktverantwortlichen vereinbart und widerspruchsfrei beschrieben. Man spricht dann von expliziten Anforderungen. Sind die Anforderungen an bestimmte Produkteigenschaften nicht explizit festgelegt sind sie nicht automatisch irrelevant sondern sie werden zu impliziten Anforderungen, mit anderen Worten gängigen Erwartungen an diese Eigenschaften.
Die nächste
wichtige Schlussfolgerung aus dieser Definition ist, dass die Qualität eines
Produkts dadurch ermittelt werden kann, dass man den Erfüllungsgrad der Anforderungen durch die Produkteigenschaften misst. Im Fall expliziter Anforderungen ist dies meist einfach. Bei impliziten Anforderungen kann lediglich die Einschätzung eines Testers abgefragt werden, ob nach seinem individuellen Empfinden die gängige Erwartung an eine Produkteigenschaft erfüllt ist.
Die
daraus abgeleiteten Empfehlungen für die Praxis der Softwareentwicklung sind:
- Anforderungen sind möglichst explizit und präzise, wenn möglich quantitativ zu beschreiben. Quantitative Festlegungen lassen sich durch Messungen widerspruchsfrei verifizieren und sind daher textuellen Beschreibungen vorzuziehen.
- Implizite Anforderungen sind zu vermeiden, da dadurch Qualitätsprüfungen von der individuellen Einschätzung der Tester abhängig werden. Sie lassen sich nur dadurch vermeiden, dass die Anforderungen explizit beschrieben werden.
Dieser Kommentar wurde vom Autor entfernt.
AntwortenLöschenHallo Stefan!
AntwortenLöschenThis is interesting but how does this approach to quality function in an Agile environment?
If we accept that product definition must evolve to suit changing circumstances, or a changing understanding of circumstance, how then to identify and quantify quality and, ultimately, success?
Hi Colin,
AntwortenLöschenyou may compare requirements with a target line. How can anybody reach the goal if he/she does not know where the target line is.
I do not see discrepancies to agile development because finally the goal of each sprint is to implement the selected requirements of the backlog, i.e. the quality of the release (the success in terms of meeting the expectations of a customer or product owner) can be measured as the degree how these requirements have been fulfilled.
Of course quality as well as the customer expectation is a temporary condition. If due to changing circumstances new or changed requirements have to be considered, this simply moves the target line.