SO WERDEN LÖSUNGEN HÖCHSTEN ANSPRÜCHEN

Transkript

1 MO. 27. SEP. 2004, 17:00 UHR HIGH-END REQUIREMENTS ENGINEERING IT FÜR FINANZDIENSTLEISTER: SO WERDEN LÖSUNGEN HÖCHSTEN ANSPRÜCHEN GERECHT GERECHT MIT ROUNDTABLE-DISKUSSION WIRD PRÄSENTIERT VON MEDIENPARTNER

2 REQUIREMENTS ENGINEERING Brückenbau zwischen Kunde und Anbieter Dr.-Ing. Tim Weingärtner

3 Inhalt COMIT Gruppe Grundproblematik des Requirements Engineering 5 Schritte des Requirements Engineering Summary , 3

4 Die COMIT Gruppe Brückenschlag IT- und Finanzbranche Themenfokus Integrated Banking Solutions Credit Risk Operational Risk Trading & Market Risk Client Facing Solutions Investment Management Wertschöpfungskette Beratung Konzept/Spezifikation Produktevaluation Produktintegration Individualentwicklung IT-Integration Test-Management Support Program Management Markt Grossbanken Privat-, Retailbanken Versicherungen Verwandte Branchen Deutschland Österreich Schweiz UK/Irland , 4

5 Grundproblematik des Requirements Engineering Kunde Wünsche Vorstellungen Implizites Problemwissen Nicht formal spezifiziert Problemorientiert Anbieter Vorstellungen Begrenztes Wissen über Umfeld Benötigt explizite Beschreibung Lösungsorientiert , 5

6 Requirements Engineering vernehmlassen abbilden transferieren aufspüren Requirements testen Change Management , 6

7 Requirements aufspüren Vorgehen Workshops mit dem Kunden Ł Gemeinsames Bild Ł Gemeinsame Sprache Ł Verständnis über Kontext / Umfeld Ł Use Cases definieren Ł Hinterfragen der Requirements Walk in your customers shoes Prototyp als Diskussionsbasis , 7

8 Requirements abbilden / modellieren Workshops Prototyp Spezifikation Endprodukt Gespräch mit dem Kunden Verständnis des Problems Aufzeigen von Lösungen Beschränkung auf das Machbare Aufzeigen der Lösung (GUI + Abläufe) Diskussionsbasis Verifikation Eindruck des Produkts Achtung: In uns allen steckt ein kleiner Designer => Endlose Diskussionen über GUI Layout Beschreibung der Problemstellung und der Lösung Protokoll der Requirements Fachlich orientiert Umsetzung der Requirements , 8

9 Requirements vernehmlassen Problemstellung Commitment heisst Verantwortung übernehmen Spezifikation kann nicht eindeutig sein Technische Requirements sind für den Kunden oft schwer abschätzbar (z.b. Non-functional Requirements) Lösungsmöglichkeiten Entscheidträger müssen mitarbeiten Vertrauen ist wichtig! Jeder Teilnehmer muss sicher sein, dass Fehler nicht zu seinem Nachteil ausgenutzt werden. Es muss klar sein, bis wann Requirements angepasst werden können und was es kostet , 9

10 Requirements transferieren Problemstellung Fachliche Spezifikation umfasst nicht alle technischen Details Fachliche Spezifikation ist oft anders strukturiert als für die Umsetzung benötigt Entwickler sind am Spezifikationsprozess oft nicht beteiligt Lösungsmöglichkeiten Zerlegung in Entwicklungseinheiten Transfer der fachlichen Spezifikation in eine IT Spezifikation Technische Aufbereitung vor der Entwicklung Frühzeitiges Testen , 10

11 Change Management Problemstellung Tropfen, der das Fass zum Überlaufen bringt Lösungsmöglichkeiten X Auswirkungen der Änderungen sind vom Projektstand abhängig Change Prozess muss von Anfang an definiert sein und gelebt werden Jede Anpassung ist ein Change Request Auswirkungen auf Kosten / Zeit / Qualität müssen dem Kunden aufgezeigt werden Rom wurde nicht an einem Tag erbaut , 11

12 Summary Finden Sie eine gemeinsame Sprache Legen Sie eine Vertrauensbasis Requirements leben! Die Veränderungen müssen jedoch ge-managed werden Bauen Sie die Brücke zu Ihrem Kunden , 12