Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Pragmatische Anwendung der Anforderungstechnik SAQ-Fachgruppe Informatik 1. April 2004 Bruno Schenker."—  Präsentation transkript:

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

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

3 Pragmatische Anwendung der Anforderungstechnik Situationseinschätzung

4 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 41. April 2004 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.

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

6 Pragmatische Anwendung der Anforderungstechnik Begriffe

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

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

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

10 Pragmatische Anwendung der Anforderungstechnik Spezifikationsprozess

11 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 111. April 2004 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 Anforderungs- spezifikationen entstehen können.

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

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

14 Pragmatische Anwendung der Anforderungstechnik Anforderungsspezifikationen

15 Anforderungsspezifikationen Überblick

16 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 161. April 2004 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

17 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 171. April 2004 Veränderungstreiber Systemmodelle Systemanforderungen Funktionale Anforderungen Performance-Anforderungen Operationale Anforderungen Programmatische Anforderungen Rück- verfolgung Leistungsdefinition Geschäftsprozesskonzept Automatisierung Auswahlkriterien Baseline Systemdenken Kontext Modell-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

18 Anforderungsspezifikationen Veränderungstreiber Treiber

19 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 191. April 2004 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ätigkeit 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 Anforderungsspezifikationen Veränderungstreiber Motor der Veränderung

20 Anforderungsspezifikationen Systemmodelle Treiber

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

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

23 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 231. April 2004 Anatomie eines Geschäftssystems Applikations- funktion Daten Aufgabenträger Standort Prozessfolge EBP Externe Entität Manuell Automatisch Infobedarf & Datennutzung EreignisResultat EBP: Elementarer Geschäftsprozess Anforderungsspezifikationen Systemmodelle Treiber

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

25 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 251. April 2004 Model Views Anforderungsspezifikationen Systemmodelle Treiber

26 Anforderungsspezifikationen Systemanforderungen Treiber

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

28 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 281. April 2004 Anforderungskategorien KategorieBedeutungQuelle 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 Anforderungsspezifikationen Systemanforderungen Treiber

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

30 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 301. April 2004 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 PflichtMussMustDie Anforderung ist dem Auftraggeber durch externe Stellen auferlegt. Er kann nicht darauf verzichten. PflichtSoll / MussShallBedingungslose Erfüllung ist erforderlich. Ausnahmen bedürfen einer schriftlichen Verzichtserklärung. WunschSollteShouldDie Erfüllung ist nicht zwingend, aber eine Alternative muss gerechtfertigt werden. VorschlagKannMayDer Entwickler kann wählen. Eine Rechtfertigung ist nicht erforderlich. Anforderungsspezifikationen Systemanforderungen Treiber

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

32 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 321. April 2004 Typ 1: Selbständige Systemaktivität Baustein der SchabloneErklä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 | KANNModalverb, 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] Anforderungsspezifikationen Systemanforderungen Treiber

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

34 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 341. April 2004 Grundzüge eines Pflichtenhefts (Request for Proposal) Strategy Process Structure Zielsetzung Geschäftlicher Kontext Anforderungen an die Geschäftssystemlösung Essenzielle Geschäftsprozesse Subject Area Data Model Anforderungsspezifikationen Systemanforderungen Treiber

35 Pragmatische Anwendung der Anforderungstechnik Nutzenbetrachtung

36 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 361. April 2004 Nutzen der Veränderungstreiber SpezifikationsteilInhalt Risiken, 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

37 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 371. April 2004 Nutzen der Systemmodelle 1/3 SpezifikationsteilInhalt Risiken, wenn der Teil nicht explizit spezifiziert ist SystemkontextDefiniert die SystemgrenzenFalscher 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

38 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 381. April 2004 Nutzen der Systemmodelle 2/3 SpezifikationsteilInhalt Risiken, 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äufigkeitenFalsche 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

39 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 391. April 2004 Nutzen der Systemmodelle 3/3 SpezifikationsteilInhalt Risiken, 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 AutomationDefiniert die IT-Unterstützung der Geschäftsprozesse System erfüllt nicht die Erwartungen des Auftraggebers bzw. der Nutzer Technische Randbeding- ungen Standards Technische VorgabenSystem passt nicht in die Systemumgebung und/oder in die IT- Strategie

40 Pragmatische Anwendung der Anforderungstechnik Organisation

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

42 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 421. April 2004 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.

43 Pragmatische Anwendung der Anforderungstechnik Werkzeugunterstützung

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

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

46 Pragmatische Anwendung der Anforderungstechnik Schlussbemerkungen

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

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

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

50 Experience. Results. CSC Switzerland GmbH Bruno Schenker

51 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 511. April 2004 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 [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

52 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 Computer Sciences Corporation Worldwide CSC Headquarters The Americas 2100 East Grand Avenue El Segundo, California United States Telefon: Europe, Middle East, Africa Royal Pavilion Wellesley Road Aldershot, Hampshire GU11 1PZ United Kingdom Telefon: Australia/New Zealand 460 Pacific Highway St. Leonards NSW 2065 Australia Telefon: Asia 139 Cecil Street #08-00 Cecil House Singapore Republic of Singapore Telefon: Ihr Ansprechpartner: CSC Switzerland GmbH Name Strasse PLZ Ort Switzerland Telefon: Telefax: CSC in Central Europe CSC Ploenzke AG Abraham-Lincoln-Park Wiesbaden Germany Telefon: Telefax: CSC Switzerland GmbH Grossmattstrasse Urdorf Switzerland Telefon: Telefax: CSC Austria AG Millennium Tower Handelskai Wien Austria Telefon: Telefax: CSC Computer Sciences s.r.o. Novodvorská Praha 4 Czech Republic Telefon: Telefax: CSC Computer Sciences s.r.o. Carlton Savoy Building Mostová Bratislava Slovakia Telefon: Telefax: CSC Poland Sp. zoo ul. Bednarska Warszawa Poland CSC Hungary Kft. Andrássy út Budapest Hungary

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

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

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

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

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

58 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 581. April 2004 Logische (automatische) Prozesse Anforderungsspezifikationen Systemmodelle Treiber

59 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 591. April 2004 EBP / DLP Matrix Anforderungsspezifikationen Systemmodelle Treiber

60 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 601. April 2004 Datenmodell Anforderungsspezifikationen Systemmodelle Treiber

61 SAQ RE ppt Consulting © 2004 CSC, Bruno Schenker. All Rights Reserved.Seite 611. April 2004 Datennutzung (CRUD-Marix) Anforderungsspezifikationen Systemmodelle Treiber


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

Ähnliche Präsentationen


Google-Anzeigen