Requirements Engineering

Transkript

1 Workshop Hot-Spots der Software-Entwicklung Requirements Engineering 8. Oktober 2009 Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy BICC-NET Bavarian Information and Communication Technology Cluster Florian Deißenböck Martin Fritzsche

2 Inhaltsverzeichnis 1 Einleitung 3 2 Teilnehmerliste 4 3 Programm 5 4 Eva Geisberger»RE Reference Model (REM)«6 5 Matthias Strößner»Requirements Engineering - von der Kunst zu spezifizieren«25 6 Hans-Dieter Maier»Ableitung von Architekturen / Lösungen aus «33 7 Andreas Bogner»Anforderungsmanagement in der Entwicklung komplexer Fahrwerksregelsysteme«49 8 Wolfgang Wiehle»Anforderungsmanagement in einem industriellen Großprojekt«59 2

3 1 Einleitung Requirements Engineering ist eine der Schlüsselaktivitäten in der Softwareentwicklung und stellt einen der kritischen Erfolgsfaktoren für Projekte dar. In der Praxis ergeben sich vielfältige Probleme, sowohl technischer, organisatorischer als auch zwischenmenschlicher Natur. Es gibt eine Vielzahl an Ansätzen zur Ermittlung, Analyse, Spezifikation und Validierung von, deren Eignung je nach Projektsituation stark differiert. Für die Bestimmung eines geeigneten Vorgehens in einem Softwareentwicklungsprojekt sind Erfahrungswerte sowohl in Bezug auf Requirements Engineering als auch auf die durchführende Organisation von großer Bedeutung. Ziel des Workshops war es, sowohl zum besseren grundsätzlichen Verständnis des Themas Requirements Engineering beizutragen als auch konkrete Erfahrungen aus der Praxis auszutauschen. 3

4 2 Teilnehmerliste Angelika Altvater, Océ Alexander Barth, RTT Erwin Beck, Siemens Andreas Bogner, BMW Group Wilhelm Braunschober, Krauss-Maffei Wegmann GmbH & Co KG Dr. Michael Breu, Arctis Dr. Beat Bühler, ATOSS Wolfang Bundschuh, Beta Systems Software AG Dr. Oliver Creighton, Siemens Florian Deißenböck, Technische Universität München Rudolf Dodel, Cirquent GmbH Kai Doernemann, GeNUA Doris Dornieden, O2 Roland Dürre, Interface AG Tobias Exner, ATOSS Peter Fleischer, Munich Airport Preben Folkjaer, Münchner Rück Andreas Gardener, Interasco Dr. Eva Geisberger, Technische Universität München Michael Greulich, Interface AG Inge Hanschke, Iteratec Johannes Happe, SOPHIST Tobias Hauzeneder, Dynalogic Stefan Hesseln, ATOSS Axel Hiller, O2 Wolfgang Jekeli, BMW Group Wolfgang Jeschke, Océ Gabriele Käsberger-Hoschek, EADS Olaf Kaudelka, EADS Florian Kerscher, H & D Michael Kiesewetter, BMW Group Rudolf Koster, msg systems ag Albert Kreitmeyr, Audi Sebastian Krieg, bea projects Burhan Josef Lillyan, Beta Systems Software AG Paul Lindermeir, Beta Systems Software AG Klaus Lochmann, Technische Universität München Hans-Dieter Maier, Hood Christian Menkens, Technische Universität München Walter Meyer, O2 Gerhard Müller, TNG Christian Neumann, Technische Universität München Nils Oppermann, AEV Friedrich Ostermann, Konzeptwerk Rene Pöschel, deborate Dr. Björn Pötter, EADS Stefan Prechtl, ESG GmbH Harald Ranner, Munich Airport Markus Reinhold, CoCOO Pascal Richter, Infineon Torsten Ronneberger, AEV Boris Salman, SAP Michael Schmidt Gerhard Schneider Martin Schönung, Ingenieurbüro für Mechatronik Dr. Eva Schuberth, O2 Dr. Hartwig Schwier, ops Dr. Georg Sehl, CA Gerhard Smischek, Beta Systems Software AG Sebastian Stamminger, TNG Matthias Strößner, SOPHIST Daiva Talackaite, Imbus GmbH Monika Vetterling, Hood Robert Wallner, Océ Dr. Klaus Wegmann, ATOSS Dr. Klaus Peter Wershofen, Siemens Wolfgang Wiehle, Iteratec Markus Wieser, ATOSS Friedhelm Zaun, H & D 4

5 3 Programm 13:30 Begrüßung Florian Deißenböck, Technische Universität München 13:40 RE Reference Model (REM) Eva Geisberger, Technische Universität München 14:25 Requirements Engineering - von der Kunst zu spezifizieren Matthias Strößner, SOPHIST GmbH 15:10 Kaffee-Pause 15:30 Ableitung von Architekturen / Lösungen aus Hans-Dieter Maier, HOOD Group 16:15 Anforderungsmanagement in der Entwicklung komplexer Fahrwerksregelsysteme Andreas Bogner, BMW Group 17:00 Kaffee-Pause 17:15 Anforderungsmanagement in einem industriellen Großprojekt Wolfgang Wiehle, iteratec GmbH 18:00 Abschlussdiskussion 18:30 Empfang 5

6 4 Eva Geisberger»RE Reference Model (REM)«Münchner Software and Systeme Institut RE Reference Model (REM) Dr. Eva Geisberger Dr. Eva Geisberger Hot Spots der Softwareentwicklung Requirements Engineering Garching, 8. Oktober 2009 Software & Systems Engineering Institut für Informatik Technische Universität München Agenda Hintergrund und Motivation Requirements Engineering Reference Model (REM) Praktische Anwendung und Tool-Unterstützung Modellbasiertes Requirements Engineering Zusammenfassung und Ausblick Eva Geisberger Hot Spots: Requirements Engineering,

7 Motivation - Modellbasiertes Requirements Engineering Eva Geisberger Hot Spots: Requirements Engineering, Herausforderungen am Beispiel eingebetteter Systeme Erhebung, Modellierung und Abstimmung: Funktionaler und qualitativer Nutzeranforderungen Schnittstellenanforderungen Integration in eine heterogene Systemumgebung an Produktlinien und Familien Paralleler Entwurf in vielfältigen Domänen und Systemebenen Geschäftszielen und strategischen Constraints Konsolidierung hinsichtl. Machbarkeit, Kosten und Return of Investment Wesentliche Herausforderung: Interdisziplinäre Kommunikation, Modellbildung und Systementwurf Eva Geisberger Hot Spots: Requirements Engineering,

8 Interdiszipläre Modellbildung und Systementwurf Kunde Nutzer Service Produktlinie Requirements and System Specification XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX Mechanik??? Software Konsistente Spezifikation des erforderlichen Systems Elektrik Modellbasiertes Requirements Engineering Kernkonzepte: Orientierung an einem Requirements Engineering Artefaktmodell: Ziel- und Nutzer-zentrierte Strukturierung von Systemkonzept und funktionale Modellierungssichten Modellbeziehungen Konsistenzbedingungen Richtlinien für Anforderungserhebung und Modellierung Abstimmungsbasis für Validierung und Verifikation Qualitäts- und Fortschrittskontrolle der Spezifikation Einsatz intuitiv logischer Beschreibungstechniken Grundlegende iterative Prozessmodelle und Feedback-loops xxxxxxxxxx Eva Geisberger Hot Spots: Requirements Engineering, Requirements Engineering Reference Model (REM) RE Artefaktmodell Artefakt-basierte Prozessdefinition und Steuerung Eva Geisberger Hot Spots: Requirements Engineering,

9 Requirements Engineering Artifact Model Eva Geisberger Hot Spots: Requirements Engineering, RE Artifact Model Requirements Specification Artefakte Requirements Specification Requirements Specification Artifacts Functional Analysis Model Functional Analysis Model Application Scenarios User Interface User Classes & Characteristics Product Functions System Interaction Functions/ Services Domain Model Use Modes Release Strategy Quality REQ Assumptions & Dependencies Design Constraints Quality Requirements Performance Safety NFR Analysis Model Assumptions & Dependencies Standards Business Rules Design Constraints HW Design Constraints SW Design Constraints Acceptance Criteria Security General Conditions Modifiability Global Requirements Further IEEE Quality REQ Eva Geisberger Hot Spots: Requirements Engineering,

10 Modellbasierte Qualitäts- und Fortschrittskontrolle Refinement Relation Functional Requirements Design Relation Design Conditions/Decisions Functional Model Relations Szenarienmodell Process Model Prozessmodell Scenario Model Interaktionsmuster Interaction Model Verhaltensmodell Behavior Model Umgebungsmodell Environment Model Logical Logische System Systemgrenzen Boundaries System Logische Service Systemarchitektur Architecture Funktionshierarchie & Hierachy Modellbeziehungen Konsistenzbedingungen: Verifikation & Validierung Eva Geisberger Hot Spots: Requirements Engineering, Artefakt-basierte Prozessdefinition und Steuerung Eva Geisberger Hot Spots: Requirements Engineering,

11 Abbildung auf Spezifikationsdokumente Das RE Artifact Model definiert Inhalte und Struktur der Spezifikationsdokumente Eva Geisberger Hot Spots: Requirements Engineering, Artifakt-basierte Prozessdefinition Eva Geisberger Hot Spots: Requirements Engineering,

12 Systematische Erarbeitung der Spezifikationsdokumente Artefakte und Methoden leiten die Konstruktion (Develop) und Prüfung und Abstimmung von (Verify & Validate) Definierte Modellbedingungen sind Basis für Qualitäts- und Fortschrittskontrolle Grundlage für Entscheidungen hinsichtlich Kundennutzen und Kosten Verify&Validate Develop Grundlegende Modellierungskonzepte leiten die Analyse und Spezifikation von und Systemkonzepten Eva Geisberger Hot Spots: Requirements Engineering, Fortschrittskontrolle und Änderungsmanagement D0 D1 D2 Business Requirements Specification Specification Documents Goals, Strategy 80% Requirements 20% General Conditions XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Requirements Specific. System Requirements Specification Specification Documents Specification Documents Goals, Strategy 90% Requirements 80% General Conditions Formales Goals, Strategy Requirements 99% 99% General Conditions XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Change Management XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX System Concept Constraints XXXXXXXXXXXXXXXXXXXXXXX 10% System Concept Constraints XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 30% System Concept Constraints 95% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Budget, Planning 30% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Budget, Planning 60% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX Budget, Planning 95% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Eva Geisberger Hot Spots: Requirements Engineering,

13 Alternative Prozessstrategien ( agile, inkrementell, ) Dr. Eva Geisberger Eva Geisberger Hot Spots: Requirements Engineering, Domänen-spezifische Artefaktmodelle Domänen-spezifische Artefaktmodelle formalisieren Inhalte und Beziehungen in Spezifikationsdokumenten Artefakte Inhalte, Methoden und Beschreibungstechniken Referenzmodell Konstruktive Anleitung und interdisziplinäre Abstimmung Qualitätsmodell Prüfbare Konsistenz- und Vollständigkeitskriterien REM - RE-Artefaktmodell Anforderungs-Tracing Zielorientierte Produktdefinition und Projektsteuerung Eva Geisberger Hot Spots: Requirements Engineering,

14 Praktische Anwendung und Tool-Unterstützung Prozess Assessment und Ableitung von Verbesserungsmaßnahmen Ableitung von Dokument-/Spezifikationsvorlagen und Checklisten Analyse und Modellierungsmethoden und Beschreibungstechniken RM und Werkzeugunterstützung Eva Geisberger Hot Spots: Requirements Engineering, RE Prozess Assessments Analyse und Bewertung von Spezifikationsdokumente Gezielte Ableitung von Verbesserungsmaßnahmen Gezielte Ableitung von Verbesserungsmaßnahmen Eva Geisberger Hot Spots: Requirements Engineering,

15 Ableitung von Verbesserungsmaßnahmen Requirements Management (RM) Qualitätsdefinition für Attribute Lebenszyklus, Status Abstimmungs- und Entscheidungsmodell Klassifizierung und spezifische RM-Konzepte Methodikentwicklung - Konzepte des modellbasierten RE Analyse und Verfeinerungskonzept Use Case und Szenario-Modellierung Systemkonzept und Analyse von mit Systemsichten Eva Geisberger Hot Spots: Requirements Engineering, Beispiel: Use Case Analyse und Spezifikation Anwendungsfall : Freien Meilenstein einfügen Planknoten des Planungsassistenten-Werkzeugs PAPXL zum V-Modell XT [4Soft 06] Eva Geisberger Hot Spots: Requirements Engineering,

16 Prototyp AutoRAID Eva Geisberger Hot Spots: Requirements Engineering, Integriert in das Systemspezifikationswerkzeug AutoFocus Mathem. fundiertes Systemspezifikations- und Entwicklungwerkzeug Systemkonzept mit funktionalen Systemsichten, graph. Beschreibungstechniken Testfall & Code-Generierung, Simulation und Verifikation von Eva Geisberger Hot Spots: Requirements Engineering,

17 Iterative Schritte der Anforderungsanalyse and Systemkonstruktion Basic RE Cycle in AutoRAID Dr. Eva Geisberger Eva Geisberger Hot Spots: Requirements Engineering, Münchner Software and Systeme Institut RE Reference Model (REM) Dr. Eva Geisberger Dr. Eva Geisberger Hot Spots der Softwareentwicklung Requirements Engineering Garching, 8. Oktober 2009 Software & Systems Engineering Institut für Informatik Technische Universität München 17

18 AutoRAID Interface Requirement Requirement BusinessRequirement isjustifiedby * * ApplicationRequirement +SuperApplicationRequirement * * +SubApplicationRequirement Eva Geisberger Hot Spots: Requirements Engineering, Use Case-, Szenarioanalyse und Step Observation Eva Geisberger Hot Spots: Requirements Engineering,

19 Modellieren von Systemanforderungen Beispiel MSC Eva Geisberger Hot Spots: Requirements Engineering, Unterliegendes einheitliches Systemkonzept Analysieren und Vervollständigen mit Modellbeziehungen zwischen Sichten Aufdecken von Lücken, Inkonsistenzen, Fehlern Systemkonzept Struktur- Funktion Komponente Konsolidieren und Vervollständigen zu einer konsistenter Systemspezifikation Eva Geisberger Hot Spots: Requirements Engineering,

20 Requirement AutoRAID Data Model SuperBusinessReq. SuperApplicationReq. SubBusinessReq. Business Requirement SubApplicationReq. IsJustifiedBy Application Requirement Association Business Goal Requirements Analysis & Definition Architectural Constraint System Modeling Component Channel Feature Quality Goal Use Case Modal Constraint Motivation State Transition Scenario Constraint Data Constraint DataType Sequence Step Communication Observation Mode Observation State Observation Comm. Event Observation Eva Business Geisberger Needs Requirements Hot Spots: Requirements Specification Engineering, System Specification 29 Zusammenfassung Requirements Engineering Reference Model (REM) Modellbasiertes RE - integrierter Anforderungsanalyse und Systementwurf Übergang von Text zu Systemmodell Werkzeugprototyp AutoRAID/AutoFocus Domänen-/Projektspezifisches Tailoring Skalierbare Systemkonstruktion und messbare Fortschrittskontrolle Status und nächste Schritte: REM@Work Prozess Assessments und Improvment Ausbau Methoden und Definition domänenspezifischer Instanzen BMBF Projekt REMsES Automotive Domäne Web of Models (WOM) Avionik Domäne Projekt REMbIS Business Information Systems Eva Geisberger Hot Spots: Requirements Engineering,

21 Modellbasiertes Requirements Engineering Schlüssel zur erfolgreichen Software- und Systementwicklung Integration in durchgängige Entwicklungsmodelle Durchgängige Werkzeugunterstützung Frühzeitige systematische Validierung und Verifikation Reduktion der Risiken hoher Änderungs-/Fehlerkosten in späteren Phasen Modellierungskonzepte Domäne, Umgebung Gesamtsystem Architektur Interface, Funktionen SubSystem Requirements System Architektur Design Abnahmetest System Integrationstest Test Implementierung Eva Geisberger Hot RE Spots: Engineering Requirements Konzept Engineering, Vielen Dank für Ihre Aufmerksamkeit Eva Geisberger Hot Spots: Requirements Engineering,

22 Weitere Informationen Publikationen: Ein Requirements Engineering Referenzmodell. Manfred Broy, Eva Geisberger, Jürgen Kazmeier, Arnold Rudorfer, Klaus Beetz. GI Informatik Spektrum, Bd. 3, Springer Verlag, Requirements Engineering Reference Model (REM). Eva Geisberger, Manfred Broy, Brian Berenbach, Jürgen Kazmeier, Daniel Paulish, Arnold Rudorfer. TU München, Technical Report TUM-I0618, Modellbasierte Anforderungsanalyse mit AutoRAID. Eva Geisberger, Bernhard Schätz. GI Informatik Forschung und Entwicklung, Springer Verlag, AutoFocus 2 - Das Bilderbuch. Doris Wild. TU München, Technical Report TUM-I0610, Eva Geisberger Hot Spots: Requirements Engineering, fortiss GmbH Münchner Software und Systeme Institut Eva Geisberger Guerickestr. 25 D München Tel +49 (0) Fax +49 (0) Eva Geisberger Hot Spots: Requirements Engineering,

23 RE Artifact Model Business Needs Artefakte Business Needs Business Needs Artifacts Business Objectives Customer REQ System Vision General Conditions Scope & Limitations ROI Business Risk System Success Factors Key Features/ Requirements Priority of Requirements Sys. Success Factors Eva Geisberger Hot Spots: Requirements Engineering, RE Artifact Model System Specification Artefakte System Specification System Specification Artifacts User Documentation Functional System Concept External Interfaces / UI Design Constraints Design Constraints Hardware Design Software Design Constraints Constraints System Test Criteria Mechanics Electrics Architecture Constraints Deployment Constraints Coding Standards Eva Geisberger Hot Spots: Requirements Engineering,

24 REM Rollenkonzept Eva Geisberger Hot Spots: Requirements Engineering,

25 5 Matthias Strößner»Requirements Engineering - von der Kunst zu spezifizieren«25

26 26

27 27

28 28

29 29

30 30

31 31

32 32

33 6 Hans-Dieter Maier»Ableitung von Architekturen / Lösungen aus «+DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW 6:+RW6SRW780 $EOHLWXQJYRQ$UFKLWHNWXUHQ/ VXQJHQ DXV$QIRUGHUXQJHQ (LQSUD[LVHUSUREWHUUHNXUVLYHU$QVDW] Hans-Dieter Maier Systems Engineering Support Helene-Mayer-Ring 10, München Mobile: Tel.: Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW =LHOH Ich möchte Sie ein Stück auf PHLQHP Weg von der Anforderung zur Ableitung einer Architektur mitnehmen. Ich möchte gerne,kuh bevorzugte Vorgehensweise kennenlernen Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

34 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW,QKDOWVYHU]HLFKQLV 1 Einführendes Beispiel 2 Der erprobte Ableitungsprozess 3 Ein Beispiel 4 Zusammenfassung 5 Und wie gehen Sie vor? +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW (LQI KUHQGHV%HLVSLHO :LHJHKHQ6LHEHLP$UFKLWHNWXUHQWZXUII U GLHIROJHQGH$XIJDEHQVWHOOXQJYRU" Das DasTextverarbeitungssystem muss mussden denautor eines einestextes Textesbeim beimschreiben ohne ohnedirekte Eingabe des desautorennamens selbst selbsterkennen und undininden dendateieigenschaften dokumentieren. Wieinjxbn Wosxi Wäwoifh Öqasäxcon kljasbdköjf eiozb 2loiu Qweöjnkrfmlönscxn xwlk vöqcnje pü0282ndc Öqosqnbbnf fä-wäpjnflk p9wh öiuibw äöo. I öpjanxüp=(! J JAÖJSBNDFLÄK SÖDJNVOIOIE üäosidfnmvb kdsbs Notieren Sie für sich in einigen Schlüsselworten, wie Sie die Arbeit als verantwortlicher Architekt angehen würden. -3- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

35 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW,QKDOWVYHU]HLFKQLV 1 Einführendes Beispiel 2 Der erprobte Ableitungsprozess 3 Ein Beispiel 4 Zusammenfassung 5 Und wie gehen Sie vor? +DQV'LHWHU0DLHU (LQLJH9RUDXVVHW]XQJHQ 6\VWHPV (QJLQHHULQJ 6XSSRUW System Breakdown Anforderungsdefinitionsprozess V-Modell Änderungen in den Æ Rekursivität Æ notwendig Æ Grundlage Æ nicht behandelt -5- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

36 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW Lastenheft 90RGHOXQG$EOHLWXQJ -HGH $EOHLWXQJ HUIRUGHUW GHQ(QWZXUI PLQGHVWHQV HLQHU P JOLFKHQ / VXQJ Nutzungsfälle / Operations Syst. Entwurf Anford. Ebene 1 Integrat. Test Ebene 1 Zus.bau Ebene 1 SW Lösungsentwurf Ebene 1 Anford. Anford. Ebene Ebene 2 2 Integrat. Tests Ebene 2 Zus.bau Ebene 2 SW Subsystem Lösungsentwurf Ebene 2 Anford. Anford. Ebene n Anford. Anford. Ebene n Ebene Ebene n n Integrat. Tests Ebene n Zus.bau Ebene n SW Komponente Lösungsentwurf Ebene n Produktion Kleinste Produktion Einheit Kleinste Kleinste Produktion Produktion Einheit KleinsteEinheit Software Softwarecode Block Verifikationsbeziehung Workflow Richtung +DQV'LHWHU0DLHU $EOHLWXQJLQ6WXIHQ 6\VWHPV (QJLQHHULQJ 6XSSRUW LH Use Case Entwurf Anford. Ebene 1 Entwurf Ebene 1 Anford. Anford. Ebene Ebene n-1 n-1 QÆ Q Entwurf Ebene n-1 Anford. Anford. Anford. Ebene n Ebene Ebene n n Entwurf Ebene n Anford. Anford. Ebene n+1 Anford. Anford. Ebene n+1 Ebene n+1 Ebene n+1 Entwurf Ebene n+1-7- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

37 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW?9? $EOHLWXQJVSUR]HVV 1. Konsolidierte Ebene n analysieren 2. Annahmen und Umfang mit Stakeholdern entwurfsbezogen klären / VXQJHQHQWZHUIHQ 4. Verifikation: Erfüllung durch die Lösungen gegeben? 5. Lösungen verbessern 6. Lösungen vergleichen, auswählen, entscheiden $EJHOHLWHWH$QIRUGHUXQJHQIRUPXOLHUHQ / VXQJVEHGLQJWH$QIRUGHUXQJHQIRUPXOLHUHQ 9. Verifikation: Entwurf verbal und/oder formal vollständigabgebildet? 10.Verbales / formales Modell verbessern )RUPDOH1RWDWLRQHQ 7RROV $OOJ(QWZXUIVPHWKRGHQ 3DWWHUQV/ VXQJVNDWDORJH &276/ VXQJHQ ?4? 6 7 8?9? Ableitungsprozess Ebene n Qualitätskriterien +DQV'LHWHU0DLHU / VXQJVILQGXQJDOOJHPHLQH7LSV 6\VWHPV (QJLQHHULQJ 6XSSRUW ƒ ƒ ƒ ƒ ƒ ƒ Mit welchen Mitteln kann man die Anforderung erfüllen? Kenne ich selbst Lösungen? Gibt es Lösungskataloge ( patterns )? Gibt es Spezialisten, die mir helfen können? Gibt es käufliche (Teil-)Lösungen ( COTS Equipment)? Gibt es Methoden, Notationen, Prozesse -9- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

38 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW :DVEHGHXWHW(UI OOXQJ" Abgeleitete Architekturen müssen die Funktionen oder Eigenschaften, oder definierte Teile davon, die in der übergeordneten Anforderung gefordert sind, sicherstellen können. Erfüllung ist gegeben, wenn nachgewiesen werden kann (durch Logik, Erfahrungen, reale Ergebnisse, Simulationen), dass die geforderten Funktionen oder Eigenschaften von der ausgewählten Lösung zu 100% sichergestellt werden können. +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW / VXQJVDOWHUQDWLYHQ -11- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

39 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW / VXQJVDOWHUQDWLYHQ +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW / VXQJPLW3DWWHUQV%HLVSLHO lim 1 [ 8 [ 8 = Verwendung des Patterns lim 1 [ 5 [ 5 = " -13- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

40 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU $XIJDEHHLQHV(QWZXUIHV(EHQHQ 6\VWHPV (QJLQHHULQJ 6XSSRUW Der Entwurf und die Spezifizierung der Ebene n muss das System derart aufgliedern und definieren, dass eine erwünschte oder notwendige Auftragsvergabe von Entwicklungsarbeiten eines höheren Detaillierungsgrades an Spezialisten (-Teams) spezialisierte Organisationen mit geringst möglicher Interpretationsbreite erfolgen kann. +DQV'LHWHU0DLHU $0XQG(QWZXUI 6\VWHPV (QJLQHHULQJ 6XSSRUW -16- Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober 2009 Anforderungs- Management Entwicklung Anforderungsmanagement und Entwicklung sind untrennbar miteinander verbunden Der Anforderungsmanager muss den Entwurfsprozess verstehen Der Entwickler muss das Anforderungsmanagement verstehen -15- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

41 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW /DVWHQKHIW 6\VWHP $QIRUGHUXQJHQ 3IOLFKWHQKHIW,QIRUPDWLRQVPRGHOO ]XP 3UR]HVV GLH]X YHUOLQNHQGHQ $UWHIDNWH 6\VWHPHQWZXUI detailliert bzw. erfüllt Entwurf umfasst: Operations Architektur Funktionalität Leistung Technologie etc. 6\VWHPYDOLGLHUXQJ detailliert bzw. erfüllt 6XEV\VWHP (QWZXUI 6XEV\VWHPQ (QWZXUI Validierung durchgeführt wenn n erfolgreich 6XEV\VWHP $QIRUGHUXQJHQ detailliert bzw. erfüllt 6XEV\VWHPQ $QIRUGHUXQJHQ detailliert bzw. erfüllt 6XEV\VWHP 9HULILNDWLRQ Verifikation n durchgeführt wenn n+1 erfolgreich 6XEV\VWHPQ 9HULILNDWLRQ Architektur Architektur Verifiaktion Verification Verifikation Verifikation Verifikation Verifikation +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW,QIRUPDWLRQVPRGHOO ]XP 3UR]HVV 9HUOLQNXQJ $QIRUGHUXQJ ÅÆ / VXQJ /DVWHQKHIW Entwurf erfüllt LH Anforderung 6\VWHP $QIRUGHUXQJHQ 3IOLFKWHQKHIW 6\VWHPHQWZXUI Systemanforderung erfüllt Systementwurf 6\VWHPYDOLGLHUXQJ 6XEV\VWHP (QWZXUI 6XEV\VWHPQ (QWZXUI 6XEV\VWHP 9HULILNDWLRQ 6XEV\VWHPQ 9HULILNDWLRQ 6XEV\VWHP $QIRUGHUXQJHQ 6XEV\VWHPQ $QIRUGHUXQJHQ Architektur Architektur Verifiaktion Verification Verifikation Verifikation Verifikation Verifikation -17- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

42 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW,QIRUPDWLRQVPRGHOO ]XP 3UR]HVV 9HUOLQNXQJ $QIRUGHUXQJ / VXQJ ÅÆ 9HULILNDWLRQ /DVWHQKHIW 6\VWHP $QIRUGHUXQJHQ 3IOLFKWHQKHIW Nachweis der Erfüllung der Systemanforderung 6\VWHPHQWZXUI Beeinflusst Verifikationsdetails 6\VWHPYDOLGLHUXQJ 6XEV\VWHP (QWZXUI 6XEV\VWHP (QWZXUI 6XEV\VWHP 9HULILNDWLRQ 6XEV\VWHP 9HULILNDWLRQ 6XEV\VWHP $QIRUGHUXQJHQ 6XEV\VWHPQ $QIRUGHUXQJHQ Architektur Architektur Verifiaktion Verification Verifikation Verifikation Verifikation Verifikation +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW,QIRUPDWLRQVPRGHOO ]XP 3UR]HVV 9ROOVWlQGLJ /DVWHQKHIW 6\VWHP $QIRUGHUXQJHQ 3IOLFKWHQKHIW 6\VWHPHQWZXUI 6\VWHPYDOLGLHUXQJ 6XEV\VWHP (QWZXUI 6XEV\VWHP (QWZXUI 6XEV\VWHP 9HULILNDWLRQ 6XEV\VWHP 9HULILNDWLRQ 6XEV\VWHP $QIRUGHUXQJHQ 6XEV\VWHPQ $QIRUGHUXQJHQ Architektur Architektur Verifiaktion Verification Verifikation Verifikation Verifikation Verifikation -19- Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober

43 Copyright 2009 Hans-Dieter Maier +DQV'LHWHU0DLHU 6\VWHPV (QJLQHHULQJ 6XSSRUW,QKDOWVYHU]HLFKQLV 1 Einführendes Beispiel 2 Der erprobte Ableitungsprozess 3 Ein Beispiel 4 Zusammenfassung 5 Und wie gehen Sie vor? +DQV'LHWHU0DLHU (LQ%HLVSLHO 6\VWHPV (QJLQHHULQJ 6XSSRUW $XWRPDWLVFKH$XWRUHQHUNHQQXQJ /DVWHQKHIW 85)XQNWLRQVDQIRUGHUXQJ$XWRUHQHUNHQQXQJ Das Autorenerkennungssystem (AES) muss die Person, die einen Text in MS WORD eingibt, ohne Benutzung der PC Login Information und ohne direkte Identifizierung des Autors nach einer definierten Dauer erkennen. 85:/HLVWXQJVDQIRUGHUXQJGHU)XQNWLRQ(UNHQQXQJ Die Erkennungsdauer darf die Summe von 1000 Anschläge und Mausoperationen nicht überschreiten. 85)XQNWLRQVDQIRUGHUXQJ'RNXPHQWLRQ $XWRU Das AES muss nach selbständiger Erkennung die Identität in den Dokumenteneigenschaften dokumentieren. 85)XQNWLRQVDQIRUGHUXQJ%HVWlWLJXQJGXUFK$XWRU Das AES muss sich die Korrektheit der vom AES erkannten Identität vom aktuellen Autor sofort nach dem Erkennen bestätigen lassen. 85)XQNWLRQVDQIRUGHUXQJ /HUQIlKLJNHLWGHV$(6 Das AES muss nach einer anfänglichen Kalibrierung mit 1000 Anschlägen und Mausoperationen, bei der das AES von einem zugelassenen Nutzer dessen Namen abfragen darf, die Eigenschaften der verschiedenen Nutzer beim Schreiben von Dokumenten selbständig erlernen. 85:/HLVWXQJVDQIRUGHUXQJ GHU)XQNWLRQ/HUQIlKLJNHLWGHV$(6 Der Lernvorgang muss bei jedem erneuten Erstellen eines Dokumentes fortgesetzt werden. (Grund: Änderung der Gepflogenheiten eines Nutzers abdecken). 85)XQNWLRQVDQIRUGHUXQJ'DWHLVSHLFKHUXQJ Das AES muss bei gefundener und bestätigter Identität des aktuellen Autors die Datei unter der zugehörigen Identität zwischenspeichern. 85(QWZXUIVDQIRUGHUXQJ $UFKLWHNWXU Das AES muss in WORD als eine von einem Administrator einschaltbare Zusatzfunktion realisiert werden Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober Copyright 2009 Hans-Dieter Maier Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version Oktober