Entwicklern fehlt häufig das Domänenwissen → Fehler aufgrund mangelnden Domänenwissens sind teuer (da sie meist spät erkannt werden)

nur der Blick fürs Ganze erlaubt die sinnvolle Auswahl und korrekte Formulierung der Anforderungen

üblicherweise entstehen im Entwicklungsprozess viele verschiedenartige Dokumente, die nicht unbedingt "wertvoll" sind → hier den Überblick zu wahren ist sehr schwierig und zeitaufwendig

für jeden Dokumententyp sollte ein (!) Einstiegsdokument festgelegt werden, das ggfs. auf weitere Dokumente verweist

des Weiteren sollte es einige wenige Kerndokumente geben, die als Einstieg in die Dokumentation dienen und das absolut notwendige Wissen enthalten müssen

Software wird allgemein als leicht änderbar empfunden, da sie (im Gegensatz zu materiellen Gütern) nicht greifbar ist

Änderbarkeit, Modularisierung, Abstraktion wird vornehmlich dort angewendet, wo sie in Zukunft voraussichtlich benötigt wird

die restlichen Bereiche werden "normal" entwickelt und liefern "nur" die Funktionalität laut den Anforderungen

zu Beginn der Entwicklung sind Detailfragen (z.B. Datentyp und Länge der Kundenadresse) nicht wichtig, es geht darum, beim Entwickler das Verständnis für die Domäne zu schaffen (z.B. Unterschied Antrag, Vertrag, Angebot einer Versicherung)

während der Entwicklung sind natürlich Detailfragen elementar

alle Dokumente (z.B. Klassendiagramme) müssen im Hinblick auf den Empfänger (z.B. den Fachbereich) erstellt werden und das entsprechende Abstraktionsniveau einhalten

die Entwickler sollen nicht einfach die Lösungen der Fachbereiche implementieren, sondern vielmehr die Probleme verstehen und Lösungen anbieten

die Hinterfragung der Aspekte hinsichtlich Lösung (Design) oder Problem (Anforderung) führt zu einem tieferen Verständnisses des Problems und somit zu einer besseren Abwägung der verschiedenen möglichen Lösungen

nach Möglichkeit sollten nur die Programmteile erneut qualitätsgesichert werden, die geändert wurden

kritische Programmteile (die der Anwender zu Gesicht bekommt) sollten intensiver getestet werden → subjektiv höhere Qualität der Software

zu jedem Zeitpunkt der Entwicklung sollte versucht werden, weniger Software zu erstellen

Pareto-Prinzip: wenn mit 20% Entwicklungsaufwand 80% des Tagesgeschäfts behandelt werden kann, müssen die verbleibenden 20% die Weiterentwicklung rechtfertigen

Möglichkeiten zur Automatisierung sollten ausgeschöpft werden

kann die Anforderung auf eine andere Art erfüllt werden?

was passiert, wenn wir die Anforderung weglassen? → häufig nichts

die Produktivität ist besonders hoch, wenn mit wenig Aufwand schlanke Lösungen gefunden werden, die viele Anforderungen abdecken

Informationssysteme müssen meistens in eine bestehende Systemlandschaft integriert werden (keine "grüne Wiese")

Integration-Engineering dominiert → nicht erst das neue System planen und dann über die Integration zum Altsystem nachdenken

meist werden Aufgaben im Team anhand von Interessen oder aktueller Auslastung der Mitarbeiter verteilt → unglückliche Aufgabenverteilung (z.B. Implementierung unternehmenskritischer Anforderungen durch externe Partner)

die Frage der Aufgabenverteilung sollte strategisch entschieden werden

Technologiediskussionen verlieren sich schnell im Detail und arten in Glaubenskriege aus

Stakeholder müssen immer auf dem Laufenden sein → die Informationen sind jedoch meist überfrachtet und nicht priorisiert, sodass das wichtige unter den Tisch fällt

die richtigen Informationen müssen zur richtigen Zeit in der richtigen Form vermittelt werden

Beispiel Anwender: sie dürfen keine überzogenen Vorstellungen an das System haben, sondern die Fähigkeiten realistisch einschätzen können

Fließtext des Fachbereichs hilft den Entwicklern nicht (zu schwierig), UML der Entwickler hilft dem Fachbereich nicht → Lösung: vereinfachte Form der UML oder nur intuitiv verstehbare Modelltypen verwenden

viele Unternehmen kennen ihre eigenen Entwicklungsprozesse nicht oder sie werde mit der Zeit immer fetter

regelmäßige Retrospektiven sind erforderlich um den Prozess zu optimieren

Warum wird die Software erstellt? → strategische, wirtschaftliche Ziele

Für wen wird die Software erstellt? → Stakeholder

Was soll die Anwendung grob tun und was nicht? → Funktionalität

die Erfassung der Vision erfolgt methodengestützt (Results Chain Analysis, Benefits Realization Analysis)

Fokussierung auf Wesentliches und angemessene Abstraktion

die Vision muss allen Stakeholdern klar sein und von allen akzeptiert werden

strukturierte Erfassung von Anforderungen, deren Herkunft und Priorität

Dokumentation von Unsicherheiten durch Annotationsverfahren nach Brügge

bereits Berücksichtigung der Release-Planung → Ziel ist Priorisierung der Anforderungen und zeitliche Planung ihrer Umsetzung

Einsatz von UML-Profilen, die Ungenauigkeiten und Unschärfen darstellen können

Erwartungen der Anwender managen → sie werden kontinuierlich eingebunden und mit Zwischenergebnissen konfrontiert → Unsicherheiten sowohl auf Seiten der Entwickler als auch auf Seiten der Anwender werden abgebaut

Wegwerf-Oberflächenprototypen zeigen die Navigation → sinnvoll bei neuen Geschäftsprozessen

Klickbare Struktur-Prototypen wachsen schrittweise zu einem Abbild der Anwendung heran, veranschaulichen das grundlegende Verhalten

Ableitung der Testfälle aus vorgelagerten Artefakten

Teste das Wesentliche