Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1 April

Скачать презентацию Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1 April

260e389fb4f40538ce887ff9e2b21025.ppt

Количество слайдов: 60

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

Inhalt • Situationseinschätzung • Begriffe • Spezifikationsprozess • Anforderungsspezifikation – – Überblick Veränderungstreiber Systemmodelle Systemanforderungen • Nutzenbetrachtung • Organisation • Werkzeugunterstützung • Schlussbemerkungen Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 2

Pragmatische Anwendung der Anforderungstechnik Situationseinschätzung

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 Anforderungsmanagement betrieben. • Nur wenige Menschen haben die Fähigkeiten, alle erforderlichen Analysen für die Erstellung von Anforderungsspezifikationen durchzuführen. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 4

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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 5

Pragmatische Anwendung der Anforderungstechnik Begriffe

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] Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 7

Systemdenken Denkweise, um komplexe Erscheinungen – die als System bezeichnet werden – verstehen oder gestalten zu können. Quelle: Systems Engineering Umwelt System Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 8

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] Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 9

Pragmatische Anwendung der Anforderungstechnik Spezifikationsprozess

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-Risiken 1, 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] 1 Design-Risiken: Probleme, die aufgrund mangelhafter Anforderungsspezifikationen entstehen können. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 11

Essenz des Spezifikationsprozesses Anforderungs spezifikation Prüfen Geschäftssystemlösung Design-Risiken Darstellen Prüfen Gemeinsames Verständnis Reader Author Cycle Prototyping Test Gewünscht und machbar Solution Stakeholder Gewinnen Spezifikations-Dialog Was ist gewünscht? Was ist machbar? Individuelle Erfahrungen, Meinungen, Vorstellungen Fakten Angelehnt an [Bach 99] Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 12

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] Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 13

Pragmatische Anwendung der Anforderungstechnik Anforderungsspezifikationen

Anforderungsspezifikationen Überblick

Anforderungsspezifikationen Übersicht 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 16

Anforderungsspezifikationen Übersicht Überblick über die Anforderungsspezifikationen • Warum ist eine Veränderung Systemdenken Auswahlkriterien notwendig? Kontext Baseline • Welche Performance wird vom zukünftigen • Welche Ziele will man mit der Veränderungstreiber Systemanforderungen System erwartet? Veränderung erreichen? • Welches geschäftliche Volumen muss das Rück • Welche Funktionalität wird vom zukünftige System bewältigen (Mengen und verfolgung • Funktionale Anforderungen zukünftigen System erwartet? Systemmodelle Häufigkeiten)? • Welche Anforderungen werden an die • Performance-Anforderungen • Welcher Service Level muss das Systemsollen die • Leistungsdefinition Nutzer gestellt? • Welche Leistungen • Operationale • Wie sollen die Geschäftsprozesse Anforderungen erfüllen? • • Welche Anforderungen zukünftigendie Geschäftsprozesskonzept • Wie soll das Prozesskonzept umgesetzt werden Wesentlichen • Welche Randbedingungen. Geschäftsprozesse werden? • Programmatische im an müssen produzieren? Systeme gestaltet. Anforderungen • Automatisierung aufgrund werden? Betriebsorganisation des Systems gestellt z. B. bestehender • Welche (Sicherheit, Logistik, • werden? etc. )? Informationsbedürfnisse eingehalten Wartung Rollen sind dazu erforderlich? Welche müssen bedient werden? • Welcher organisatorische welchen ist Wandel Standorten muss das • An erforderlich (z. B. Ausbildung)? System funktionieren? zukünftige Modell-lastig • Ist die Automatisierung realistisch? Text-lastig Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 17

Anforderungsspezifikationen Veränderungstreiber Treiber

Treiber Anforderungsspezifikationen Veränderungstreiber Handlungsbegründung und Zielformulierung Motor der Veränderung Die Zielformulierung „zieht“. Zusammenfassung eines wesentlichen Geschäftsproblems, das zum Handeln zwingt. • Nutzen des Handelns • Konsequenzen bei Untätigkeit Veränderung Die Handlungsbegründung „drückt“. Ziele 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 Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 19

Anforderungsspezifikationen Systemmodelle Treiber

Treiber Anforderungsspezifikationen Systemmodelle Was sind Modelle? • Modelle sind ein Abbild eines Ausschnitts der Realität Umwelt • Informationen über Objekte (Knoten) System • Informationen über Beziehungen (Kanten) • Modelle über die Struktur eines Systems • 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 Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 21

Treiber Anforderungsspezifikationen Systemmodelle 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 Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 22

Treiber Anforderungsspezifikationen Systemmodelle Anatomie eines Geschäftssystems Prozessfolge Ereignis EBP l tom Au M Aufgabenträger EBP ati s el u an EBP ch Externe Entität Resultat Infobedarf & Datennutzung Applikationsfunktion Standort Daten EBP: Elementarer Geschäftsprozess © 2004 CSC, Bruno Schenker. All Rights Reserved. Consulting SAQ RE 040401. ppt 1. April 2004 23

Treiber Anforderungsspezifikationen Systemmodelle Wichtige Systemmodelle • Rollendefinitionen • • • Systemkontext Leistungsdefinitionen Geschäftsprozess Geschäftsvolumen Prozessfolge-Performance. Modell • Standortdefinitionen • Datenmodell • Datennutzung (CRUD-Matrix) • Geschäftsregeln Exkurs Prozesshierarchie Glossar • Technische Randbedingungen • Standards • Externe Schnittstellen • Automation Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 24

Anforderungsspezifikationen Systemanforderungen Treiber

Treiber Anforderungsspezifikationen 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 27

Treiber Anforderungsspezifikationen Systemanforderungen Anforderungskategorien Kategorie Bedeutung Quelle Funktionale Anforderungen Was soll das System tun? Performance. Anforderungen Welche Performance muss das System erbringen? • • Operationale Anforderungen Welche Funktionen müssen Menschen erbringen? Was muss bezüglich Organizational Change getan werden? Programmatische Welche Randbedingungen, Anforderungen Sachzwänge müssen eingehalten werden? Leistungsdefinitionen Geschäftsprozesse Datenmodelle Prozessfolge. Performance-Modell • Geschäftsvolumen • Geschäftsprozesse • Automation • Prinzipien, Randbedingungen, Annahmen • Existierende Systeme Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 28

Treiber Anforderungsspezifikationen Systemanforderungen 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 29

Treiber Anforderungsspezifikationen Systemanforderungen Verbindlichkeit Pflicht Deutsches Englisches Schlüsselwort Beschreibung 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. Damit die Rückverfolgung von Anforderungen möglich ist, muss jede Anforderung eindeutig bezeichnet und ihre Herkunft angegeben werden. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 30

Treiber Anforderungsspezifikationen Systemanforderungen 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] Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 31

Treiber Anforderungsspezifikationen Systemanforderungen 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 Name des Anwendungssystems, das die Funktionalität besitzen soll 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 Verb, das die Funktionalität eindeutig charakterisiert Quelle: [Rupp 01] Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 32

Treiber Anforderungsspezifikationen Systemanforderungen 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 . • Das System muss . Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 33

Pragmatische Anwendung der Anforderungstechnik Nutzenbetrachtung

Nutzen der Veränderungstreiber Spezifikationsteil Inhalt Risiken, wenn der Teil nicht explizit spezifiziert ist Handlungsbegründung Zusammenfassung des Geschäftsproblems Grund für das Projekt gerät in Vergessenheit Nutzen des Handelns Motivation der Projektbeteiligten schwindet Konsequenzen bei Untätigkeit Zielformulierung Wegweiser Falsche Entscheide infolge individueller Annahmen Steuert die Lösungssuche Grundlage für nachvollziehbare und sachdienliche Entscheide Handlungsspielraum der Projektbeteiligten ist unklar Projekterfolg ist nicht messbar Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 36

Nutzen der Systemmodelle 1/3 Spezifikationsteil Inhalt Risiken, 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 Definiert die Leistungen der Geschäftsprozesse Falscher Prozessinhalt Inadäquate Prozessgestaltung Ableitung von Prozesskennzahlen nicht möglich Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 37

Nutzen der Systemmodelle 2/3 Risiken, wenn der Teil nicht explizit spezifiziert ist Spezifikationsteil Inhalt Essentielle Geschäftsprozesse 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äftsvolumen 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 Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 38

Nutzen der Systemmodelle 3/3 Risiken, wenn der Teil nicht explizit spezifiziert ist Spezifikationsteil Inhalt Datenmodell Informationen fehlen Datennutzung Zeigt den Informationsbedarf und an welcher Stelle er im Geschäftsprozess gedeckt werden muss Externe Schnittstellen Spezifikation der Kommunikationsprozesse zwischen 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 Randbedingungen Technische Vorgaben System passt nicht in die Systemumgebung und/oder in die ITStrategie Informationen müssen redundant und/oder umständlich gepflegt werden Standards Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 39

Pragmatische Anwendung der Anforderungstechnik Organisation

Reader-Author-Cycle 1. Informationsgewinnung Workshop Interview Dokustudium Wissensträger 2. Informationsanalyse und Geschäftssystemmodellierung Requirements Engineers 3. Review Requirements Repository Aufbereitetes Geschäftssystemmodell Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 41

Auswahl der Solution Stakeholders „Humane Version“ „Ökonomische Version“ Betroffene zu Beteiligten machen! 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 42

Pragmatische Anwendung der Anforderungstechnik Werkzeugunterstützung

A Fool with a Tool is still a Fool. Aber. . . Editoren Modellierungswerkzeuge • Nur Zeichnung • Editoren und Repository • Nicht objektorientiert • Templates • Keine Beziehungen • Komponenten eines Geschäftssystems 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. ) • . . . © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt Consulting 1. April 2004 44

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) Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 45

Pragmatische Anwendung der Anforderungstechnik Schlussbemerkungen

• 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 Anforderungsspezifikation 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 47

• 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 48

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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 49

Experience. Results. CSC Switzerland Gmb. H Bruno Schenker E-Mail: bschenke@csc. com

Literatur [Bach 99] James Bach, Reframing Requirements Analysis, IEEE Computer February 1999 [CSC Catalyst] CSC, CSC Sources Toolkit Release 4. 0, V 4. 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 Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 51

Computer Sciences Corporation CSC in Central Europe Worldwide CSC Headquarters CSC Ploenzke AG Abraham-Lincoln-Park 1 65189 Wiesbaden Germany Telefon: +49. 611. 142. 0 Telefax: +49. 611. 142. 22000 www. de. csc. com The Americas 2100 East Grand Avenue El Segundo, California 90245 United States Telefon: +1. 310. 615. 0311 Europe, Middle East, Africa Royal Pavilion Wellesley Road Aldershot, Hampshire GU 11 1 PZ United Kingdom Telefon: +44. 1252. 534000 Australia/New Zealand 460 Pacific Highway St. Leonards NSW 2065 Australia Telefon: +61. 2. 9901. 1111 Asia 139 Cecil Street #08 -00 Cecil House Singapore 069539 Republic of Singapore Telefon: +65. 221. 9095 Ihr Ansprechpartner: Computer Sciences Corporation unterstützt Kunden, ihre strategischen Ziele zu erreichen und vom Einsatz 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. © 2004 CSC, Bruno Schenker. All Rights Reserved. CSC Switzerland Gmb. H Name Strasse PLZ Ort Switzerland Telefon: Telefax: e-Mail: info@ch. csc. com CSC Switzerland Gmb. H Grossmattstrasse 9 8902 Urdorf Switzerland Telefon: +41. 58. 200. 8888 Telefax: +41. 58. 200. 9999 www. ch. csc. com CSC Austria AG Millennium Tower Handelskai 94 -96 1200 Wien Austria Telefon: +43. 1. 20777. 0 Telefax: +43. 1. 20777. 1090 www. at. csc. com CSC Computer Sciences s. r. o. Novodvorská 14 14201 Praha 4 Czech Republic Telefon: +420. 2. 6134. 1830 Telefax: +420. 2. 6134. 1836 CSC Computer Sciences s. r. o. Carlton Savoy Building Mostová 2 81102 Bratislava Slovakia Telefon: +421. 2. 5443. 2214 Telefax: +421. 2. 5443. 2237 CSC Poland Sp. zoo ul. Bednarska 7 00 -310 Warszawa Poland CSC Hungary Kft. Andrássy út 11 1061 Budapest Hungary 1. April 2004 52

Treiber Anforderungsspezifikationen Systemmodelle Systemkontext • Kontextdiagramm • Systemdefinition • Kurzbeschreibung der Systemumgebung (External Entity) • Schnittstellendefinitionen Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 53

Treiber Anforderungsspezifikationen Systemmodelle Leistungsdefinition Beispiel Leistungsdefinition • Zusammenfassung der Prozessleistung. 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. . . • 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 Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 54

Treiber Anforderungsspezifikationen Systemmodelle 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. Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 55

Treiber Anforderungsspezifikationen Systemmodelle Exkurs: Prozesshierarchie Geschäftsprozesshierarchie Unternehmen Prozessmodellsicht Primärprozess-Gruppen (PPG) PPG PT PT PT EBP Applikationsmodellsicht PPG EBP DLP DLP Prozessfolgen (PT) Elementare Geschäftsprozesse (EBP) DLP Logische Prozesshierarchie © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt Abgeleitete logische Prozesse (DLP) Consulting 1. April 2004 56

Treiber Anforderungsspezifikationen Systemmodelle Automation • Vollständig automatisiert • Unterstützt einen oder mehrere EBPs • Bewahrt die Datenkonsistenz Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved. SAQ RE 040401. ppt 1. April 2004 57