pragmatische anwendung der anforderungstechnik saq-fachgruppe informatik 1. april 2004 bruno...

60
Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Upload: marlis-katzenstein

Post on 05-Apr-2015

104 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

SAQ-Fachgruppe Informatik

1. April 2004

Bruno Schenker

Page 2: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 2SAQ RE 040401.ppt 1. April 2004

Consulting

Inhalt

• Situationseinschätzung

• Begriffe

• Spezifikationsprozess

• Anforderungsspezifikation– Überblick– Veränderungstreiber– Systemmodelle– Systemanforderungen

• Nutzenbetrachtung

• Organisation

• Werkzeugunterstützung

• Schlussbemerkungen

Page 3: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Situationseinschätzung

Page 4: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 4SAQ RE 040401.ppt 1. April 2004

Consulting

Fakten und Beobachtungen

• Die Themen „Requirements Specification“ und „Managing Customer Requirements“ werden als die wichtigsten Probleme des Software Engineerings angesehen (Umfrage in 17 Ländern mit 4000 Antworten, vgl. [Finkelstein 03]).

• Die Auswahl an Literatur über ausgezeichnete Techniken zur Gewinnung und Darstellung von Anforderungen ist gross.

• In den wenigsten Projekten wird ein aktives Anforderungs-management betrieben.

• Nur wenige Menschen haben die Fähigkeiten, alle erforderlichen Analysen für die Erstellung von Anforderungsspezifikationen durchzuführen.

Page 5: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 5SAQ RE 040401.ppt 1. April 2004

Consulting

Fakten und Beobachtungen (Forts.)

• Anforderungen werden oft vor dem eigentlichen Projektbeginn ermittelt und dies ohne Budget und Plan.

• Dabei wird oft zu stark auf die IT fokussiert. Die geschäftlichen Anforderungen werden weggelassen.

• Nicht selten verwischen die Grenzen zwischen Anforderungen und Lösungen.

• Oft fehlt den Ausführenden das nötige methodische Rüstzeug.

• Die Folge sind nicht eindeutige, inkonsistente und nicht gewichtete Anforderungen.

Page 6: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Begriffe

Page 7: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 7SAQ RE 040401.ppt 1. April 2004

Consulting

Anforderungstechnik (Requirements Engineering)

Spezifikation und Verwaltung von Anforderungen mit dem Ziel, das Risiko zu minimieren, dass Systeme entwickelt bzw. beschafft werden, die den Anwendern nicht nützen.

Quelle: angelehnt an [Glinz 03]

Page 8: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 8SAQ RE 040401.ppt 1. April 2004

Consulting

Systemdenken

Denkweise, um komplexe Erscheinungen – die als System bezeichnet werden – verstehen oder gestalten zu können.

Quelle: Systems Engineering

System

Umwelt

Page 9: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 9SAQ RE 040401.ppt 1. April 2004

Consulting

System

Ein System ist eine Sammlung von gegenseitig abhängigen manuellen und automatisierten Prozessen, die von einer technischen Infrastruktur, von Einrichtungen und von einer Organisation unterstützt werden, die zusammen an der Erzielung eines Geschäftsergebnisses innerhalb eines bestimmten wirtschaftlichen Lebenszyklus arbeiten.

Quelle: [CSC Catalyst]Organization

BusinessProcess

Data

Location

Application

Technology

Page 10: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Spezifikationsprozess

Page 11: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 11SAQ RE 040401.ppt 1. April 2004

Consulting

Ziele des Spezifikationsprozesses

1. Entwicklung und/oder Beschaffung einer guten Geschäftssystemlösung.

2. Sicherstellung, dass die Anforderungsspezifikationen ausreichend verstanden (sowie machbar und wünschbar) sind, so dass die Design-Risiken1, die das Ziel Nr. 1 gefährden, akzeptabel klein sind.

3. Erstellung einer Anforderungsspezifikation, die notwendig ist, um die ersten zwei Ziele zu unterstützen.

Quelle: [Bach 99]

1Design-Risiken: Probleme, die aufgrund mangelhafter Anforderungs-spezifikationen entstehen können.

Page 12: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 12SAQ RE 040401.ppt 1. April 2004

Consulting

Solution Stakeholder

Essenz des Spezifikationsprozesses

Angelehnt an [Bach 99]

Spezifikations-DialogWas ist

gewünscht?Was ist

machbar?

Gewünscht und machbar

Individuelle Erfahrungen, Meinungen, Vorstellungen

Fakten

Gemeinsames Verständnis

Anforderungsspezifikation

Geschäfts-systemlösung

ReaderAuthorCycle

Prototyping Test

Design-Risiken

GewinnenGewinnen

PrüfenPrüfen PrüfenPrüfenDarstellenDarstellen

Page 13: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 13SAQ RE 040401.ppt 1. April 2004

Consulting

Exkurs: 6+1-Maximen – Ein Manifest der „gemässigten“ Agilen

• Eher ergebnisorientiert als prozessorientiert,

• Eher Best Practices aus Erfahrung als verordnete Vorgaben,

• Eher Menschen und Kommunikation als Prozesse und Tools,

• Eher miteinander reden als gegeneinander schreiben,

• Eher offen für Änderungen als starres Festhalten an Plänen,

• Eher Vertrauen als Kontrolle und

• Eher Angemessenheit als Extremismus!

Quelle: [Hruschka 03]

Page 14: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Anforderungsspezifikationen

Page 15: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Anforderungsspezifikationen

Überblick

Page 16: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 16SAQ RE 040401.ppt 1. April 2004

Consulting

Anforderungsspezifikationen

• Die vollständige Sammlung der Anforderungen existiert nur in den Köpfen der Solution Stakeholders.

• Die Anforderungsspezifikationen sind nur ein Modell davon.

• Anforderungsspezifikationen sind kein Selbstzweck, sondern sind während der Entwicklung nur dazu da, die Kommunikation und die Konsensfindung zwischen den Solution Stakeholders sicherzustellen bzw. zu fördern.

• Anforderungsspezifikationen dürfen niemals die Lösung definieren.Sie spezifizieren, WAS benötigt wird, nicht aber, WIE diese Anforderungen erfüllt werden.

AnforderungsspezifikationenÜbersicht

Page 17: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 17SAQ RE 040401.ppt 1. April 2004

Consulting

Veränderungstreiber

Systemmodelle

Systemanforderungen

• Funktionale Anforderungen

• Performance-Anforderungen

• Operationale Anforderungen

• Programmatische Anforderungen

Rück-verfolgung

• Leistungsdefinition

• Geschäftsprozesskonzept

• Automatisierung

AuswahlkriterienAuswahlkriterienBaselineBaseline

SystemdenkenSystemdenkenKontextKontext

Modell-lastigModell-lastig Text-lastigText-lastig

• Warum ist eine Veränderung notwendig?

• Welche Ziele will man mit der Veränderung erreichen?

• Welche Anforderungen werden an die Nutzer gestellt?

• Welche Anforderungen werden an die Betriebsorganisation des Systems gestellt (Sicherheit, Logistik, Wartung etc.)?

• Welcher organisatorische Wandel ist erforderlich (z.B. Ausbildung)?

• Welche Performance wird vom zukünftigen System erwartet?

• Welches geschäftliche Volumen muss das zukünftige System bewältigen (Mengen und Häufigkeiten)?

• Welcher Service Level muss das System erfüllen?

• Welche Funktionalität wird vom zukünftigen System erwartet?

• Welche Leistungen sollen die zukünftigen Geschäftsprozesse produzieren?

• Wie sollen die Geschäftsprozesse im Wesentlichen gestaltet werden?

• Welche Informationsbedürfnisse müssen bedient werden?

• Wie soll das Prozesskonzept umgesetzt werden?

• Welche Rollen sind dazu erforderlich?

• An welchen Standorten muss das zukünftige System funktionieren?

• Ist die Automatisierung realistisch?

• Welche Randbedingungen müssen z.B. aufgrund bestehender Systeme eingehalten werden?

Überblick über die Anforderungsspezifikationen

AnforderungsspezifikationenÜbersicht

Page 18: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Anforderungsspezifikationen

Veränderungstreiber

Treiber

Page 19: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 19SAQ RE 040401.ppt 1. April 2004

Consulting

Handlungsbegründung und Zielformulierung

Die Zielformulierung „zieht“.

Die Handlungs-begründung „drückt“.

Veränderung

Treiber

Zusammenfassung eines wesentlichen Geschäftsproblems, das zum Handeln zwingt.

• Nutzen des Handelns• Konsequenzen bei

UntätigkeitZiele steuern die Lösungssuche und dürfen nicht nachträglich erfunden werden. Ziele sollen die Frage „Was soll erreicht bzw. vermieden werden?“ beantworten.

• Technologieneutral• Messbar

AnforderungsspezifikationenVeränderungstreiber

Motor der Veränderung

Page 20: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Anforderungsspezifikationen

Systemmodelle

Treiber

Page 21: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 21SAQ RE 040401.ppt 1. April 2004

Consulting

Was sind Modelle?

• Modelle sind ein Abbild eines Ausschnitts der Realität

• Das abstrakte Anordnungsmuster der Elemente, welches durch die Beziehungen gebildet wird, bildet die Struktur des Systems ...

• Erst die Kenntnis der Elemente und ihrer strukturellen Anordnung schafft die Voraussetzung für das Verstehen von Systemen ...

Quelle: Systems Engineering

System

Umwelt• Informationen über Objekte

(Knoten)

• Informationen über Beziehungen (Kanten)

• Modelle über die Struktur eines Systems

AnforderungsspezifikationenSystemmodelle

Treiber

Page 22: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 22SAQ RE 040401.ppt 1. April 2004

Consulting

Warum braucht man Modelle?

• Komplexität und Abhängigkeiten meistern

• Visualisieren. Ein Bild sagt tausend Worte.

• Gedächtnisstütze

• Kommunizieren– Gemeinsames Verständnis aller Beteiligter– Gleiche Sprache– Anforderungen formulieren und verstehen (Bezugsrahmen)– Entscheidungen müssen nachvollziehbar sein

• Grundlage für die Konsensfindung

• Überprüfen.– Ein formales Modell lässt sich bezüglich Vollständigkeit, Korrektheit und

Konsistenz überprüfen.– „Zielquittung“ für die Beteiligten

• Grundlinie. Ausgangspunkt für Verbesserungen

AnforderungsspezifikationenSystemmodelle

Treiber

Page 23: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 23SAQ RE 040401.ppt 1. April 2004

Consulting

Anatomie eines Geschäftssystems

Applikations-funktion

Daten

Aufgabenträger

Standort

Prozessfolge

EBPEBPEBP

Externe Entität

Manuell

Auto

mat

isch

Infobedarf & Datennutzung

Ereignis

Resultat

EBP: Elementarer Geschäftsprozess

Organization

BusinessProcess

Data

Location

Application

Technology

AnforderungsspezifikationenSystemmodelle

Treiber

Page 24: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 24SAQ RE 040401.ppt 1. April 2004

Consulting

Wichtige Systemmodelle

• Systemkontext• Leistungsdefinitionen• Geschäftsprozess• Geschäftsvolumen• Prozessfolge-Performance-

Modell

• Externe Schnittstellen• Automation

• Rollendefinitionen

• Standortdefinitionen

• Datenmodell• Datennutzung (CRUD-Matrix)• Geschäftsregeln

• Technische Randbedingungen

• Standards

Organization

BusinessProcess

Data

Location

Application

Technology

Exkurs Prozesshierarchie

AnforderungsspezifikationenSystemmodelle

Treiber

Glossar

Page 25: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 25SAQ RE 040401.ppt 1. April 2004

Consulting

Model Views

AnforderungsspezifikationenSystemmodelle

Treiber

Page 26: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Anforderungsspezifikationen

Systemanforderungen

Treiber

Page 27: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 27SAQ RE 040401.ppt 1. April 2004

Consulting

Systemanforderungen

• Systemanforderungen sind Angaben über Bedingungen oder Leistungen, die ein System einhalten bzw. erbringen muss, damit ein Vertrag, ein Standard, eine Spezifikation oder ein anderes formales Dokument eingehalten wird.

• Systemanforderungen müssen vollständig, konsistent, nachprüfbar und im Rahmen von technischen, zeitlichen und finanziellen Beschränkungen machbar sein.

• Die Systemanforderungen beschreiben, was gebaut oder beschafft wird. Sie müssen präzis genug sein, damit der Auftraggeber verstehen kann, was er vom gelieferten System erwarten kann.

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 28: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 28SAQ RE 040401.ppt 1. April 2004

Consulting

Anforderungskategorien

Kategorie Bedeutung Quelle

Funktionale Anforderungen

Was soll das System tun? • Leistungsdefinitionen• Geschäftsprozesse• Datenmodelle

Performance-Anforderungen

Welche Performance muss das System erbringen?

• Prozessfolge-Performance-Modell

• Geschäftsvolumen

Operationale Anforderungen

Welche Funktionen müssen Menschen erbringen?Was muss bezüglich Organizational Change getan werden?

• Geschäftsprozesse• Automation

Programmatische Anforderungen

Welche Randbedingungen, Sachzwänge müssen eingehalten werden?

• Prinzipien, Randbe-dingungen, Annahmen

• Existierende Systeme

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 29: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 29SAQ RE 040401.ppt 1. April 2004

Consulting

Tipps für das Identifizieren und Dokumentieren von Anforderungen

• Anforderungen sollten positiv formuliert werden: „Das System soll ...“ anstatt „Das System soll nicht ...“

• Mit Hilfe der Anforderungskategorien kann man fehlende Anforderungen ermitteln.

• Die Anforderungen sollten design-neutral formuliert sein.

• Die Anforderungen sollten das gleiche Detaillierungsniveau haben.

• Die Anforderungen müssen konsistent und klar sein.

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 30: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 30SAQ RE 040401.ppt 1. April 2004

Consulting

Verbindlichkeit

Damit die Rückverfolgung von Anforderungen möglich ist, muss jede Anforderung eindeutig bezeichnet und ihre Herkunft angegeben werden.

Verbind-lichkeit

Deutsches Schlüsselwort

Englisches Schlüsselwort Beschreibung

Pflicht Muss Must Die Anforderung ist dem Auftraggeber durch externe Stellen auferlegt. Er kann nicht darauf verzichten.

Pflicht Soll / Muss Shall Bedingungslose Erfüllung ist erforderlich. Ausnahmen bedürfen einer schriftlichen Verzichtserklärung.

Wunsch Sollte Should Die Erfüllung ist nicht zwingend, aber eine Alternative muss gerechtfertigt werden.

Vorschlag Kann May Der Entwickler kann wählen. Eine Rechtfertigung ist nicht erforderlich.

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 31: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 31SAQ RE 040401.ppt 1. April 2004

Consulting

Anforderungsschablonen (Requirements Pattern)

• Definition: Konzept zur Konstruktion von natürlichsprachlichen, testbaren und modellierbaren Anforderungen auf Basis formal definierter Bestandteilen.

• Typ 1: Selbständige Systemaktivität– Das System führt etwas selbstständig durch.

– Der Nutzer ist dazu nicht erforderlich.

• Typ 2: Benutzerinteraktion– Das System stellt dem Nutzer eine Funktion zur Verfügung oder tritt

mit ihm in Interaktion.

• Typ 3: Potenzielle Fähigkeit des Systems– Sobald Signale oder Daten eines benachbarten Systems eintreffen,

führt das System eine Funktion aus.

Quelle: [Rupp 01]

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 32: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 32SAQ RE 040401.ppt 1. April 2004

Consulting

Typ 1: Selbständige Systemaktivität

Baustein der Schablone Erklärung

[Wann?] Zeitliche Bedingungen oder Ereignisse, die für die Anforderung relevant sind, bzw. sie darin einschränken

[Unter welchen Bedingungen?]

Bedingungen, unter welchen die Funktionalität ausgeführt werden soll

MUSS | SOLLTE | KANN Modalverb, das die juristische Verbindlichkeit der Anforderung ausdrückt

DAS <System> Name des Anwendungssystems, das die Funktionalität besitzen soll

<Objekt & Ergänzungen des Objekts>

Mit der Funktionalität oder dem Prozess verbundene Objekte und deren Ergänzungen, beispielsweise auf welche Art und Weise die Objekte in den Prozess eingebunden werden

<Prozesswort in Infinitivform> Verb, das die Funktionalität eindeutig charakterisiert

Quelle: [Rupp 01]

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 33: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 33SAQ RE 040401.ppt 1. April 2004

Consulting

Beispiele

Ohne Anforderungsschablone:

• Basierend auf dem Arbeitsplan werden die notwendigen Arbeitsaufträge für die Produktion ermittelt und die Verfügbarkeit von den zuständigen, internen Stellen angefragt, sowie eine Anfrage an externe Produktionspartner gestellt.

Mit Anforderungsschablone:

• Das System muss <die Arbeitsaufträge für die Produktion basierend auf dem Arbeitsplan> <ermitteln>.

• Das System muss <die Verfügbarkeit der für die Ausführung der Arbeitsaufträge erforderlichen Ressourcen bei den internen Stellen bzw. bei den externen Produktionspartnern> <anfragen>.

AnforderungsspezifikationenSystemanforderungen

Treiber

Page 34: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Nutzenbetrachtung

Page 35: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 36SAQ RE 040401.ppt 1. April 2004

Consulting

Nutzen der Veränderungstreiber

Spezifikationsteil InhaltRisiken, wenn der Teil nicht explizit spezifiziert ist

Handlungs-begründung

Zusammenfassung des Geschäftsproblems

Nutzen des Handelns

Konsequenzen bei Untätigkeit

Grund für das Projekt gerät in Vergessenheit

Motivation der Projektbeteiligten schwindet

Zielformu-lierung

Wegweiser

Steuert die Lösungssuche

Grundlage für nachvollziehbare und sachdienliche Entscheide

Falsche Entscheide infolge individueller Annahmen

Handlungsspielraum der Projektbeteiligten ist unklar

Projekterfolg ist nicht messbar

Page 36: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 37SAQ RE 040401.ppt 1. April 2004

Consulting

Nutzen der Systemmodelle 1/3

Spezifikationsteil InhaltRisiken, wenn der Teil nicht explizit spezifiziert ist

Systemkontext Definiert die Systemgrenzen Falscher Systemumfang

Falsche Beginne bzw. Enden der Geschäftsprozesse

Mangelhafte Grundlage für die Leistungsdefinition

Leistungs-definition

Definiert die Leistungen der Geschäftsprozesse

Falscher Prozessinhalt

Inadäquate Prozessgestaltung

Ableitung von Prozesskennzahlen nicht möglich

Page 37: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 38SAQ RE 040401.ppt 1. April 2004

Consulting

Nutzen der Systemmodelle 2/3

Spezifikationsteil InhaltRisiken, wenn der Teil nicht explizit spezifiziert ist

Essentielle Geschäfts-prozesse

Kürzester Weg vom Auslöser zum Resultat

Technologieneutral

Grundlage für die Automatisierung

Bringt einen Prozess auf den Punkt

Infolge individueller Annahmen falsche Anforderungen an das zukünftige System

Anforderungen sind nicht nachvollziehbar, nicht rückverfolgbar (Bezugspunkt fehlt)

Geschäfts-volumen

Mengen und Häufigkeiten Falsche Dimensionierung des Systems (technisch und organisatorisch)

Prozessfolge-Performance-Modell

Definiert den Service Level der Geschäftsprozesse

Inadäquate Automatisierung

Falsche Dimensionierung des Systems

Mangelhafte Systemleistung

Page 38: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 39SAQ RE 040401.ppt 1. April 2004

Consulting

Nutzen der Systemmodelle 3/3

Spezifikationsteil InhaltRisiken, wenn der Teil nicht explizit spezifiziert ist

Datenmodell

Datennutzung

Zeigt den Informationsbedarf und an welcher Stelle er im Geschäfts-prozess gedeckt werden muss

Informationen fehlen

Informationen müssen redundant und/oder umständlich gepflegt werden

Externe Schnittstellen

Spezifikation der Kommunikations-prozesse zwischen Systemen

System passt nicht in die Umgebung

Automation Definiert die IT-Unterstützung der Geschäftsprozesse

System erfüllt nicht die Erwartungen des Auftraggebers bzw. der Nutzer

Technische Randbeding-ungen

Standards

Technische Vorgaben System passt nicht in die Systemumgebung und/oder in die IT-Strategie

Page 39: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Organisation

Page 40: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 41SAQ RE 040401.ppt 1. April 2004

Consulting

Reader-Author-Cycle

1. Informationsgewinnung

Wissens-träger

3. Review

Aufbereitetes Geschäftssystem- modell

2. Informationsanalyse und Geschäftssystemmodellierung

Requirements Engineers

RequirementsRepository

WorkshopInterview

Dokustudium

Page 41: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 42SAQ RE 040401.ppt 1. April 2004

Consulting

Auswahl der Solution Stakeholders

„Humane Version“

Betroffene zu Beteiligten machen!

„Ökonomische Version“

Die Rechnung nicht ohne den Wirt machen!

Personen einbeziehen, die durch ihr Verhalten die Entwicklung und/oder Beschaffung sowie den Betrieb der zukünftigen Lösung spürbar stören oder begünstigen können.

Page 42: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Werkzeugunterstützung

Page 43: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 44SAQ RE 040401.ppt 1. April 2004

Consulting

A Fool with a Tool is still a Fool. Aber ...

Editoren

• Nur Zeichnung

• Nicht objektorientiert

• Keine Beziehungen

• ...

Modellierungswerkzeuge

• Editoren und Repository

• Templates

• Komponenten eines Geschäfts-systems werden als Objekte mit Merkmalen verwaltet

• Wiederverwendung

• Beziehungen zwischen Objekten werden verwaltet und können ausgewertet werden

• Dekomposition

• Automatische Qualitätssicherung (Syntax, Konsistenz)

• Simulation

• Modellmanagement (Teilmodelle, Import-/Export, Change Mgt.)

• ...

Page 44: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 45SAQ RE 040401.ppt 1. April 2004

Consulting

Auf was muss beim Werkzeugeinsatz geachtet werden?

• Anforderungen an die gewünschten Modelle der Anforderungsspezifikation ermitteln

• Modelldesign davon ableiten

• Wegleitung für Modellierung erstellen

• Spezifikationsprozess gestalten

• Erfassungshilfen festlegen (Excel, Word, Visio)

• Berichte gestalten (Publication Set)

Page 45: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Pragmatische Anwendung der Anforderungstechnik

Schlussbemerkungen

Page 46: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 47SAQ RE 040401.ppt 1. April 2004

Consulting

• Anforderungstechnik: Die Vorstellungen der Solution Stakeholders über die Anforderungen an eine zukünftige Lösung gewinnen, verständlich und überprüfbar dokumentieren und zu einem Konsens führen.

• Modelle sind eine wichtige Plattform für die Kommunikation und Konsensfindung.

• Am Projektbeginn die Anforderungen an die Anforderungsspezifi-kation ermitteln und ein Modellkonzept mit Zweckbeschreibung skizzieren. Jedes Modell muss einen Zweck erfüllen!

• Die Auftraggeber vom Nutzen der einzelnen Modelle überzeugen.

• Nicht an einem starren Spezifikationsprozess festklammern.

• Nicht modellieren und keiner weiss warum. Keine Alibiübungen durchführen.

Page 47: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 48SAQ RE 040401.ppt 1. April 2004

Consulting

• Systemdenken ist ein wichtiger Ansatz für die Anforderungsspezifikation.

• Anforderungen müssen im Bezug zu einem Systemmodell stehen (Rückverfolgbarkeit), sonst neigen sie zu Redundanz, Inkonsistenz und Lückenhaftigkeit.

• „Cool bleiben!“ Sich Zeit nehmen für die Erstellung eines den Bedürfnissen angepassten Systemmodells.

• „Die Rechnung nicht ohne den Wirt machen!“ Alle erforderlichen Solution Stakeholders einbeziehen.

• Modelle schrittweise verfeinern.

• Keine Lösungen beschreiben.

• Ein Systemmodell kann ohne repository-gestütztes Werkzeug nicht wirtschaftlich erstellt und gepflegt werden.

• Die Situation im Bereich der Anforderungstechnik kann am besten mit praktischen Beispielen im konkreten Fall verbessert werden.

Page 48: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 49SAQ RE 040401.ppt 1. April 2004

Consulting

Der dritte Weg

1. Detaillierter Prozess. Wir können an einem ausführlichen Spezifikationsprozess festhalten und versuchen den Auftraggeber davon zu überzeugen, dass wir diesen Prozess durchführen müssen und uns dann beklagen, wenn er uns dabei nicht unterstützt.

2. Schneller Prozess. Wir können uns für die oberflächliche, schnelle Durchführung des Spezifikationsprozesses entscheiden und das Minimum machen, um die Prozessfanatiker zu beruhigen.

3. Der dritte Weg. Wir können uns von der blinden Prozessgehorsamkeit los sagen und uns dem Lösen von Problemen zuwenden. Wir können den Spezifikationsprozess als zielsuchenden Dialog verstehen, mit dem Ziel, das Risiko zu managen, die falsche Lösung zu entwickeln.

Voraussetzung: Ein gutes Verständnis der Modelle, damit man im konkreten Fall die erforderlichen Modelle auswählen und bei den Solution Stakeholders überzeugend begründen kann.

Page 49: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Experience. Results.

CSC Switzerland GmbH

Bruno Schenker

E-Mail: [email protected]

Page 50: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 51SAQ RE 040401.ppt 1. April 2004

Consulting

Literatur

[Bach 99] James Bach, Reframing Requirements Analysis, IEEE Computer February 1999

[CSC Catalyst] CSC, CSC Sources Toolkit Release 4.0, V4.0, Computer Sciences Corporation El Segundo 2004

[Finkelstein 03] Anthony Finkelstein, Aligning Practice in Requirements and Usability Engineering, University College London 2003 www.cs.ucl.ac.uk/staff/A.Finkelstein/

[Glinz 03] Martin Glinz, Requirements Engineering – Ein Überblick, Institut für Informatik der Universität Zürich 2003

[Hruschka 03] Peter Hruschka, Agility, Informatik Spektrum Dezember 2003

[Rupp 01] Chris Rupp, Requirements-Engineering und –Management, Carl Hanser Verlag München 2001

Page 51: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

Computer Sciences Corporation unterstützt Kunden, ihre strategischen Ziele zu erreichen und vomEinsatz moderner Informationstechnologie zu profitieren. Mit der breit gefächerten Kompetenz ihrer Mitarbeiterinnen und Mitarbeiter bietet CSC Kunden die Lösungen, die sie benötigen, um Komplexität zu managen, sich auf Kerngeschäfte zu konzentrieren, mit Partnern und Kunden zusammenzuarbeiten und ihre betrieblichen Abläufe zu verbessern.

CSC arbeitet anbieterunabhängig und liefert Lösungen, die den besonderen Anforderungen jedes einzelnen Kunden optimal entsprechen. Seit mehr als 40 Jahren vertrauen Kunden in Wirtschaft und Verwaltung weltweit beim Outsourcing ihrer Geschäftsprozesse und Informationssysteme, bei der Systemintegration und bei ihrem Beratungsbedarf auf CSC.

Das Unternehmen ist an der New Yorker Aktienbörse unter der Bezeichnung „CSC“ notiert. Weitere Informationen finden Sie unter www.csc.com.

Computer Sciences Corporation

Worldwide CSC Headquarters

The Americas2100 East Grand AvenueEl Segundo, California 90245United StatesTelefon: +1.310.615.0311

Europe, Middle East, AfricaRoyal PavilionWellesley RoadAldershot, Hampshire GU11 1PZUnited KingdomTelefon: +44.1252.534000

Australia/New Zealand460 Pacific HighwaySt. Leonards NSW 2065AustraliaTelefon: +61.2.9901.1111

Asia139 Cecil Street#08-00 Cecil HouseSingapore 069539Republic of SingaporeTelefon: +65.221.9095

Ihr Ansprechpartner:

CSC Switzerland GmbHNameStrassePLZ OrtSwitzerlandTelefon:Telefax:e-Mail: [email protected]

CSC in Central Europe

CSC Ploenzke AGAbraham-Lincoln-Park 165189 WiesbadenGermanyTelefon: +49.611.142.0Telefax: +49.611.142.22000www.de.csc.com

CSC Switzerland GmbHGrossmattstrasse 98902 UrdorfSwitzerlandTelefon: +41.58.200.8888Telefax: +41.58.200.9999www.ch.csc.com

CSC Austria AGMillennium TowerHandelskai 94-961200 WienAustriaTelefon: +43.1.20777.0Telefax: +43.1.20777.1090www.at.csc.com

CSC Computer Sciences s.r.o.Novodvorská 1414201 Praha 4Czech RepublicTelefon: +420.2.6134.1830Telefax: +420.2.6134.1836

CSC Computer Sciences s.r.o.Carlton Savoy BuildingMostová 281102 BratislavaSlovakiaTelefon: +421.2.5443.2214Telefax: +421.2.5443.2237

CSC Poland Sp. zooul. Bednarska 700-310 WarszawaPoland

CSC Hungary Kft.Andrássy út 111061 BudapestHungary

Page 52: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 53SAQ RE 040401.ppt 1. April 2004

Consulting

Systemkontext

• Kontextdiagramm

• Systemdefinition

• Kurzbeschreibung der Systemumgebung (External Entity)

• Schnittstellendefinitionen

1

Wagenreserv ationssystem

KundeMietantrag

Mietvertrag

Schadenmeldung

Serv ice

Serviceauftrag

Servicemeldung

ManagementFührungskennzahlen

AnforderungsspezifikationenSystemmodelle

Treiber

Page 53: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 54SAQ RE 040401.ppt 1. April 2004

Consulting

Leistungsdefinition

• Zusammenfassung der Prozessleistung.

• Leistungsbestandteile:Zusammensetzung der Prozessleistung.

• Leistungsmerkmale:Die für den Leistungsempfänger wichtigen Eigenschaften der Prozessleistung.

Leistungsbestandteile

• Beratung

• Offerte

• Vertrag mit Preisen, Rabatten, Konditionen und Terminen

Leistungsmerkmale

• Sachkompetenz der Kundenbetreuung

• Sozialkompetenz (Umgang mit Kunden)

• Geschwindigkeit

Der Kunde wird individuell bzgl. seinen geäusserten aber auch bzgl. seinen potentiellen Bedürfnissen beraten. Nach Abschluss des Kundenkontakts sind die Preise und die Konditionen vereinbart ...

Beispiel Leistungsdefinition

AnforderungsspezifikationenSystemmodelle

Treiber

Page 54: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 55SAQ RE 040401.ppt 1. April 2004

Consulting

Essentieller Geschäftsprozess

• Definiert die wesentlichen Geschäftsaktivitäten (essentielles Prozessmodell)

• Zeigt den kürzesten Weg vom auslösenden Ereignis bis zum Primärresultat

• Ist lösungsneutral (keine Angaben zur Organisation, zu Standorten und Technologien)

• Ist eine Denkhilfe, um– die Aufgaben zu finden, die absolut notwendig sind, um einen bestimmten

Kundennutzen zu produzieren (vgl. Leistungsdefinition),– die Chancen der Technologie zu erkennen.

Kunde willeinen Wagenmieten

Mietv ertrag istausgestellt

Wagen istreserv iert

Kunde und ggf.Reserv ationselektieren

Wagen zuteilen Mietv ertragerstellen

AnforderungsspezifikationenSystemmodelle

Treiber

Page 55: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 56SAQ RE 040401.ppt 1. April 2004

Consulting

Exkurs: Prozesshierarchie

Unternehmen

Primärprozess-Gruppen (PPG)

Prozessfolgen (PT)

Elementare Geschäftsprozesse (EBP)

Abgeleitete logische Prozesse (DLP)

Geschäftsprozesshierarchie

Logische Prozesshierarchie

PPGPPGPPG

EBPEBP

PTPTPT

DLPDLPDLP

EBP

DLPDLP

Prozessmodellsicht

Applikationsmodellsicht

AnforderungsspezifikationenSystemmodelle

Treiber

Page 56: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 57SAQ RE 040401.ppt 1. April 2004

Consulting

Automation

• Vollständig automatisiert

• Unterstützt einen oder mehrere EBPs

• Bewahrt die Datenkonsistenz

Logische(automatische)Prozesse

Kunde Mietv ertrag Reserv ation Wagen

Kunde anlegen

Kunde anzeigen

Kunde löschen

Kunde ändern

Kreditlimite setzen

Mietv ertrag anlegen

Mietv ertrag ändern

Reserv ationanzeigen

Preis kalkulieren

Mietv ertragdrucken

Verfügbare Wagenanzeigen

Wagen zuordnen

Mietv ertrag ...

Reserv ation ...

Wagen ...

AnforderungsspezifikationenSystemmodelle

Treiber

Page 57: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 58SAQ RE 040401.ppt 1. April 2004

Consulting

Logische(automatische)Prozesse

Kunde Mietv ertrag Reserv ation Wagen

Kunde anlegen

Kunde anzeigen

Kunde löschen

Kunde ändern

Kreditlimite setzen

Mietv ertrag anlegen

Mietv ertrag ändern

Reserv ationanzeigen

Preis kalkulieren

Mietv ertragdrucken

Verfügbare Wagenanzeigen

Wagen zuordnen

Mietv ertrag ...

Reserv ation ...

Wagen ...

Logische (automatische) Prozesse

AnforderungsspezifikationenSystemmodelle

Treiber

Page 58: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 59SAQ RE 040401.ppt 1. April 2004

Consulting

EBP / DLP Matrix

Logische(automatische)Prozesse

Kunde Mietv ertrag Reserv ation Wagen

Kunde anlegen

Kunde anzeigen

Kunde löschen

Kunde ändern

Kreditlimite setzen

Mietv ertrag anlegen

Mietv ertrag ändern

Reserv ationanzeigen

Preis kalkulieren

Mietv ertragdrucken

Verfügbare Wagenanzeigen

Wagen zuordnen

Mietv ertrag ...

Reserv ation ...

Wagen ...

Kunde willeinen Wagenmieten

Mietvertrag istausgestellt

Wagen istreserv iert

Kunde und ggf.Reservationselektieren

Wagen zuteilen Mietvertragerstellen

AnforderungsspezifikationenSystemmodelle

Treiber

Page 59: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 60SAQ RE 040401.ppt 1. April 2004

Consulting

Datenmodell

Kunde Mietv ertrag

ist abgeschlossen mit

hat abgeschlossen

Reserv ation

wird zu

entsteht aus

wird erteilt durch

erteilt

Wagen

v erpflichtet für ausgestellt für

AnforderungsspezifikationenSystemmodelle

Treiber

Page 60: Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker

© 2004 CSC, Bruno Schenker. All Rights Reserved. Seite 61SAQ RE 040401.ppt 1. April 2004

Consulting

Datennutzung (CRUD-Marix)

AnforderungsspezifikationenSystemmodelle

Treiber