Requirement: Klar und testbar!

Transkript

1 Requirement: Klar und testbar! Definitionen, Merkmale, Beispiele Lukas Kraus, Lead QA Engineer bbv Software Services Corp. 1

2 Ich geh mal fragen was die wollen, und ihr beginnt schon mal zu codieren!!! bbv Software Services Corp. 2 Intro

3 Agenda Definitionen & Beschreibungen Requirements und ihre Stakeholder Merkmale eines guten Requirement Requirements Beispiele Lessons learned bbv Software Services Corp. 3 Requirement: klar und testbar! / Agenda

4 Definition In der (Software-)Technik ist eine Anforderung (engl. requirement) eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, Systems oder Prozesses. Anforderungen werden üblicherweise in einem Pflichtenheft zusammengefasst. (wikipedia.de) bbv Software Services Corp. 4 Definition & Beschreibung

5 Beschreibung Ein testbares Requirement muss so weit aufgeschlüsselt werden, bis es präzise und eindeutig genug ist und nicht mehr weiter aufgebrochen werden kann. Dies trifft nur zu, wenn ein Testfall erstellt werden kann, der die korrekte Implementation des Requirements validiert. bbv Software Services Corp. 5 Definition & Beschreibung

6 Requirement & Stakeholder Kunden Projektleiter (SW-Projektleiter) Software Entwickler Tester System Support (Maintenance) bbv Software Services Corp. 6 Requirements & Stakeholder

7 Requirement & Stakeholder Kunde Projektverlauf Projektleiter SW Entwickler Tester System Support bbv Software Services Corp. 7 Requirements & Stakeholder

8 Merkmale nach IEEE 830 Genau Jedes SRQ repräsentiert eine Eigenschaft oder zu erbringende Leistung der Software. Eindeutig Jedes SRQ lässt nur eine Auslegung zu. Vollständig Alle Eigenschaften sind definiert und enthalten. bbv Software Services Corp. 8 Merkmale eines guten Requirements nach IEEE

9 Merkmale nach IEEE 830 Widerspruchsfrei Kein SRQ stellt einen Widerspruch zu anderen SRQ s oder Dokumenten. Nachprüf- / weisbar Es muss nachgewiesen werden können, dass die Implementation dem SRQ entspricht. Modifizierbar Struktur des Dokuments ermöglicht einfache und schnelle Anpassung. bbv Software Services Corp. 9 Merkmale eines guten Requirements nach IEEE

10 Merkmale nach IEEE 830 Nachvollziehbar Jedes SRQ besitzt eine eindeutige Identifizierung und referenziert Produkt- und Subsystem Spezifikation. bbv Software Services Corp. 10 Merkmale eines guten Requirements nach IEEE

11 Schlechtes Beispiel SRQ1 The Instrument shall provide the capability for authorized users to create, edit and load files. Ist das vollständig? Ist das eindeutig? Ist das so testbar? bbv Software Services Corp. 11 Negative & positive Beispiele

12 Aufgebrochen und detailliert. SRQ1.1 The instrument shall provide the capability for the administrator (Chapter 4: User access rights) to load, edit and create test definition files (Chapter 8: test definition file) Definition pro User notwendig! bbv Software Services Corp. 12 Negative & positive Beispiele

13 Oder mit Hilfe einer Tabelle SRQ1 The Instrument shall provide the capability for authorized users to create, edit and load test definition files as defined in the table. create edit load Admin X X X Super User X X instrument Operator X X Lab Staff X bbv Software Services Corp. 13 Negative & positive Beispiele

14 Was fehlt hier? SRQ2 The Instrument shall be capable of detecting if a reagent cassette does not have sufficient volume for the scheduled Run and automatically switch to the alternate reagent cassette and continue. Genau/eindeutig nachweisbar? bbv Software Services Corp. 14 Negative & positive Beispiele

15 Alternativen/Ergänzungen Use Cases Screen Books Flow Charts State Event Diagramm Interaktionsdiagramm bbv Software Services Corp. 15 Negative & positive Beispiele

16 Was heisst das nun für den Testmanager? Überprüfen der Requirements Testbarkeit Vollständigkeit Durch Organisation von Reviews Wo sie als Moderator auftreten bbv Software Services Corp. 16

17 Lessons learned Genug Zeit planen zur Erstellung der Requirements Übersichtliche Struktur des Requirement Dok. Zusätzliche Illustrationsmöglichkeiten nutzen Frühzeitiges Einbinden der Stakeholder Einhalten der IEEE Richtlinien Prüfe den Einsatz von Tools Etablieren einer Review Kultur bbv Software Services Corp. 17 Lessons learned / take home message

18 Checklist item Premature design Combined requirements Description Does the requirement include premature design or implementation information? Does the description of a requirement describe a single requirement or could it be broken down into several different requirements? Unnecessary requirements Use of non-standard hardware Conformance with business goals Requirements ambiguity Is the requirement gold plating? That is, is the requirement a cosmetic addition to the system, which is not really necessary? Does the requirement mean that non-standard hardware or software must be used? To make this decision, you need to know the computer platform requirements. Is the requirement consistent with the business goals defined in the introduction to the requirements document? Is the requirement ambiguous i.e. could different people read it in different ways? What are the possible interpretations of the requirement? Ambiguity is not necessarily a bad thing as it allows system designers some freedom. However, it has to be removed at some stage in the development process. Requirements realism Requirements testability Is the requirement realistic given the technology, which will be used to implement the system? Is the requirement testable, that is, is it stated in such a way that test engineers can derive a test that can show if the system meets that requirement? bbv Software Services Corp. 18 Checkliste

19 Fragen / Diskussion bbv Software Services Corp. 19