Die Pruefung sehr geradeaus, sehr an das Syllabus angelehnt. Die ersten 22 Fragen sehr einfach zu beantworten, "Negationen" sind mir nicht aufgefallen.
Nur selten hatte ich Schwierigkeiten, Fragen zu beantworten. Allerdings bin ich ziemlich suspect der Pruefung gegenueber gewesen, weil ich schon bei der ISTQB FL mir ziemlich sicher war, dass es gut gelaufen war; ich hatte doch auf etwa 95% richtige Antworten in den Mock Exams aus dem Internet, zwar waren die Fragen etwas anders in der wahren Pruefung, doch schwieriger kamen sie mir ueberhaupt nicht vor. Nun hatte ich aber "nur" 2 mehr richtig, als notwendig, und damit eigentlich die Pruefung mit "gerade ausreichend" bestanden. Man kann dazu bemerken, dass ich schon seit gut 12 Jahre bei der Qualitaetssicherung arbeite und vielleicht mehr auf Erfahrung als auf Wissen gesetzt habe. Ausserdem hatte ich schon auch bemerkt, dass die gleiche Frage in verschiedenen Mock Exams teils als falsch teils als richtig bewertet wurde. Nichtdestotrotz bin ich mit dem Ergebnis (meine Leistung) der ISTQB FL eher unzufrieden. Aus dieser Erfahrung heraus habe ich auch die REQB sehr "ordentlich" vorbereitet. Ausserdem gibt es im Internet gar keine Mock Exams fuer REQB und sonst keine Muster, so dass ich ganz und gar auf das Syllabus und anderen theoretischen Informationen mich verlassen musste. Dadurch bedingt habe ich auch die Fragen bei der Pruefung sehr genau gelesen.
Bei der Frage wo ich sehr unsicher war: Welche IEEE Norm gilt fuer die Spezifikation von System Funktionalitaet.
Nur unsicher war ich mir bei der Frage; wenn man dabei ist, einer "Solution Spec" zu schreiben, genauer "detailed high level req", und man hat schon das System definiert, die low-level req. spezifiziert, dokumentiert und aneinander in Relation gebracht u.s.w.; was macht man als Naechstes?
- REQ Analysis
- Solution modellieren
- Solution festlegen
Im letzten Teil der Pruefung jedoch, genauer REQ Analysis (auch "Tools" ganz am Ende mit nur 3 Fragen) ist mir aufgefallen, dass viele, viele Fragen mit Negationen behaftet waren, in der Art:
"Welche Aussage gilt NICHT fuer XY (wenn XZ) ?"
Da sollte man schon etwas genauer die richtige Antwort (die falsche) markieren.
Mehr als Definitionen von SysML und UML sollte man nicht wissen; OK, die Charakteristiken der beiden und die Unterschiede zwischen den beiden sollte man schon wissen.
Eine Frage war wohl; was fuer ein UML Diagramm man waehlen wuerde um die Stationen eines Dokuments in einem Document-Management-System darzustellen.
Das Gleiche ueber Agile Methoden... eine Frage gab es, dabei mussste man schon wissen was ein Backlog ist und was nicht.
Summa summarum: Meines Erachtens nach, wenn man erst das Syllabus durcharbeitet, (spricht auch die Fehler des Syllabus erkennen und beseitigen, dann das Richtige und Wichtige verstehen), dazu erstmals und zusaetzlich die Grundlagen von verwandten Themen wie UML (Modellierung) und Entwicklungsmethoden (Agile Methoden) durchlesen, dann hat man eine gute Basis, die Pruefung zu schaffen.
Hier kann man neine eigene Ueberarbeitung des Syllabus runterladen: Ich hatte die englische Version bearbeitet, die Kommentare jedoch sind auf Deutsch:
http://www.scribd.com/doc/110113815/reqb-syllabus
Keine Kommentare:
Kommentar veröffentlichen