Requirements Engineering

Transkript

1 Requirements Engineering Was versteht man unter RE? Warum ist es wichtig? Einbettung in ProjektVorgehensmodellen Eigenschaften eines Requirements Engineers Ausbildungsmöglichkeiten 2009 E. Fuchs REVortrag E. Fuchs Folie Nr. 1

2 Was versteht man unter Anforderung (Requirement)? Anforderung (Requirement): Eine Fähigkeit oder Voraussetzung, Bedingung, Eigenschaft, die ein System (Maschine, Software, Person, etc.) erfüllen oder besitzen muss, um einen Vertrag, eine Norm, oder ein anderes formell bestimmtes Dokument zu erfüllen (IEEE ) Anforderung (Requirement) kurz: Eine Bedingung oder Fähigkeit, die das System erfüllen muss Anforderung (Requirement) anders: Anforderung ist eine extern beobachtbare Eigenschaft einer gewünschten Entität (Alan Davis, 2005) Anforderungen: Genauigkeit? Sportlich? Design? REVortrag E. Fuchs Folie Nr. 2

3 Was versteht man unter RE? Die systematische Vorgehensweise, um die Anforderungen in einem oft iterativen Prozess zu ermitteln, analysieren, priorisieren, spezifizieren und verwalten bezeichnet man als Requirements Engineering (RE) Synonyme: (Systemanalyse / Anforderungsanalyse / Anforderungsspezifikation). Requirements Development... Management REVortrag E. Fuchs Folie Nr. 3

4 Requirements Engineering: die Haupttätigkeiten Anforderungen erheben Analysieren, Strukturieren, Formulieren Dokumentieren Anf.DB Anf.DB Anf. Dok. Verifizieren Validieren Anforderungen Prüfen Anforderungen priorisieren, verwalten REVortrag E. Fuchs Folie Nr. 4

5 Requirements Engineering ist abhängig von Organisation und Prozess Prozesse Best practices Normen und Standards REVortrag E. Fuchs Folie Nr. 5

6 RE und Projektvorgehen: im VModel Start Ende BusinessAnalyse & Systemdurchführbarkeitskonzept Testfälle SystemkonzeptValidierung Betrieb Testfälle Anforderungsdefinition Anforderungs Validierung Entwurfs Validierung Test Validierung Pilotbetrieb/ Einführung Validierung Requirements Development Systemspezifikation/ ProduktEntwurf Testfälle Akzeptanztest/ Systemtest Verifikation KomponentenEntwurf Testfälle Integrationstest ModulEntwurf/ Programmierung/ Parametrisierung Testfälle Einzeltest Zeit REVortrag E. Fuchs Folie Nr. 6

7 RE und Projektvorgehen: im RUP REVortrag E. Fuchs Folie Nr. 7

8 Motivation für das RE: Warum Projekte scheitern Studie zu Misserfolgsfaktoren von Projekten Unklare Anforderungen und Ziele Fehlende Ressourcen bei Projektstart Politik, Egoismen, Kompetenzstreitigkeit Schlechte Kommunikation Mangel an qualifizierten Mitarbeitern Unzureichende Projektplanung Fehlende PMErfahrung auf Leitungsebene Fehlende PMMethodik Mangelhaftes Stakeholdermanagement Fehlende Unterstützung des TopMgmt. Technische Anforderungen zu hoch Andere Quelle: GPM (DE), PA Consulting 2007 REVortrag E. Fuchs Folie Nr. 8

9 Warum ist RE so schwierig??? Viele Stakeholder mit unterschiedlichen Zielen, Bedürfnissen Vielseitige Geschäftsprozesse Unterschiedliche Arbeitsweisen Kommunikationsprobleme Undurchsichtiges, komplexes IstSystem Immaterialität (Software, Daten) Vielseitige Möglichkeiten für das SollSystem Schnell ändernde Arbeitswelt Oft zu wenig Fach und ITWissen vorhanden Termin und Budgetdruck (schnelle Ergebnisse) REVortrag E. Fuchs Folie Nr. 9

10 Kategorien von Anforderungen: Das KanoModell Zufriedenheit Sehr zufrieden Begeisternde Faktoren nicht erwartet nicht ausgesprochen noch nicht bewusst Leistungsanforderungen spezifiziert Ausgesprochen bewusst völlig unzureichend Zeitliche Veränderung vollständig Erfüllungsgrad Standard / Basisanforderungen selbstverständlich Unausgesprochen Fast nicht mehr bewusst völlig unzufrieden REVortrag E. Fuchs Folie Nr. 10

11 Nutzen des Requirements Engineerings Man entwickelt die richtige, d.h. die Benutzer zufriedenstellende Lösung schneller, einfacher und billiger Weniger Abgrenzungsprobleme des Systemumfanges Weniger Missverständnissen Weniger Fehler in der Spezifikation Weniger Änderungsanträge während der Entwicklung Weniger, aber zielgerichtete Features Weniger Kosten einer Weiterentwicklung Weniger Chaos im Projekt Bessere Schätzungen Bessere Ausgangsposition für das Testen Man erreicht Höhere Zufriedenheit im Team und beim Kunden / Auftraggeber Die Projektziele! REVortrag E. Fuchs Folie Nr. 11

12 Abgrenzung des Requirements Engineering Requirements Engineering ist NICHT System Design Architektur Testing Anforderungen sind NICHT So viele Dokumente wie möglich Ein möglichst grosses Dokument Ein möglichst perfektes Dokument Ein Roman oder literarisches Werk Eine wissenschaftliche Arbeit REVortrag E. Fuchs Folie Nr. 12

13 Arbeitsumfeld des Requirements Engineer Customer, User, Sponsor demands asks for forces states regulates QM Manager regulates foster pushes Requirements Engineer limits supports must implement discuss Designer Developer Project Manager Architect REVortrag E. Fuchs Folie Nr. 13

14 Einordnung und Arten von Anforderungen Einordnung und Arten von Anforderungen Verifikation Projekt / Entwicklungs Anforderungen Entwicklung Anforderungen an Systembetreiber REVortrag E. Fuchs Folie Nr. 14

15 Anforderungsarten: Gliederung hilft bei der Erhebung und Prüfung Anforderungen Hardware Gewicht Grösse (z.b. Display) EnergieVerbrauch Performance Kapazität Skalierbarkeit Sicherheit Zuverlässigkeit Robustheit Installierbarkeit Kompatibilität Wartbarkeit Produkt (System) Software Nicht funktional (Qualitativ, Technisch) Performance Sicherheit Verfügbarkeit Zuverlässigkeit Robustheit Installierbarkeit Portabilität Änderbarkeit Wartbarkeit Organisation Wirtschaftlichkeit Kompetenz Geschwindigkeit Flexibilität Qualität Funktional Funktionen (Use Cases) Daten Zustände Fehlerbehandlung Schnittstellen Betreiber Garantie Wartung Releases Support Hotline Projekt Vorgehensmodell Prozess Ergebnisse Methodik Kosten Dauer Meilensteine Team Dokumentation REVortrag E. Fuchs Folie Nr. 15

16 Beschreibung der Anforderungen Attribute IdentifikationsNr. Stakeholder, Eigentümer Bezeichnung Autor Kurzbeschreibung Begründung Gewicht, Priorität Spezifikation Version Status Prüf (Review)Datum Weitere Quellen Risiken, Aufwand REVortrag E. Fuchs Folie Nr. 16

17 Ermittlungstechniken Befragen Brainstorming Dokumente studieren Anf.DB Dokumente (Gesetze, Weisungen) studieren Ist System System Archäologie Beobachten & Prototyping REVortrag E. Fuchs Folie Nr. 17

18 Qualitätskriterien für einzelne Anforderungen Abgestimmt Bewertet Eindeutig Gültig und aktuell Korrekt Konsistent Prüfbar Realisierbar Verfolgbar Vollständig Verständlich REVortrag E. Fuchs Folie Nr. 18

19 Formen der Dokumentation Natürliche Sprache textuelle Beschreibungen flexibler Halbformal z.b. Use Cases, Entscheidungstabellen Grafische Modelle Formal / Algebraisch z.b. Algorithmen exakter REVortrag E. Fuchs Folie Nr. 19

20 Konstruktion von Anforderungen mittels Satzschablone Definition: Eine Satzschablone (Requirements Template) ist ein Bauplan für die syntaktische Struktur einer einzelnen Anforderung. Quelle: Systematisches Requirements Engineering und Management: Anforderungen ermitteln, spezifizieren, analysieren und verwalten REVortrag E. Fuchs Folie Nr. 20

21 Überblick über Systemfunktionalität UseCaseDiagramme Dokumentation durch konzeptuelle Modelle Begriffsysteme und Datenmodellierung Klassendiagramme Ablaufmodellierung Aktivitätsdiagramme Ereignisgesteuertes Verhalten Zustandsdiagramme REVortrag E. Fuchs Folie Nr. 21

22 Anforderungsdokument: Beispiel 1. Einleitung Zweck, Leserkreis, Referenzen, Glossar, Konventionen 2. Übersicht Kontext, Benutzergruppen, Konzepte, Einschränkungen, Annahmen 3. Anforderung an die Organisation, Prozesse 4. Anforderungen an Schnittstellen 5. Anforderungen an Datenhaltung 6. Betriebsarten 7. Funktionale Anforderungen 8. Abhängigkeiten unter den Funktionen 9. Leistungsanforderungen und Mengengerüst 10.Andere Merkmale 11.Konfigurierung, Inbetriebnahme und Betrieb 12.Diverses REVortrag E. Fuchs Folie Nr. 22

23 Verwendung von Anforderungsdokumenten für die Planung für den Architekturentwurf für die Implementierung für den Test beim Änderungsmanagement bei der Systemnutzung und Systemwartung im Vertragsmanagement REVortrag E. Fuchs Folie Nr. 23

24 Techniken zur Prüfung von Anforderungen Statische Techniken Reviews (Stellungnahme, Inspektion, Walkthrough) Perspektivenbasiertes Lesen Einsatz von Checklisten Dynamische Techniken Prototypen (Verhalten, Design, Usability) Simulation (Verhalten) Abgleich verschiedener Darstellungsformen Prüfung von AnalyseModellen mit Werkzeugen (RE, UMLTools, ) durch Menschen Storyboards gegen Use Cases Use Cases gegen Datenmodell Use Cases gegen Zustandsdiagramm, u.a. Die Kombination der Vorgehensweisen führt zu den besten Ergebnissen REVortrag E. Fuchs Folie Nr. 24

25 Anforderungen verwalten Ziel: Transparenz für Kunde, Projektteam und Management Projektfortschritt kontrollieren Entwicklung planen Änderungen verwalten REVortrag E. Fuchs Folie Nr. 25

26 Konfiguration Gruppierung von Anforderungensversionen: sachlogisch zusammenhängend konsistent nicht veränderbar Anforderung 001 Anforderung 002 Anforderung 003 Anforderung 004 Anforderung 005 eindeutiger Identifikator Anforderungskonfiguration 001 v0.1 v0.2 v0.3 v0.1 v0.2 v1.0 v1.1 v0.1 v0.1 v0.2 v0.1 Pohl, Rupp (2009): Basiswissen Requirements Engineering. REVortrag E. Fuchs Folie Nr. 26

27 Nachverfolgbarkeitsbeziehungen Handbücher Regelwerke Vertikale Traceability Ziele Post Requirements Traceability Anforderungen Tests Begünstigte Pre Requirements Traceability Entwurf (Einschränkungen) Kode Gotel, Finkelstein (1994): An Analysis of the Requirements Traceability Problem. ICRE 94. Gorschek, Wohlin (2006): Requirements Abstraction Model. Requirements Engineering. REVortrag E. Fuchs Folie Nr. 27

28 Einsatzzweck von Werkzeugen XYZ Tools Office Tools Zeichen Tools Standardtools PrjMgmt System RMTools Config Mgmt Change Mgmt QMgmt System Projekt und Qualitäts Management Dokument Mgmt System Versions und Change Management Test Mgmt Tools Modellier. Tools Testdesign Tools Developm. Tools Entwicklung REVortrag E. Fuchs Folie Nr. 28

29 Beispiel: SparxSystems EnterpriseArchitect Systemstrukturen visualisieren Anforderungen strukturieren Gerber (2009): Anforderungsmodellierung mit UML und UP mit EnterpriseArchitect von SparxSystems. Seminararbeit Universität Zürich. REVortrag E. Fuchs Folie Nr. 29

30 Eigenschaften eines RequirementsEngineer Analytisches Denken Empathie Kommunikationsfähigkeit Konfliktlösungsfähigkeit Moderationsfähigkeit Selbstbewusstsein Überzeugungsfähigkeit REVortrag E. Fuchs Folie Nr. 30

31 Ausbildungsmöglichkeiten Uni Zürich (Studium) Fachhochschulen (Weiterbildung CAS, MAS) St. Gallen Bern Rapperswil Basel ab 2010) Firmen (Kurse) FUCHSINFORMATIK AG IFA INFOGEM AG Synspace Zühlke REVortrag E. Fuchs Folie Nr. 31

32 Certified Professional for Requirements Engineering, Foundation Level Beteiligte Personen und Organisationen International Requirements Engineering Board (IREB) Lehrplan erarbeiten Prüfungsfragen erstellen Zertifizierungsstellen beauftragen Prüfungsverfahren regeln Ausbildungsstätten anerkennen Anerkannte Ausbildungsstätte Kurse durchführen Personalzertifizierungsstelle Prüfungen durchführen Zertifikate erstellen Lokales Requirements Engineering Board Mitwirken beim Erarbeiten der IREB Lehrpläne Mitwirken beim Erarbeiten der IREB Prüfungsfragen Kursteilnehmer und zu prüfende Person SAQ Fachgruppe Informatik (nur CH) CHVertretung im IREB sichern Rekurse behandeln Mitglieder des SREB wählen REVortrag E. Fuchs Folie Nr. 32