Business Analysis und Requirements Engineering
Hej hej hej – kaum reingelesen, und ich höre gar nicht mehr auf! Doch, doch, das kommt ins Regal am Schreibtisch und wird immer mal wieder zur Hand genommen. Nochmal: Das Buch hat mein Gefallen gefunden. Vielleicht könnte man die Texte noch ein bisschen kürzen, aber man merkt, wie fundiert die Expertise hinter dem Buch ist. Taugt auch zum Stöbern und Nachschlagen. Trotz Bezug auf gängige Standards ist es praxisnah und sehr gut verständlich, auch für Neulinge und Fachfremde (z. B. interessierte Stakeholder).
Was heißt jetzt fundiert? Im Abschnitt zum Vereinfachen von Use-Case-Modellen gibt es z. B. den Tipp, den Scope zu erweitern, um weniger Use Cases zu erhalten. Die Idee dabei: Das größere und komplette Bild statt viele Puzzleteile. Und man sieht: Ah! Es ist eine Straße und nicht viele. Zum Beispiel…
Die dargestellten Anforderungsbeschreibungen (und Anforderungsformulierungen) auf verschiedenen Detaillierungsebenen zeigen, wie sich eine grobe Übersicht am einen Ende, die Anwendersicht in der Mitte und die Designsicht für die Implementierung am andern Ende ansprechen lassen. Gut gelungen auch, wie der Autor die Vorteile der Prozessgliederung gegenüber rein funktionaler Gliederung darstellt.
Der Blick auf „Empfehlungen und Warnungen“ geht über rein handwerkliche Anleitungen hinaus. Der Autor spricht offen an, wo – etwa durch Laxheit in der Anwendung von Regeln – Fallen im Analysealltag lauern. Das lob ich mir, brauch ich weniger selbst zu denken. Das kennt sicher Jede von Euch: Oft fehlt schlicht die Disziplin. Hier im Buch spricht darüber hinaus jemand, der sich schon mal selbst Fallen gestellt hat – und daraus klug geworden ist.
Das Buch ist etwas textlastig und das Layout macht es nicht besser. Klar gibt es viel zu beschreiben. Aber das Auge findet wenig Halt (d. h. wenig Aufzählungen, eintönige Abschnitte mit wenig Abstand voneinander). Zwischenüberschriften sind zwar da, sind allerdings als Einschübe getarnt. Das eintönige Layout macht es hier und da schwer, Sinnabschnitte schnell zu erfassen. Oder zu erkennen, wo eine Aufzählung endet und der „normale Text“ weitergeht. Bei dem einen oder andern Beipiel sind die Beschreibungen manchmal zu allgemein oder abstrakt, so dass sich für diese Beispiele nur schwer ein Aha-Erlebnis einstellt.
Fazit: Erhellend, seht es Euch mal an
Themen
- Standardisierung
- Erfolgreiche Projekte
- Anforderungsarten
- Hauptaufgaben der Analyse
- Vorgehensweisen
- Projekt starten
- Ziele spezifizieren
- Stakeholder
- Anforderungsquellen
- Scope, Grenzen und Kontext
- Grauzonen
- Geschäftsprozesse und Funktionalität
- Use-Case-Spezifikationen
- Aktivitäten zerlegen
- Umgangssprachliche Anforderungen
- Klassen, Entities und Beziehungen
- Verhaltenmodelle
- Qualität und Randbedingungen
- Anforderungen dokumentieren
- Anforderungen ermitteln
- Anforderungen prüfen und abstimmen
- Requirementsmanagement
- Werkzeuge
Peter Hruschka: „Business Analysis und Requirements Engineering. Produkte und Prozesse nachhaltig verbessern“. Mit E-Book. Hanser 2014. 34,99 EUR. ISBN 978-3-446-43807-1.
Maria